Catching up on our student projects

Community
1

Hi,
With the awesome news that Bristlemouth is now interfacing with a Pi, and the great work done by the folks who were able to pass an image through Bristlemouth, I thought it might be a good time to catch up on what we’ve been up to. Anyone who has seen my previous posts might know this is going to be a bit long. Patience, my friends.

We successfully finished our first ROV. It’s a simple unit, all manually controlled, with 3 thrusters. There’s nothing new here, but I see it as a great opportunity for our students to learn some of the things that they’ll have to deal with when building a submersible, from movement, to bouyancy, to control, working with waterproof seals, etc. “Sea trials” were in my bathfub. I’ll get it out to some local ponds soon just to try it out.

I’m moving on to the design for our 2nd submersible, which will have a Pi on board, which is why I’m excited about the Bristlemouth Pi communications

There are some practical challenges that are driving some of the design decisions into interesting areas. We are in Elmhurst, IL. As you may notice, we don’t have any oceans nearby but we do have Lake Michigan. That is great, BUT, the deep parts of Lake Michigan that are our target areas are a long way offshore, well, “long way” for us. And so, we’d have to travel a ways (the deepest part of Lake Michigan is about 150 miles north of us), and then charter a boat to get us and gear onto the Lake. That’s expensive, especially if you want to do it fairy regularly to test equipment and capabilities. Even if stay in shallower waters for now.

That got us, well, me, thinking about building a small surface vessel that could act as a “mothership” for the ROV and let it take the ROV wherever we’d like to explore (whether that be environmental monitoring, wreck mapping, etc). Luckily, there are folks already doing this, and we can piggyback on their great work. Basically, the idea would be to have the surface vessel ferry the ROV out to wherever we’re testing, and drop the ROV with a fiber optic tether (a later generation could be completely autonomous). The tether allows the surface vessel to relay control and monitoring data to and from the ROV. Now, typical remote control systems can’t reach as far as we need to go with the surface vessel, so we need another solution. I thought that the Bristlemouth Developer’s kit would be a tool for that since it has those communications capabilities, at least in concept now. Unfortunately, we haven’t been granted a developer’s kit, so I needed another solution. I thought about modeling our ROV management system on the way that the Mars rovers are controlled. They don’t have real time connections, and so send instructions that are interpreted by the rovers and executed. Since I can do that, I think, with text messages, I think we can use cell phones on the surface vessel for that purpose. (I’ve checked with local boaters, and texting out into the Lake is not a problem) I still like the idea of working with Bristlemouth, and so I plan to mimic the protocol as much as I can so that should we be fortunate to get a developers kit at some point, we can migrate to that. We’d simply integrate the buoy into our surface vessel (somehow :-)).

So, in short, we’ll have a Pi managed surface vessel that we can communicate with via text messages. It will have the basic mission paramaters loaded into the Pi. The surface vessel will have the submersible on board in some sort of cradle that can be opened to drop the ROV as well as bring it back on board. The ROV will have its own Pi on board for managing operations there.
And then the surface vessel brings everything back to a happy reunion with the land lubbers on shore. I’m going to take a close look at the image carrying work that’s been done, since we can definitely use something like that. Under consideration is adding a side scan sonar to the ROV to find targets of interest and then having a 2nd, deeper diving ROV for further examination, but one thing at a time.

And, I’ll just add as I usually do…I completely understand the folks at Bristlemouth not granting us a developer’s kit. The work that they’ve been doing is prioritizing sensor work, and while we’d certainly use that at some point, that’s not our focus. So, I’m cool with that, but as I said, I’m going to mimic the protocol as much as I can as we do our work so that should a kit become a “thing” for us at some point, we’d have less migration work to do. There are plenty of fun challenges to be figured out, with or without Bristlemouth, so plenty of good learnings for our students (and me).

I should be starting to 3D print the components for the ROV in a couple of weeks.

If you made it this far, thanks for your patience.

Ron

2

