We on the Sofar Ocean firmware team are working on the new Bristlemouth implementation of our Smart Mooring product. We want to define the messages that we send around the Bristlemouth network in a standard way and set an example for the community.
We were leaning toward using ROS-style msg files, but we would have to build our own code-generation tooling to create the C/C++ implementations of those messages. I put together a quick proof-of-concept last month.
Today as @russ was diving into some implementation details we had a more informed and in-depth discussion about how we would implement string fields, and we came out leaning toward protobufs as already solving several related issues.
I wanted to hear some opinions from the community though, so everybody please speak up! Have you created or used ROS .msg files before? Have you created or used .proto files before? Were these uses in a bare metal context, an RTOS context, cloud server-side, or something else? How was your experience?
I hadn’t heard of flatbuffers. Thanks for the tip! I also see it offers a schema-less self-describing version, which is one of the main motivations for using CBOR on the wire, which has been the main idea about the code we’d generate from the .msg files if we went that way.
Really appreciate the suggestion of flatbuffers. It’s a really cool project!
After doing some internal proof-of-concept work, we decided to use CBOR on the wire, and to have ROS-style msg files that, for now, are just documentation, but later we’ll create code-gen tooling to generate the .cpp and .h files to encode and decode CBOR.
Flatbuffers is very much intended for mobile phone processors that are significantly more powerful than the Cortex-M microcontrollers we use for all our devices. I took the flatcc project (flatbuffers on C instead of C++) for a spin because some folks report being able to run it on FreeRTOS with portMalloc, but it’s definitely not designed by the maintainers for that usage. It’s also fairly poorly documented, and the heavy usage of macros means you can’t search the code for which function you should use.
We don’t want to create a difficult path for future Bristlemouth developers — we want things to be as easy as possible, and the tinycbor documentation is very clear.
Additionally, flatcc doesn’t support flexbuffers, the schema-less variant, and I believe that the ability to read and understand Bristlemouth messages for which you don’t have a schema will prove highly useful down the road. We’re encoding CBOR messages as maps with string keys, even if you don’t have the schema, you could inspect the keys and learn about what’s happening on your network, or even inspect messages for a particular key that you expect even without knowing what the rest of the message means.
Imagine a future in which there’s an ecosystem of Bristlemouth modules that you can buy from many different vendors. They’ll be released at various times. Some will have compatibility with some others. Some will be maintained with firmware updates available while others won’t. The ability for a module OEM to declare the messages they publish and subscribe to and to leave room for extensions to those messages by future devices that can remain compatible in the long term — that’s a future I’m excited about.
