ArduSub advanced control: add support for thrust vectoring, control surfaces, and dynamic buoyancy

[ES-Alexander]

Feature request

Is your feature request related to a problem? Please describe. ArduSub currently only supports static vectored-thruster control, but the underwater environment is well-suited to other motion control regimes like dynamic thrust vectoring, flow-based gliding and flapping, and active buoyancy.

While ROVs most commonly use only fixed thrusters (like a copter, but with vectorised thruster orientations for more intuitive motion), "sub"marines and gliders will often have a single thruster or no thrusters, with steering accomplished by either rotation of that thruster (thrust-vectoring) or by control surfaces that skew velocity by changing the vehicle's flow (lift and drag) characteristics in a given movement direction. Vertical motion is sometimes accomplished by inflating and deflating an external bladder, or by expanding or decreasing the volume of an enclosure with a piston. None of those options are currently available, which significantly limits the scope of underwater vehicle designs that can be meaningfully controlled with ArduSub.

Describe the solution you'd like

1. Rotatable thrusters could be supported by allowing a servo to determine the angle of a thruster, and have the thrust factors dynamically re-calculated based on the current servo angle
   • Changing the thrust factors seems in principle quite simple, but determining the new ones may require decent dynamic modelling of the vehicle, and/or internal records of where each thruster is relative to the vehicle's centre of mass, and where its rotation axis is located
   • Advanced usage could involve two servos, to perform two-axis rotations (e.g. allow a rear thruster to steer horizontally and vertically, with both yaw and pitch control)
   • Highly advanced usage could modify the shape of the vehicle itself
     • This could involve both rotation and translation of thrusters, and change the CoM
     • May require some inverse kinematics, to enable intuitive control of one the shape without self-collisions
       • This could also be applied to control a multi-axis manipulator
2. Basic control surfaces could potentially be supported like the existing support for rudders in ArduBoat and wing flaps in ArduPlane
   • This would likely go a long way to supporting at least basic submarine designs
   • Advanced usage could allow simple flapping (like flippers / fish fins) to provide thrust
     • Highly advanced usage could allow ripple motions that can "flap" a multi-part control surface in the transverse direction, and potentially (sinusoidally?) "slither" it like an eel or snake
3. Basic (piston-based) buoyancy and/or centre of mass (CoM) control could be implemented as a servo (or stepper motor) that linearly scales buoyancy force or moves the CoM by changing its position
   • CoM control (via a sliding mass) is primarily useful for controlling the neutral pitch angle, and/or offsetting the weight of an item that has been picked up (e.g. by a gripper)
   • Buoyancy is dependent on vehicle mass and volume, as well as water density, so accurate (intuitive) control relative to the neutral point would need per-dive calibration
   • Advanced usage could support non-linear control (e.g. from air pumping into or out of an external bladder, or a radially expanding flexible enclosure), perhaps with some kind of user-specified or auto-calibrated curve
   • If a concept of buoyancy is added there may be some value in explicitly supporting single-use changes from CO₂ canister releases and weight-releasing burn wires, but that would only really add value for vehicles with multiple of one or the other, which is much less likely than the other control options on this list
     • It may be possible to handle this as though it's a parachute deployment for an aerial vehicle

Describe alternatives you've considered

• Small thruster or control surface rotations are not hugely impactful to vehicle motion at a given point in time, so to some extent points 1 and 2 are achievable with manual control of servos, but only supporting small angles and manual control is problematic and very restrictive
• Existing vehicles have no concept of buoyancy, and it is currently dealt with by manual control or pressure-based feedback for automated control, so manual buoyancy adjustments are already possible for vehicles that support it, but they aren't usable in an automated fashion (so it's a gimmick/toy feature, not a tool)
  • One-off buoyancy changes are already possible via relay control, and generally do not need much vertical control of the vehicle afterwards, so are a low priority

Platform [ ] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover [x] Submarine

Additional context

• Forum post about control surfaces
• Forum post about adding fins
• Advanced flippers idea inspiration (very cool)
  • A flipper design and usage showcase video
• Robotic fish showcase (flipper+piston buoyancy+sliding mass)
• Forum post about stepper-controlled buoyancy
• Dynamic piston-based buoyancy control example
• Compressed gas dynamic buoyancy control example
• Forum comment about external bladders
• Forum post about multi-axis manipulator
• Tangentially related, video about robots that swim like fish

NOTE: This issue could likely be split into multiple smaller ones, but since the underlying context is related, and advances in one control capability should likely consider relevant expansion of others, I decided to make a single issue that can be tracked as a whole but tackled in parts

[BjornAU]

I'm building a towed underwater drone. Controlled by flaps, they are designed to change the wing profile, more than being control surfaces. the drone has two individually controlled flaps on the front wings. and a double flap on the back wing.

[BjornAU]

Dear software engineers. I’m a mechanical engineer working at Aarhus University, on the development of an underwater towed glider drone. As the drone more resembles a plane than a ROV, but still is an underwater vehicle. We need a features that supports control surfaces as mentioned in this post: https://github.com/ArduPilot/ardupilot/issues/21568

For the drone we are using Blue Robotics; Navigator Flight Controller Ping sonar Lumen Subsea Light Bar30 High-Resolution 300m Depth/Pressure Sensor

Right now, I’m working on implementing a leak sensor on the plane firmware, and in this work I have noticed that the Ardusub firmware, has a lot of nice features, related to underwater vehicles.

I would like build the firmware for a sub, but with plane control.

Is it possible that I could get a run thru on how the Ardusub firmware is build, from the GitHub repository? As a live session? My main questions are; What file(s) are defining what files/functions to include in the build? How is the program/function hierarchy/relations in Ardusub?

As for reference the drone has a footprint of 1.2 x 1.2 m. with an individually controled flap on the two front wings. and a double flap on the tail wing.

[daehwankim112]

Hello, I am also planning to build a glider using a Navigator Flight Controller. Does Blue Robotics have a plan to officially support Glider control system on ArduSub project?

[ES-Alexander]

Does Blue Robotics have a plan to officially support Glider control system on ArduSub project?

Nothing specific at this stage. I'm personally interested in ArduSub supporting additional sub-marine control mechanisms, but I don't expect there'll be an official company push for that kind of development unless it's done in tandem with the development of a product that would gain value through that support, and presumably with evidence of sufficient market desire for it.

Our current vehicle architecture development efforts are focused around making it simpler to create custom ArduSub vehicle frames, and ideally be able to specify them dynamically (without needing to build a custom firmware for frame modifications). If implemented well that work could provide a basis for further developments like thrust vectoring, but persistent state changes (like from dynamic buoyancy and/or control surfaces) will require a more involved modification of the vehicle's motion control algorithms (so are somewhat independent, and will likely take longer).

That being said:

1. ArduSub is open source
   • while Blue Robotics are the primary maintainers, that's partially a stewardship role - we are certainly open to external contributors adding features that are useful to others in the space, and to helping those features get tested and merged
2. Other firmware variants may already support much of the desired control type, in which case it may be simpler to work on adding support for the water-focused sensors and failsafes as options within those firmwares rather than waiting on ArduSub
   • e.g. see this discussion on adding leak sensor support to ArduRover
   • It seems conceptually reasonable to me that most/all vehicle types could have a compile flag or parameter that determines whether they make use of water-based barometers for depth estimation, although it would likely be prudent to discuss preferred approaches with the other vehicle type maintainers before attempting to do so