Looking for expertise/advice on Ardupilot/MAVlink

Hi,

I’m looking into the possibility of restarting my AUV project. It stalled when it wasn’t clear what the user interface could/should be like. Now it seems that QGroundControl + Ardupilot could be a suitable interface. So I’d like to get the opinion of those who actually know something about this aspect of drone software on what-all it would take to modify Ardusub to do the job.

Technically, only MAVlink/QGC is enough, as that is strictly the user interface. But the state of the art has now advanced to the point that the it makes sense to consider using Ardusub to control the vessel as well as integrating MAVlink, although Ardusub is way overkill when the only really valuable code is the EKF.

Anyway, the primary mission has remained unchanged: low cost (~USD1000) autonomous underwater CTD drone with Chlorophyll a and pH parameters eventually.

Thanks for your interest,

1 Like

@Harold I’m sorry, I do not have any feedback on your question, but is this the repo I can watch to see your progress?

Hi Jeremy,
I won’t have anything to report for a while I’m afraid. There are many design decisions that need to be rethought, for example I’m testing some options for the thruster now. Things will really get going when I’ve put together a team, at least one of whose members has access to a lake! and found funding, at which point there will need to be a page for coordination if nothing else. But right now I’m mapping what all the scope should be.

1 Like

Hi,

On the topic of restarting the Baby AUV project, I’m posting a bit of background and musings on the project because I’d like all yalls insights on how to proceed. In particular I’m looking for an application for or a vision of. I’m a bit too close to the project to be able to see clearly, you see.

The Baby AUV (working name, suggestions welcome) project was to become a cheap and simple AUV for environmental monitoring. The resulting design was an underactuated finless design with only a forward/reverse thruster, and a moving mass actuator to pitch up and down. GPS would be used for localisation while parked nose-up on the surface (so the antenna on the nose would be pointing skyward). After a fix is obtained, reverse thrust is applied and the torque reaction used to roll the vessel about a vertical axis (while descending slowly). At the appropriate time, the vehicle pitches horizontally to the desired heading, and forward thrust applied to get under way.

While under way, minor course corrections are made by modulating the thruster’s single-bladed propeller appropriately (listen for the modulated thruster whine in the video), to bias the inherent wiggle to the left or right.

Both these phenomena have been tested and they work very well. A consequence of employing these 2 techniques is that a large and slow-turning propeller is favoured, as this improves the torque reaction. Coincidentally, this is also the formula for producing thrust efficiently (it follows from the momentum equation).

Not so felicitously, this also means the vehicle cannot make way while on the surface, as the propeller would not be submerged half the time. This is perhaps as well, because the narwhal-tusk-like antenna would be submerged when the vessel is horizontal, so GPS and remote control would not be available. The only thing the vessel can do while on the surface is pitch nose up, get a GPS fix, and communicate via RF.

Here are the necessary actions I see that need to be taken to bring the prototype up to the current state of technology.

  1. Replace aluminum hull with (shorter?) PVC pipe (I lost the source for aluminium pipe, and PVC is cheaper anyway).

  2. New waterproof aluminium end bulkheads, using O-rings instead of compression rubber sealing, which takes away too much bulkhead real estate from payload sensors. Investigate online CNC services.

  3. Nose cone.

  4. New antenna radome, to contain not only GPS antenna, but also GPS receiver; and MAVlink antenna (2.4GHz?)

  5. Rewrite all code for STM32 (current favourite) or ESP32. Original was for bare metal ATmega328p. Port round robin scheduler? Or use FreeRTOS?

  6. New PCB for MCU, and maybe motor controllers.

  7. Add Kalman filter code for current drift compensation.

  8. Add MAVlink code for telemetry and mission upload/control. Test against QGroundControl as the UI repurposed from quadrotor drones for the AUV.

  9. Moving mass actuator redesign, servo was liable to strip gears.

  10. Lipo battery 1s instead of 4s? certainly not more than 2s. Test DC/DC converters for efficiency.

  11. Test new motors for thruster. Previous N20 motor was not powerful enough to develop at least 1m/s.

  12. Decide upon radio for MAVlink (how AUV and QGroundControl communicate). Only 2.4GHz is useable in Singapore. Alternative to expensive Holybro SiK?

  13. Decide upon EC sensor. Atlas Scientific EC sensors do not integrate well into the bulkhead, and are unnecessarily expensive anyway.

Here is the initial vision, and where it is now:

Initially this AUV was to be for environmental monitoring, which I have some background in. Here is what we are up against: This used to be the best in class, replaced by this one. You can see the trend towards smaller vehicles. Let’s compare Us/Them:

  1. Cost USD500-1k/30k (old price from memory)

  2. Mission duration 24h/8h

  3. Weight 3.5kg/9.5kg

  4. Speed 2kt/3-4kt (projected)

  5. Max depth 50m?/250m ^^

  6. Vertical profiling Up+down/Up ** they may control for drift

  7. Number of parameters (~sensors): maybe3/7

  8. DVL? No/Yes We’ll use the propeller as an odometer instead

  9. Altitude sensing/echo sounder: No/Yes

^^ Depth at present is limited by the survivability of sensors, not the AUV.

Taking physical parameters is basically an O(3) problem because we’re surveying a volume. Here we have the advantage (cost). The strategy then is to develop a synoptic view or get a baseline with multiple low cost AUVs, sending in the expensive AUVs if needed to investigate anomalies.

Apart from this, what other possible futures are there? Can you see a path to ubiquity? Do you know of an appropriate (sympathetic?) first customer/first use case?

Thanks,

-harold