DroneNode Motherboards - Evolution from v1 to v5

Each boat (or other device) is based on a custom ESP32-based motherboard running our DroneNode firmware.  The motherboard exposes the ESP32 IO interfaces (digital/analog IO, serial, SPI) and includes an 8-channel I2C expander to make connecting peripheral devices extremely easy.  It has also evolved to include onboard GPS, RFM69 radio, QMC5883L compass, status Neopixel and micro-SD card reader as of v4.

The same DroneNode firmware runs on all versions of the motherboard, maintaining backward compatibility and auto-detects hardware version based on an I2C scan of onboard devices.

See DroneLink Architecture for how the motherboards fit into the overall DroneLink ecosystem.


Version 1 - Simple beginnings

Our first attempt at a motherboard to support early test boats (like the Paddles) - calling it a motherboard is a stretch, given it was really just a breakout board for an ESP32 DevKit, an I2C multiplexer, and a bunch of connectors for expansion ports / I2C.

Its simplicity was deliberate.  It was a good chance for me to get back into PCB design (having barely touched it in over a decade) and serve as a quick/cheap/straightforward platform for further development.  

ESP32

Selecting the ESP32 as the long-term platform on the hardware side was an important choice, but a fairly easy one.  I've been working with embedded devices for over 20 years and have used most common platforms at some point (ARM, PIC, various Arduinos, etc), but in more recent years, I've settled on ESP32 as my "go-to".  It provides an excellent balance of computing power, memory, flash, IO, integrated WiFi/Bluetooth, library/community support, and is extremely low cost.  It also had no supply chain issues through COVID, which helped!

I2C

You may be wondering why we included the I2C expander, given I2C can support a lot of devices on a single bus.  After early experimentation, it was a choice driven by:

  • Some I2C devices have a fixed address and so you can't have multiple on a single bus
  • Minimal sensors per bus minimises noise and also generally avoids issues with pull-up resistors
A full 8-channels is a little sledgehammer, but it has worked extremely well in practice and also simplifies wiring, as each sensor can generally have its own channel.

JLCPCB, EasyEDA, and LCSC

There are several popular PCB fabs, but my go-to is the nicely integrated suite of EasyEDA for PCB design, JLCPCB for PCB manufacture, and LCSC for component sourcing.  They've proved extremely fast, reliable, and high quality over a number of projects.  EasyEDA also lives up to its name, whilst allowing us to share/collaborate on the PCB designs.

Version 2 - Start of Integration

For Version 2, I wanted to start including surface-mount components (rather than plugging in modules), bring the size down and integrate some common components - starting with the I2C multiplexer and RFM69HW radio module.

Two of our core design principles are modularity and minimal part count, so this motherboard also standardised on 4-pin JST-XH connectors.  All external IO was exposed on these 4-pin connectors, each combining a pair of IO pins plus power and ground, with a jumper allowing the power pin to the connected to 5V or 3.3V. 


Version 3 - Tried to be too clever, Epic fail

In version 1 and 2 boards, we would occasionally have issues with a sensor that would require a power reset to resolve.  Wanting to automate this power reset function, I thought it would be fun to control the power pins for external devices using a bunch of MOSFETS - one for the 3.3V rail and one for 5V rail.  Having so many MOSFETS to control needed a lot of IO pins, so I included a 16-port IO multiplexer.  

However, once the boards arrived for testing it didn't take long to produce magic smoke.  It turned out I'd completely misread the Chinese datasheet for the IO multiplexer and it's bootup state was for all outputs to be active - enabling all the power outputs and shorting the 3.3V and 5V rails.  Suffice to say that put a rapid end to the V3 boards and the whole batch went into the reclamation pile.  I've since scavenged the occasional chip off them, but basically, they're junk.


Version 4 - Bells'n'whilstles

Having learned some lessons on V3, I decided to integrate a bunch more devices in V4, including an SD card module to allow for data-logging.

Key features:


