Just wanted to post some details about my recent engineering senior design project. Our project’s goal was to create and test a subsea resident AUV. The “subsea resident” title means the AUV is accompanied with a dock where it can recharge and upload data, essentially allowing it to stay underwater indefinitely.
The AUV has 6 BR T200s, in a 5 DoF thruster configuration. Its about 2 feet in width and length and weighs nearly 20kg in air. The AUV localizes itself in our test tank using computer vision, since acoustic solutions were far too expensive.
Some more interesting features:
Custom FOC motor controllers.
Compact 24 cell battery system.
3 Raspberry Pi Zero camera modules.
Support for wireless charging at up to 100W.
Over 25 unique mechanical pieces, all cut using a hobby CNC machine.
I’ve attached links to three videos; a detailed presentation our team gave, a full video showing an autonomous undocking and redocking mission, and our “demo” video, which gives a broader context to the subsea resident concept.
Happy to discuss any more aspects of the project in depth! Hopefully this is good inspiration for anyone looking to work on their own AUV or underwater vehicle project.
Really impressed with your system, you and the team certainly managed to pack a load of useful features into it.
You mention uploading data and charging at the dock - is it also possible to communicate with the AUV while docked (e.g. send it new instructions, ask it for extra telemetry/logging data to debug performance issues, etc), or would inbound communication require surfacing?
Thanks Eliot! Long time viewer, first time poster!
Our AUV communicated wirelessly underwater only while it was docked. A Raspberry Pi 4 acted as our onboard flight computer, and we set it up to emit a WiFi hotspot using RaspAP. Our “surface station” was a simple laptop, and we connected it to an external waterproofed WiFi antenna attached to the dock. When the AUV was docked, the laptop could see the external hotspot from the vehicle and make a connection.
This WiFi communication was only possible at very close distances underwater, about 5-10cm, but it worked completely fine with no hiccups! Really great way to send a ‘launch’ command to our vehicle or monitor it while it was idle and docked.
Cool to have confirmation on wifi range through water, with an effectively acrylic enclosure - someone was asking recently about potentially using a sports-camera outside an ROV enclosure and wirelessly streaming the video in to the internal raspberry pi
I can also confirm that we’re seeing around 5-10 cm of WiFi range underwater. My group set up an ad-hoc wireless network using the BlueROV2 Pi’s wireless hardware, and connected to it using a Jetson Nano placed in a completely separate cylinder strapped on top of the vehicle–we had occasional packet loss, but were able to consistently run that connection even while submerged around 10 meters. Lab testing showed about that same kind of range.
We had a similar idea after the fact Chris! Our camera enclosures include a Raspberry Pi Zero W, so theoretically we could have communicated to them over WiFi from our main enclosure! They draw so little current too that perhaps you could go completely penetrator-less with a wireless power and WiFi combo.
We actually were totally pentetrator-less, although only because we used a separate USB power supply (I think 10000 mAh @ 5V) inside the Jetson enclosure to run things. It did require unsealing twice the canisters in the field to run power, though, which I didn’t love.
However, Especially with the BlueROV2 Heavy configuration, I found it difficult to add additional hardware to the main electronics canister–there’s just not a lot of room. We’d originally run an Ethernet cable between the two, but switched over to using wireless after we starting running into trouble getting a good vacuum seal on the electronics canister because of how many different cables/penetrators we had! For a custom frame, I bet using wireless power would be feasible, and could be a really neat way to implement a hot-swap sensor payload or something.
