OpenMantaClaus - Open source low-cost ROS2-based AUV for SAUVC

Projects
1

MantaClaus runs its entire autonomy stack on a Raspberry Pi, a Blue Robotics Navigator Flight Controller, and a single simple USB webcam. I built it independently on a tight budget for the Singapore Autonomous Underwater Vehicle Challenge (SAUVC), where it managed to snag 2nd place!

Key Features & Architecture

  • Software: Built on ROS 2. I extended and forked the ROS 2 BlueOS Extension to run a containerized environment inside BlueOS for seamless deployment and node management.

  • Vision & Navigation: Custom YOLO-based target detection and classical CV running off a standard USB camera.

  • Hardware: Accessible, low-cost frame and electronics enclosure built using Blue Robotics and ROVMaker hardware.

Open Source Links

Since this is my first open-source release, I’d love for the community to check it out, build on it, or share feedback. Any thoughts, recommendations, or PRs are very welcome!

1 Like
ROS News for the Week August 3rd, 2026
2

Hey, that’s really impressive (congrats on the second place), you should’ve posted the video too:

I have so many questions :grinning_face_with_smiling_eyes:

It is pretty funny seeing an estop button on an AUV, though I suppose it makes sense when there’s no tether nor wifi once you drop it in. I see you’re using direct RC override in MAVROS for ardusub, did you have any problems getting that to work in terms of the endpoint ID needing to be some specific number? I remember having some issues along those lines at one point since it clashed with qground’s ID and it never quite worked reliably, I had to use velocity control instead which pulled along ardusub’s stabilization and had its own downsides.

Anyhow that is some serious yaw and velocity stability over time, and this is just the imu + bar02 + thruster feedback motion model if I’m reading the code right or are the YOLO landmarks used too? A DVL would definitely double your BoM and wouldn’t work in a pool anyway (far too much multipath) so the visual slam method does sound much more promising. Have you got anything concrete planned for that if you intend to continue the project? Coincidentally I was just looking at OpenVINS since it’m told it’s the thing use on quadrotors for monocular odom atm and it might work underwater as well as long as it’s paired with a downward facing camera.

Would be cool to see if you have any videos on how yolo26n performed in practice, I’ve never thought of that size as very.. uh.. reliable, plus the quantization bit had to make the accuracy even worse? Still, 10Hz on a Pi 4 that’s already under load from BlueOS is really quick.

These ZF-S30s have gotta be the first actual pressure rated underwater servos under $300 I’ve ever seen and they do undercut that by a wide margin, do they perform reliably? If so I have to order a few…

3

Ahaha thanks! And for posting the video too!

YES! An estop was mandatory according to the competition rules, although most teams used a magnetic hall effect sensor rather than an actual estop.

Not really that I can remember, as long as I got mavros url’s correct in the config file and it could establish a connection, I had rc_override work right off the bat. I have consistently used rc_override for any kind of control in all the AUVs I have worked with. It makes sense since most stacks are very reliable and easy to use as teleoperated vehicles meaning a pseudo-joystick is the most natural replacement for AUVs. I haven’t tried velocity control, but it does require a reliable dvl so I wouldn’t have been able to do it here anyway.

most definitely yes! The final map->odom transforms come from the ekfslam node. The imu+bar02 combo was quite reliable over time but the thruster feedback motion model is a huge source of drift and error so without ekf corrections, the localisation would not be stable whatsoever. VIO with a bottom camera becomes a much better alternative without moving to expensive DVLs. I was skeptical about DVLs in pools but surprisingly enough several teams managed to use them reliably (including Bumblebee that won robosub this year and Mecatron that won SAUVC last year) so there is something there as well.

I have the OpenMV camera as the downward facing camera, simply because I had it with me and it offloads some compute. The natural next step was to use openmv optical flow with ardupilot with some assumptions about floor distance (the pool depth is known beforehand) to get a pseudo DVL. OpenVINS is a great alternative which I haven’t explored simply because of compute constraints (but I did consider adding some extra usb compute to the pi at some point haha)

I actually did have a yolo video in the readme, it doesn’t seem to have rendered properly but I have fixed that now! the raw 26n pt model was great, but the quantisation definitely ruined the reliability to some extent. What helped here was doing a big pretrain run and then finetuning it in the actual competition environment. this ended up being quite reliable even to changes in lighting and some turbidity. For outdoor ocean environments with murkiness and unpredictable conditions, I Would still be skeptical about this.

These were a steal! I had some issues with them as I’d expect. After some use they started jittering a lot to the point that they were unusable but what fixed it was keeping them on for a few minutes after which they stabilise again. My guess was there was some internal condensation, that leaves when the servos get hot enough again but it was hard to tell. I don’t think I would buy these again because of this (and the really hard to find support), but I would definitely consider the slightly more expensive ROVMaker alternative which I bet is more reliable. Although, that being said, I only did buy one servo (didn’t have budget for spares) and there’s a chance I just got unlucky with them.