Omnidirectional surface vehicle controllers for position and attitude

[not7cd]

This PR introduces Surface Vehicle controllers for position and attitude. Attitude is based on UUV controller, while position is written from scratch. This is all work in progress. This vehicle uses 6DOF frame without roll, pitch and thrust in Z axis. And uses 4 engines in OmniX configuration.

As of now, I'm able to drive it manually proving that control allocation works, and minimal modification of PID control was needed for uuv_att_control to adapt it. Position control is not implemented.

Alternatives

Refactor rover_pos_controller to be more generic, disable so-called L1 control.
Extend uuv_pos_controller to implement more vehicle modes.

Test coverage

• Unit/integration test: none, not sure how
• Simulation/hardware testing logs:
  • Custon model based on UUV BlueROV2 with USV dynamics plugin.
  • Upcoming hardware testing in 4 days.

Context

Driving omni vehicles - Discussion Forum, for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink

[swimmingseeds]

This pull request has been mentioned on Discussion Forum, for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-february-15-2023/30744/1

[not7cd]

The logic presented here seems reasonable and close to my use case.

PX4-Autopilot/src/modules/mc_pos_control/PositionControl/PositionControl.hpp

Lines 55 to 74 in d6bb19e

	/**
	* Core Position-Control for MC.
	* This class contains P-controller for position and
	* PID-controller for velocity.
	* Inputs:
	* vehicle position/velocity/yaw
	* desired set-point position/velocity/thrust/yaw/yaw-speed
	* constraints that are stricter than global limits
	* Output
	* thrust vector and a yaw-setpoint
	*
	* If there is a position and a velocity set-point present, then
	* the velocity set-point is used as feed-forward. If feed-forward is
	* active, then the velocity component of the P-controller output has
	* priority over the feed-forward component.
	*
	* A setpoint that is NAN is considered as not set.
	* If there is a position/velocity- and thrust-setpoint present, then
	* the thrust-setpoint is ommitted and recomputed from position-velocity-PID-loop.
	*/

I don't need setTiltLimit or setHoverThrust, but overall mc_pos_control seems like a good fit. I tested it in simulation and it didn't work with my usv_att_control. What can block me or how should I proceed? I honestly don't know what I'm doing.

[swimmingseeds]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/driving-omni-vehicles/30716/4

[not7cd]

For the record, we had tests in the model pool, we collected some data using manual mode. Here are the results.

Flight Review #1
Flight Review #2

Full playlist on YT

We have observed that thrust and torque setpoints are fighting in control allocator. This means that with full throttle it will not allocate torque making turning while moving impossible at full throttle.

Here is an example

Should this be a problem for an attitude controller? Maybe some sort of 6DOF rate controller would solve the problem?

[Jaeyoung-Lim]

This basically breaks all UUV use cases

[not7cd]

I will revert that commit. Should I create my own usv_apps? It is a bit similar to a boat and rover. So I don't know where I stand.

[Jaeyoung-Lim]

Right, would it be too hard to genearlize the rover position controller for your use case? We can separate out the rover_att_control if you think is needed

[not7cd]

@Jaeyoung-Lim, I would appreciate a separate rover_pos_control, I think I might use it usv_att_control. I'm at loss with position control as I'm debugging attitude in on the real model.

Still, should I add rc.usv_apps? I guess it would feature something like this:
rover_pos_control
usv_att_control
6dof_rate_control – about this one I'm discussing at discord

[Jaeyoung-Lim]

Still, should I add rc.usv_apps? I guess it would feature something like this:
rover_pos_control
usv_att_control
6dof_rate_control – about this one I'm discussing at discord

I don't think this is necessary, since your vehicle is the only vehicle that would be using it. I would prefer if we can make the rover more generic, so that we can also support omnidirectional ground vehicles

[not7cd]

For now I would be running this module, but yes. rover should become more generic. My changes could be merged with it later.

[Jaeyoung-Lim]

In that case, would you be able to work on separating the rover_att_controller outside of the rover position controller? I worked on #20082 before to get the low level controls going, might be useful for your usecase also

[not7cd]

@Jaeyoung-Lim, would it be reasonable to drop this PR in favor of refactoring rover_pos_control? I think I gained enough know-how to extend it, and maybe add omni-directionality

[Jaeyoung-Lim]

We can also keep this open, and rebase once the refactoring is done

[not7cd]

If your PR is in working order, I would prefer refactoring rover_pos_control to use control allocator

[not7cd]

For the record, I have been bitten by an issue that was solved here #20885
This wasn't present in uuv_att_control. I have added this as a separate function. This approach could be replicated in other control modules, as it at a glance explains what is happening with the throttle setpoint. This is my way of fighting with such complex functions: smaller functions.

[swimmingseeds]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-march-08-2023/31090/6

[junwoo091400]

This was definitely a cool project & I would love to keep track of it in the future!

As recommended by @Jaeyoung-Lim in https://discuss.px4.io/t/px4-community-q-a-march-08-2023/31090/6, it would be better to close this PR and extend the Rover control logic.

@not7cd could you do that? 😉