Here are some quick notes about what we discussed. Everybody please feel free to add more context!
Attending:
Goals:
- End of year: integrators should be able to make their devices support Bristlemouth easily and cleanly without forking, on any embedded platform
- August 23: first rough draft of firmware API docs that we’ll then implement for the rest of the year
Zachary talked about some of the most basic things we’ll need:
- simple packet processing library — imagine a sensor manufacturer who has everything working on their own system but when packets arrive on the Bristlemouth network, they need a simple library that will parse those packets and say basically “what is this” and “what to do with it”
- clearly spec’d middleware APIs: publish, subscribe, request, create service
- code generation: given msg and svc files, generate the C code for encoding and decoding those messages
- cleanly separated independent driver for the ADIN networking chip — Charles gave this one a big
from his experience. Analog Devices has a driver, but at this point we’ve had to modify things quite a bit. Also we need to cleanly support our current 2-port chip, as well as the 1-port hardware and others from a Bristlemouth integrator’s perspective. At Mission Robotics, they will at some point need a single-port ADIN driver for an ESC (electronic speed controller)
Zachary also talked for a bit about how to architect the firmware to easily support both single-threaded hosts (think Arduino setup and loop) and multi-tasking environments like FreeRTOS and Linux. From the outside, the APIs should be designed to assume a single-threaded caller. A multi-tasking caller can simply call the packet processing function in an infinite loop. However, from the inside, the firmware needs to be designed to assume a multi-tasking host, setting notifications/flags rather than calling callbacks directly. A single-threaded host can call those listener functions one after another, polling the status. Charles mentioned DDS waitsets as prior art.
This week, Zachary explored zenoh.io more (which Charles has mentioned to him many times) and found it a really surprisingly awesome project. Charles agreed but called out that zenoh doesn’t have a spec which has been a barrier.
On the point of a custom Bristlemouth ADIN networking chip driver, Victor pointed out that we use lwip for the networking stack in current Bristlemouth firmware and asked Charles how it works in Linux.
Victor’s been researching file transfer, which is an often-requested feature. We heart that a group from Santa Barbara managed to capture and transfer an image over Bristlemouth and Spotter’s telemetry. Victor has been comparing a bunch of protocols and implementations, like tinycurl, ftp, xmodem, zmodem, and the existing Bristlemouth DFU protocol. He imagined users wanting to move a file from an SD card on node X to an SD card on node Y. We discussed how DDS lets the receiver control speed of flow in case the destination storage is super slow.
Charles is primarily focused on Linux. One short term goal he has is to get all basic BCMP messages handled and sending over both the native network and over a serial interface.
Charles is thinking about a registry of types to be used in common messages. He recently gave a presentation at RTI (DDS implementation). There was interest by Woods Hole and the DDS marine working group in such a registry. Now there are a lot of marine folks using DDS, but no common types. He’s talked to some folks at the Object Management Group (OMG). If there were enough interest in the marine space, they would be open to sponsoring a standards process.
Last, Charles talked about recent work to record all traffic in a DDS system to an MCAP file, and then also be able to replay that file on the system. He could imagine doing the same for Bristlemouth. Foxglove is some software to help visualize and manage MCAP data. It targets ROS and DDS systems but could probably be used as well with Bristlemouth.