This project started as a way to collect data on my local lake, but has evolved over the last year and gained some momentum with some local grants, and now a pilot project planned for the fall.
Inside the dry housing is a ~700 mL buoyancy engine, 240 Wh battery, and Blues IoT cellular / ELRS controller for comms. Externally in the front end is the BR ping sonar and depth sensor, and in the rear is an external on/off switch, and 300 meter rated servo that steers the T200 thruster with the folding prop and fins.
You can launch it from shore and drive it like a boat, then when you flip a switch on the RC controller it starts its pre-programmed dive profile, slowly gliding forward as it goes up and down, or moving along the bottom for a set time before surfacing.
We’re currently working on the firmware that handles everything underwater, so you can see in the pictures we added a temporary tether to help with troubleshooting. As well as a web interface that can push/pull telemetry data and commands through the internal Blues hardware.
The plan for this summer is to add connectors and space for RBR, YSI, or AML sensors, and something to log data from them. I’m still trying to figure out if the use case for something at this low price point is single-day, or multi-day missions, and that will determine a lot of the above.
I’d love to hear your feedback or suggestions for future use cases, and I’ll do my best to answer your questions.
Hi @brad_smith, cool project - thanks for sharing!
Is that a personal interest, a government/council supported project, or relevant for some other commercial venture? I’d be interested to know what kind of data you’re collecting, and whether that’s intended to be open access (and potentially contributed to by others who make similar vehicles), or if it’s driven by a specific location-relevant project.
Nice! I’m curious whether you’re tuning the base buoyancy to prioritise descension or ascension, and what kinds of speeds this volume allows you to achieve.
Are you adapting ArduSub for this? Developing something from scratch?
If you’re using BlueOS presumably you at least have a single-board computer on there (likely a Raspberry Pi of some kind), but you haven’t specified if you’re using a standard flight controller board, or something more custom.
This all started as a way to try and help my city press charges on a local condo development that was polluting our lake. This introduced me to a few ocean tech accelerators here, and after a lot of Teams calls this evolved into a venture developing a tool to make marine data collection more accessible. The plan is to build a platform that will allow people to use their own third party sensors that best suit their mission. The pilot project we have planned is to do before and after surveys of dissolved Co2 and PH levels for a company doing marine carbon dioxide removal. I’m looking for more pilot projects to do this summer if you know anyone interested in collecting costal data.
No Buoyancy bias at the moment, though I really want to explore using this as a mobile mooring. I’m working with someone building a underwater motion activated camera, and we want to send it out on the AUV, have it sit on the bottom for a week or more, then come home when the battery is getting low. The most expensive part of using a moored sensor is getting it out there.
The pump operates at about 1.5 L/min, letting us change direction quickly, and operate in really shallow water. the Slocum glider by comparison needs 50m of water depth to operate. We don’t have a measured max speed yet, but for comparison the Slocum glider moves at about .5 knots with 50-100 mL of displacement. Two of the main concerns of operating a glider in costal waters was salinity changes, and faster currents, and the larger buoyancy engine helps us overcome both of those.
Here’s a dropbox link of some tank testing I did trying to get it neutrally buoyant. Dropbox
A previous prototype had a Pi, and the one before that had a F405 fixed wing flight controller running ArduBoat. Both were overkill for the testing we were doing at that time. I’d love to go back to that if we can find a business case for it, but without a DVL they were only really useful above the water. The Blues comms system comes with a ESP32 microcontroller called a swan, and that does everything we need it to at the moment.
We have a couple demos and the polit project lined up, but our goal is to gain as much customer feedback as posable this summer. The end user will ultimately dictate the direction of this project now. If you know anyone who’d be interested in a trial project please let me know! I’d love to explore what other jobs this could do.
Nice! That’s a large part of the BR playbook, and it’s exciting to see that expanded in additional directions
Not my space, I’m afraid, but I’ll mention it internally, and hopefully there’ll be some interested community members who come across your post as well
Are you after anyone (globally), or specifically people in Canada / near where you’re currently located?
Super cool idea - with sensors suited for long-term submersion that could form a highly effective data collection system. A valuable expansion could be to enable parallel and sequential collection, perhaps with something like a central floating platform with that can handle data upload and occasional recharging of multiple AUVs in a swarm. With motors on the platform it could hold its position, and even relocate the whole array from time to time to survey a new area.
Well, sometimes it’s getting it back
The DORIS project comes to mind, though the surface returning mechanism there is single use (a mechanical part dissolves to release a weight), so can’t be as readily expanded to continual/repeated data collection.
Fascinating insights - thanks for sharing
Nice! I imagine in practice this is expected to be managed by a PD controller or other control algorithm? Neutral buoyancy is tough, both to achieve and maintain - especially since at the finer end it’s dependent on temperature and salinity of the water.
Fair enough. Longer term data collection is a different game from live (and especially remote) vehicle control, and it makes sense that at some point it’s more efficient to strip back the internals and just extract data at the end before providing functionality to make it accessible/pretty.
I’m located on the east coast in Nova Scotia, and have a few parties here interested in seeing it this summer. But also a few in the US. I recently bought a pelican case for this, so if someone wants to pay for the shipping I’d be more than happy for them to try it out.
My background is in mechanical design, with some experience in manufacturing as well. I’ve been fortunate enough to have a few grants to help with the firmware and web portal, but anything beyond that I need to justify with a business case. The Venn diagram between passion project an profit project is quite narrow, but that’s how businesses are made! If i had infante time and resources I’d love to explore a million other use cases for this.
For us to further integrate this into the Blue Robotics ecosystem I think we’d have to find a way to incorporate BlueOS, but I’m not familiar enough with it understand the feasibility of doing that. Is there someone on your team I could talk too to explore that a little more? For example i heard It doesn’t work with control surfaces like a rudder?
Hi @brad_smith -
I don’t think BlueOS makes sense for your application, as the pi required to run it uses drastically more power than a microcontroller, which would really shorten your mission time! It’s also true that ArduSub doesn’t support control surfaces- it can be tricked into working, but has issues when velocity decrease and control surfaces lose authority…
The only advantage BlueOS and ArduSub may bring you is convenience in integrating some payloads, and the ability to use existing GCS software to plan your deployments- assuming the vehicle has a position sensor of some variety!
Thanks Tony, this is quite helpful and confirms my hunch. I’ll keep using the microcontroller for now.
I also have a group of software students working with me at the moment building an interface to send and receive data. We’re able to achieve most of the ground control functionality through this, and then it just sends simple instructions to the microcontroller to execute. It’s all still in the early stages, but has the potential to solve some of the same problems.
