[Open] Feedback Period - Spring 2024 Developer Accessibility Sprint

Hi all,

This spring the core development team is starting a sprint to develop more tools, features, examples, and guides that focus on accessibility.

There are a number of really great ideas out there and we need your help to narrow that down.

Some examples could be:

  • more common integration examples (like I2C or generic UART)
  • ability to program apps on the Bristlemouth mote with micro-python
  • more fleshed out request-reply examples
  • a Bristlemouth-over-serial transport library for common co-processors (RasPi/Arduino/…)

Please reply here let us know what you’d like to see, where you might be blocked, or what would be most helpful to making your project with Bristlemouth succeed!


1 Like

Hi Zach,

There is some really interesting work going on in the land of sensors, and I can see why that would be a priority for you guys.

We’re interested in exploring the use of Bristlemouth for managing components on board a submersible using something like a Raspberry Pi. There are all sorts of connection possibilities there along with all of the associated needs of the device at the end of that connection.

For example, thrusters. I can control a thruster programmatically using a Pi, but I can’t use the Pi to provide power except for small motors. And so, I need to use an additional motor control board that can provide “3rd party” power. So, there could be a need to communicate through multiple components. The Pi might want to get an acknowledgement that the thruster is running, perhaps a readout as to the RPMs that it is providing. I might control direction of the thruster using a stepper motor, and need to communicate with that as well. I think that there might similar applications for, say, lighting control, cameras, specimen gathering devices, manipulators, buoyancy control, etc.

So, what I’d like to explore to see what facilities there might be for not only carrying signal, but for carrying payloads of data, some going to the devices, some coming back. And like with something like Ethernet, be able to identify the target for the instruction/data, etc.

It might be interesting to, instead of using a host of connections on the Pi, each going to a device, to have one connection on the Pi that connects to Bristlemouth, and have it manage the traffic to the devices. Use software on the Pi to construct packets of data or instructions to be sent to the various devices, and let Bristlemouth route it to the right device. I wouldn’t expect Bristlemouth to be able to interpret the instructions being sent, I don’t think.

Anyway, that’s the idea that I’d like to explore. A lot of this can be experimented with without even having to put something in the water, although I’d like to do that as well. I’m building our first very simple ROV now, but I’m also planning our next one, which will have the Pi on board. That might be a good time to be able to do some parallel work, where we build the functionality without using Bristlemouth, and also build it with Bristlemouth.

Thanks for your time. Ron

Hey Zach,

Great to Meet on Tuesday! For my application (USV) a standalone Bristlemouth telemetry unit would be amazing! So rather than using a spotter e-box, a stripped back unit which could be easier to integrate into a wider range of form factors (e.g. wouldn’t need batteries etc). Appreciate this is probably beyond the scope of what you were thinking but I’m sure there would be some others out there who would fine it useful!

My two cents:

  • Big +1 for micro-python support
  • A standalone Ethernet to Bristlemouth interface with Linux support, great work by @spiderkeys already
  • Minimal sensor bridge reference design (stripped down Mote)
  • Ability to add add additional communication channels to Spotter, see crazy idea here: link

Keep up the good work!

1 Like

Hi Andre,

Your lessons learnt ae very helpful, our team would also like to mount additional instrumentation to the unit, inclusive of a subsea camera also.

Your feedback regarding the internal heat of the unit, has this caused any malfunctioning of the instrumentation or data feeds?


More details can be seen here: Bristlemouth Core Development Roadmap & Feature Tracker - #2