[Guidance & Control] Thruster allocation from URDF/SDF

[arjo129]

• [ ] Filter thruster allocation from plakton
• [ ] Setup example with a hover type vehicle on Ignition
• [ ] Get TAM from URDF

[oKermorgant]

Hi,

I'd be glad to propose a package that acts as a thruster manager from URDF.

Something similar was done in Plankton and I have adapted it to Ignition plugins.

A few remarks remain:

• the input can be a Wrench or WrenchStamped but the normal use is to have a wrench expressed in the control frame anyway
• I currently use a JointState as the output, as it allows conveying all thrust information in a single message. However Ignition would expect one Float64 per thruster (thruster plugin). My guess is that we should let the user pick their desired output
• the body control frame should be a parameter
• In most cases the TAM is constant and can be extracted from the URDF, under the condition that thruster joints can be identified. What we did in Plankton is assume all joints that begin with thruster are thrusters. What I do now is identify which joints use the Ignition thruster plugin, as it is written anyway in the models we use here.
• If it is not constant (steering thruster) then we can still reconstruct the current TAM from /tf. However I am not sure whether people using a steering thruster ROV would use this package or rather a custom one to also control the steering angles
• My choice would be to use C++ so the node can run embedded or as a library for a higher-level control

What do you think?

[bartboogmans]

What do you think?

Well I think your work fulfills many goals in this topic, and is pretty awesome. I've been reading through it and want to show my respect on this work.

It's also nicely packed: one module/node/repo to solve a single, well bounded problem. I think that benefits reusability as well. I often also see thrust allocation modules hidden within the spaghetti of other code, and I like it more like you did here.

[bartboogmans]

To best shape the ros-maritime framework in the future, I think we should not aim for having only a single thrust-allocation algorythm because there are many different approaches, each with their own strengths.

I think @oKermorgant sets a good example of a solution that satisfies requirements for many users, and could be the go-to solution in such cases.

Ideally I'd see convergence towards a standardized thrust-allocation-interface where solutions could be swapped out according to need.

Some ideas of features/information that could be supported/integrated in urdf

• Support for more complex thrust models, for instance:
  • Rotatable thrusters ($T$ becomes variable)
  • Velocity dependent actuators (e.g. Fins)
  • Propeller-rudder combinations
• Integration of actuator dead zones
  • e.g. a propeller with minimum speed
• Some means of quantifying preferences in actuator use in general, or under specific circumstances.
• Enabling different modes of operation
  • e.g. docking, stationkeeping, transit or emergency situations

I'm just putting some ideas out there that I believe would be ideal. Any thoughts on this are welcome.

[oKermorgant]

Hi

As for steering thrusters I am currently funding a PhD program on this topic. If it is successfull then early developments will be on this part and will of course be open sourced.