Close

Design decisions: modularity and microcontroller

A project log for BeeHive

A standard system for laboratory equipment development

Ihor SobianinIhor Sobianin 4 days ago0 Comments

Microcontroller

When we first started developing Beehive, we needed to decide which of
the many available microcontrollers we would use. Given that there were so
many options available, we decided to focus on researchers (our initial target
audience) needs and skills as the main driver for our decision.
What we know about our target audience:
- They use python as one of their main programming languages for data
analysis, therefore choosing a board that could deal with micropython
would be an advantage, as they can with little effort start writing
routines for BeeHive.
- They require data to be transmitted from more than one device at a
time to a central location, so using a board with built in wireless
communication capabilities (Wi-Fi and Bluetooth) would be an
advantage, as different devices could be all part of the same local
network and send data to one central computer.
- Not all researchers are based in institutions that can either afford
expensive boards, or even having the money, have access to certain
boards. Our chosen board would need to be truly globally available.
- Some experiments are performed over multiple equipment in parallel,
so again having a board that was quite affordable was important, so
the price tag would not escalate with the number of equipment built.
Putting the points above together, it came as an easy decision to select ESP32 as
our main board, since it is quite affordable, ubiquitous available, having many
pins/communication protocols, wireless capabilities and can run MicroPython.

Modularity

Since we cannot foresee all possible current and future uses for BeeHive,
we decided to go with a modular approach, similar to Seed Studio GROVE
system, where, we have a central breakout board, where the pins from the
ESP32 are made available via number of 4-pin XH-JST connectors, and a selection
of “daughter boards” where each board is dedicated to performing one function.
For example, we have a temperature sensor breakout board, that allows easy
connection of the central board to up to 6 DS1..., and an h-bridge board, that
allows us to drive DC motors and/or peltier elements. So if one application is an
incubator, we can combine these 3 boards (main, temperature sensor and H-
bridge) and have a closed loop system in place in no time.
Another point of this modular design is that this makes it easy for others
to create their own modules for BeeHive, all they need to do is respect the
guideline of “one board one function” and the pin out we established for the main board. This will allow the BeeHive community to leverage each other’s work and come up with new applications for this ecosystem.

Finally, BeeHive is GROVE compatible, so we can leverage the many sensors and actuators developed for that ecosystem. The main difference from GROVE is that Beehive is using connectors with higher power ratings, and so we can drive different types of actuators.

Discussions