Overall V4 has been very successful with almost all aspects working correctly, the one exception being the SD module. As of writing, I've been unable to get SD cards to be read/written reliably - I've yet to confidently diagnose the problem, but potential causes may be some missing passives or an SPI conflict with the RFM69 module. The latter may be resolvable in software, but the former will obviously need a hardware revision.



Version 5 - TBC

I've started designing Version 5, in fact, a complete design is ready to be manufactured, but first I want to confirm the issues with the V4 SD module.

The design objectives of V5 are:

  • Move from using a plug-in ESP DevKit module to onboard ESP SOC and associated circuitry - targeting the ESP32-WROOM-32UE (16MB) Soc with external WiFi antenna for enhanced range
  • Header for FTDI programming (no onboard USB interface to save cost/space)
  • Shrink board footprint to 50x50mm
  • Stackable with the Power Module v2
  • Edge JST-XH connectors can be interchanged with right-angled versions for low profile wiring
  • Different multiplexer I2C address from v4 to allow for automatic motherboard version detection
  • Optional permanently enabled peripheral power or controlled via ESP on D32
Assembly approach:
  • Bottom-side surface mount components to be soldered using a hot plate, including majority of SMT components, especially those with challenging footprints (like the tiny compass)
  • Top-side SMT is simple enough to be hand-soldered
  • Through-hole connectors are hand-soldered last


Comments

Post a Comment

Popular posts from this blog

Waypoint Navigation and Sailing Algorithm

Image
This post describes the underlying operation of the Sailing algorithm built into the DroneLink platform.  The functionality is spread across a number of logical modules, allowing for flexible usage in different types of devices, for example, motorboats requiring waypoint navigation, but not sailing logic. Waypoint Navigation All our boats (and other mobile robots) require basic waypoint navigation, implemented in the Waypoint module.  The module loads a list of lon/lat coordinates and associated target radii from a CSV stored in the ESP32 flash filesystem (waypoint.csv).  An example CSV and the resulting visualization is shown below for 4 waypoints: The Waypoint module subscribes to t he current lon/lat location,  from the GPS module, and uses this to calculate once the boat has come within the target distance of the current waypoint (10m radius for the first waypoint in the example above).  Once the target radius is reached, the next waypoint from the file w...
Read more

Volantex Compass Robotic Conversion

Image
Motivated by the desire for a compact, traditional sailing boat that I could easily chuck in the car and launch with minimal prep, I acquired a second-hand Compass Volantex DG65-class RC yacht.  The previous owner had assembled it from a kit, but never quite finished the rigging.  So, having completed that little task I took it out for a sail using the included 2-channel RC transmitter.  This test sail verified it behaved nicely on the water and gave me a sense of how it might behave after conversion to robotic control!  The conversion would involve a few stages: Replace the original RC receiver and battery with a DroneLink motherboard, Power module and LiPo battery Rework the electronics bay to accommodate the electronics Replace the stock hatch with a new 3D printed hatch to house the battery and Compass module Integrate a GPS antenna and 915MHz dipole for the RFM69 radio Create a miniature wind vane using an AS5600 magnetic encoder  Overall layout: New Brains...
Read more

Making the Keel of So Close

Image
Preface this is a blog about making a keel for a model boat. If you haven't read the post about that it won't make a lot of sense - Link to the original So Close post. So Close needs a high-density low heavy keel to keep it the right way up. Sounds easy to make something heavy, but it also needs to be a streamlined shape and have some means of fixing it to the two bits of sheet metal that it will hang between. Still doesn't sound very hard? Just 3D-print a mould of the shape and fill it with concrete, cast in a few bits of threaded rod and job done? Not quite so easy, So Close needs a 6kg keel, but the density of concrete is approximately 2.4kg/L, so 2.5 litres of concrete. Not a small mould to print, but not impossible if done in a few bits. The problem is when put under water it will displace 2.5 litres so now the concrete only weighs 3.5kg and it's huge. Now, of course, I could keep adding more and more concrete, not a very practical strategy, or pick a more dense su...
Read more