Hey there Ron, glad to hear how things are going. We’re still aiming the ship towards vehicle integrations. In fact @spiderkeys has been developing in that direction a lot lately. We’re still a ways away–thanks for staying with us!

3

Hi Zack,
Thanks for the note. Yep, we keep plugging along. I’ve looked at some of the things that Mission Robotics is doing, and it seems similar to some of what we’re playing with. Hard to tell, their website is mostly pictures without much behind them, BUT, it’s cool to see what might be done when you actually have staff and money. I’ve looked at what spiderkeys has done just a bit as well.
:slight_smile:

Hey, if you have a minute, could you please answer a really basic question for me; perhaps point me to where in the doc I can learn more? If you have a buoy with multiple sensors attached to it, I’m assuming that there’s something in the protocol that carries an identifier for the individual sensor. And that means that the sensor has to be built with some sort of hardware that provides that identification (kinda like technoligies that use an IP or MAC address??). I’d like to learn more about that because if I’m going to have a common interface for controlling devices, I need a way to identify which component should respond to a command, like one thruster out of a thruster array, for example. Yes, I can use the individual I/O pins on an Arduino or a Pi to do that, using each to a unique component, but the point is to be able to have one pinout that controls everything, ala USB or ethernet. I’d hope to mimic what Bristlemouth is doing so that I can integrate into the Bristlemouth ecosystem easier once that becomes possible. I understand if you’re busy, so no worries either way. Thanks and have a great weekend. Ron

4

Hey Ron! Great question.

The unique identifier for a node (sensor, thruster, etc.) in a Bristlemouth network is called the Node ID. In code, you can get the Node ID as a 64-bit unsigned integer by calling getNodeId() or you can get it as a string by calling getNodeIdStr().

If you call those functions, and the compiler tells you they are “not declared in this scope”, then you just need to add this line near the top of your application file:

#include "device_info.h"

If you have a serial console connected to a dev kit, and you issue the info command, one line of the output looks like this:

Node ID: 0b54ccce5c7978bf

The Bristlemouth protocol runs on top of IPv6. The link-local and unique local IPv6 addresses of each node contain the Node ID, and this is generally how nodes identify each other at the the protocol level.

You’ll also see lines in the info output showing the MAC and IP addresses:

MAC: 00:00:5c:79:78:bf
IP addresses:
Link Local: FE80::B54:CCCE:5C79:78BF
Unicast:    FD00::B54:CCCE:5C79:78BF

The Bristlemouth dev kits use an STM32U5 microcontroller. STM32 MCUs always have a 96-bit read-only unique ID register. In the current implementation, the Node ID is calculated as a 64-bit Fowler/Noll/Vo FNV-1a hash of the unique ID register. There is no requirement by the Bristlemouth standard that Node IDs be calculated this way. They could be generated other ways as well. The standard only requires that the Node ID “is unique within a single Bristlemouth network.”

Since the FNV hash is deterministic, and it’s based on an unchanging read-only factory chip ID for the microcontroller, that means that the Node ID will never change. If you unplug and replug a dev kit into a Bristlemouth network, it will show up with the same Node ID as before. If you plug it into a completely different Bristlemouth system, it will again show up with the same Node ID.

Hope that helps!
Zachary

5

Hi, and thanks a lot for that info. After reading this, and poking around a bit more in the product sheets from Sofar, and the developer kit info online, the best way I can express my thought in type is

Ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!

Okay, I think I get it now. So, does anyone have, say, a “smart thruster “ that connects to Bristlemouth? Might be easier to do something like a light that is either “on” or “off”. Sorry, this has got me thinking now. The chips only cost a few bucks, so I might fool around with some breadboarding to learn more. A place to start, anyway. Our fall term at the university is just starting up, so I have to see when I can get some students involved, also.

Ah, another thing for my workbench :blush:. I’m working on a desk for my son that has a lightsaber built into it (that has the lights and sound), so I have free up some space.

Thanks again, Zachary. Much appreciated. Ron

1 Like