Add position lock to resolve quadcopter sinking in offboard mode

[shrit]

Describe the bug I have noticed that the IRIS quadcopter have tendency to lose altitude in gazebo when pitching or rolling in some direction. The problem have been reported and well discussed on Slack you can follow using this thread: https://px4.slack.com/archives/C68J8H32A/p1559816218007600

Log Files and Screenshots https://logs.px4.io/plot_app?log=97830f7e-5bce-4649-8704-e5d0ffc8ea5b

[julianoes]

Since (free) Slack deletes all conversation after some time, let me give some more context to this.

This is using velocity offboard control in MAVSDK. The problem is that the drone will try to hold the z velocity but does not correct drift over time.

A possible fix would be to lock the z position if z velocity is set to 0.

I had done something like that a while ago before position control received flight tasks: https://github.com/PX4/Firmware/pull/5868/commits/642e65cffc5a7199d3847a09bf06814b1f153a90

[MaEtUgR]

I'm shifting towards having reusable logic of the flight tasks in libraries anyways and we can just reuse the position lock from manual position mode which locks the altitude/position when the velocity is constantly zero. The start for this library can be found here: https://github.com/PX4/Firmware/pull/12072/files#diff-cd11905871652d5f1467db1dfc9cecd2R47

[dakejahl]

Nice! Can we have this perform braking? It would be ideal if <0,0,0> velocity setpoints caused the vehicle to brake and then lock into a position hold after coming to a stop.

I am imagining the aggressiveness of the braking could be controlled via a parameter.

[shrit]

Just to add some more details: After monitoring several flights of the quadcopter. I have noticed that sometimes the quadcopter do not just sink, but gain some altitude. For example: a quadcopter might gain up to 5 meters up when it is going forward, and then it starts to sink gradually.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[shrit]

Keep open

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[shrit]

Keep open

[Pedro-Roque]

@MaEtUgR is this still ongoing?

[shrit]

@Pedro-Roque Yes, it still open.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[shrit]

Keep open

[Jaeyoung-Lim]

@shrit Why would you use attitude setpoints if you want to control the attitude? Why is using velocity setpoints / position setpoints not an option?

[shrit]

@Jaeyoung-Lim I use only velocity setpoints. In this case, I was using the velocity setpoints to set the velocity of quadrotor every 50 milliseconds (In order to simulate the behavior of a joystick for example)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[shrit]

Keep open

[Jaeyoung-Lim]

@shrit Given that offboard mode is simply a way to directly access the cascaded controllers inside the fmu, I still think there should be a position controller that is outside compensating for the drift, rather than the expecting the flight controller to hold position when velocity 0 is commanded.

[Pedro-Roque]

I agree with @Jaeyoung-Lim . A zero velocity control command will inherently drift.

[shrit]

@Pedro-Roque @Jaeyoung-Lim I agree on the point that if the velocity vector is equal zero, then the drone is going to drift. However, the behavior I observed when I open this issue is related to the sinking of the quadrotors toward the ground rather than drifting. The quad tends to sink when moving forward in this manner and does not compensate the Z component over time.

[Jaeyoung-Lim]

@shrit This is related to the vertical velocity not being well observable/controlled compared to the horizontal velocity components. I believe it is safe to say that what you are seeing is drift of the velocity controller and you will see different extent of drifts depending on the vehicle dynamics for each axis.

You can try to fight this issue with having a tighter velocity controller on the fmu side. But I don't think having additional position control to lock the altitude is the right solution for this issue. If you have a outer feedback loop compensating for this effect I believe this will disappear.

[shrit]

Okay, in this case, if I observe the issue I will add an outer feedback look to compensate. You can close this issue if there is nothing to add on the firmware side.