Acceleration based control/feed-forward #14212

MaEtUgR · 2020-02-22T18:19:47Z

Describe problem solved by this pull request
More or less last step to finish splitting up and QAing #12072. It's based on #245 and introduces processing acceleration setpoints. This enables acceleration feed-forward which the jerk optimized flight tasks by @bresch immediately make use of. It also heavily reduces dependence between collective thrust and vehicle tilt making the demanded tilt less jerky when the altitude control output is changing.

Describe your solution
I make the velocity control output acceleration in m/s² which in theory would make the controller tuning more independent of the vehicle's thrust to weight ratio (~hover thrust) but for the initial introduction I introduce a scaling factor using the hover thrust to make the existing gains compatible. To separate the high-frequency altitude control changes from the collective thrust from the demanded tilt I'm switching control strategy to apply horizontal acceleration setpoints assuming hover/gravitational acceleration in the vertical direction effectively directly mapping it to the vehicle's tilt. The vertical acceleration gets projected onto the planned tilt and then executed by setting the collective thrust accordingly. Only in the limit case of more than the maximum thrust tilt gets coupled by being limited using vertical acceleration demand to ensure prioritizing altitude control over horizontal navigation.

Test data / coverage
For the basic limit cases, input combinations, failsafe and zero thrust inputs there are unit tests now. I did a lot of SITL testing and multiple outdoor tests with a 250 size, one test on a big multicopter.

Additional context
Refactorings that made this change possible: #13247, #13248, #13262, #13347, #13701, #14017

I still need to change the jerk limits for manual and auto since the tracking is tighter now.
I discussed with @Jaeyoung-Lim to expose the acceleration on the offboard interface to allow more dynamic flights and a different kind of input that doesn't rely on vehicle internal velocity estimate.

MaEtUgR · 2020-02-25T11:26:31Z

I rebased on master and removed the draft since the configuration default changes are also there.
It's maybe not ready for final testing because of flash problems?

Jaeyoung-Lim · 2020-02-26T07:39:42Z

@MaEtUgR I tried offboard acceleration feedforward with this PR, but couldn't enter offboard mode. Am I missing something?

I was sending on POSITION_TARGET_TYPEMASK=0 on POSITION_TARGET_LOCAL_NED.

WARN  [mc_pos_control] Altitude-Ctrl activation failed with error: Activation Failed

Same offboard setpoint works on master, but enabling acceleration setpoints introduces hunge tracking errors.

To benchmark the performance I am sending POSITION_TARGET_LOCAL_NED and sending position, velocity, accleleration to follow a circular trajectory. Here are the logs in SITL.:
Acceleration enabled in Offboard
Acceleration ignored in Offboard

MaEtUgR · 2020-02-26T10:46:04Z

@Jaeyoung-Lim Thanks for testing offboard!!
The provided logs show that instead of actually setting acceleration the normalized collective thrust vector is set to the value you probably want to give in m/s^2

I presumably fixed that with this pr: https://github.com/PX4/Firmware/pull/14212/files#diff-f58f83b125f08a9604e2b91bb9f94b1bL231-L233

I don't know why you can't enter offboard mode, maybe we can have a quick look together to get a clue?

Jaeyoung-Lim · 2020-02-26T10:53:36Z

@MaEtUgR Ah, sorry for not being clear. That was the logs from master since I couldn't make it go in offboard mode with this PR. Would be great if we can dig in!

Jaeyoung-Lim · 2020-02-26T15:03:07Z

@MaEtUgR Disarming shortly after arming in offboard mode : Log

dannyfpv · 2020-02-28T23:27:00Z

tested on pixhawk4 v5 f-450
Modes Tested*

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
go to: Good.
RTL: Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL

Notes:
No issues noted, good flight in general.

Log:
https://review.px4.io/plot_app?log=d2109f81-1651-4b5d-91de-92147ee43378

Junkim3DR · 2020-02-29T04:26:18Z

Tested on NXP FMUK66 v3

Modes Tested

Mission Plan Mode (Automated):
Good.Go To Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Note: Vehicle was sent to a "Go To" point then RTL was triggered
Arm and Take off in mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once all waypoints are completed make sure vehicle triggers RTL.

Notes
Good flight in general.

Logs
https://review.px4.io/plot_app?log=b3dfd093-4eb9-457b-9723-ddbe76de9ccf

Tested on Pixhawk 3 v4Pro

Modes Tested

Mission Plan Mode (Automated):
Good.Go To Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Note: Vehicle was sent to a "Go To" point then RTL was triggered
Arm and Take off in mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once all waypoints are completed make sure vehicle triggers RTL.

Notes
Good flight in general.

Logs
https://review.px4.io/plot_app?log=c8254650-1392-4e7a-94fc-de6d030a939f

jorge789 · 2020-02-29T15:51:31Z

Tested on PixRacer V4

Tested Modes

Position Mode
Mission plan mode (automated):
Good. Go to (Automated) mode: Good.
RTL (Back to Earth): Good.
Process
Note: the vehicle was sent to a "Go to" point in the middle of mission and then RTL was activated
Assemble and take off in Position mode after flying one minute, switch to mission plan, then make sure the vehicle follows all the waypoints as shown in QGC, once all waypoints are completed, make sure of the vehicle activating RTL.

Notes
Good flight overall.

Logs
https://review.px4.io/plot_app?log=7286d189-3cdf-4a76-aa01-2edfe1a6633d

https://review.px4.io/plot_app?log=6aa51b7b-f999-4aea-bcdd-1a4cb0bde0ac

Tested on CUAV nano V5

Tested Modes

Position Mode
Mission plan mode (automated):
Good. Go to (Automated) mode: Good.
RTL (Back to Earth): Good.
Process
Note: the vehicle was sent to a "Go to" point in the middle of mission and then RTL was activated
Assemble and take off in Position mode after flying one minute, switch to mission plan, then make sure the vehicle follows all the waypoints as shown in QGC, once all waypoints are completed, make sure of the vehicle activating RTL.

Notes
Good flight overall.

Logs
https://review.px4.io/plot_app?log=ac76803a-1689-420b-9516-fb67c423614c

https://review.px4.io/plot_app?log=d12827ac-cfd1-48d1-babe-b85b10c54264

MaEtUgR · 2020-03-01T13:56:25Z

@dagar As we discussed I rebased (without conflict) and removed the in my eyes deprecated FlightTaskSport to make it fit in the flash of the omnibus. Here's the commit message explaining:

This mode was just kept as an example after
its usage in a single case. It's basically untested
and doesn't make much sense anymore since it's
incompatible with the jerk limited trajectory
implementations. The implementation only switched
the configuration parameter of the velocity resulting
from maximum stick deflection to be
MPC_XY_VEL_MAX instead of MPC_VEL_MANUAL.
This is according to todays understanding undesired
because when hitting that limit the position
controller has no room for corrections anymore.

Also it saves some flash space on omnibus to remove
the task at this point and makes romm for the
acceleration feed-forward.

EDIT: I think now CI is showing the offboard problem that @Jaeyoung-Lim saw before.

MaEtUgR · 2020-03-04T13:16:43Z

I rebased on master and tried to reproduce the offboard issues by using the MAVSDK offboard integration tests:
./build/src/integration_tests/integration_tests_runner --gtest_filter="SitlTest.Offboard*"
But they all pass and seem to be doing what is expected looking at the simulation UI.

What do the two different errors I had come from, could they be glitches?
before rebasing: http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-SITL_tests/detail/PR-14212/6/pipeline
after rebasing: http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-SITL_tests/detail/PR-14212/7/pipeline

Now also jenkins seems to cancel my build NuttX builds only one shows in the UI and whole test fails even though the GitHub workflow builds succeed and "dronecode-macmini" cannot be contacted for the Mac build.

hamishwillee · 2020-03-05T01:20:10Z

@MaEtUgR Any docs impact to all this?

MaEtUgR · 2020-03-05T20:33:50Z

@hamishwillee Good point. Sport mode was never documented since it wasn't too different. But the control diagram https://dev.px4.io/master/en/flight_stack/controller_diagrams.html#multicopter-position-controller needs to be adjusted a little bit. Time to look into how these diagrams 😬

MaEtUgR · 2020-03-06T07:09:17Z

I was able to reproduce what CI is flying and it found a real issue that I'm currently looking into.

MaEtUgR · 2020-03-28T20:46:21Z

@bresch Here's the plot of the same scenario including velocity tracking. Note that it's not tracking anymore because it's hitting the maximum tilt limit and the integrator is still not winding up:

Log: https://logs.px4.io/plot_app?log=40bbbfcc-7db9-4667-ac18-b735745235e0

Rebased on master and lowered the maximum jerk in the VTOL defaults based on @fury1895's valuable VTOL testing feedback 🎉 . That concludes testing and fixes from my side and I consider it ready to merge 👍

bresch

Awesome!

Before #14212 the velocity control gains used in the multicopter position controller were defined as a scale between velocity error in one axis (or it's integral and derivative respectively) and the unit thrust vector. The problem with this is that the normalization of the unit thrust vector changes per vehicle or even vehicle configuration as 0 and 100% thrust get a different physical response. That's why the gains are now defined as scale between velocity error (integral/derivative) and the output acceleration in m/s².

Jaeyoung-Lim · 2020-05-17T18:34:40Z

@MaEtUgR Maybe this is too late, but I have tried this with offboard control, but this doesn't seem to work with offboard control.

MaEtUgR · 2020-05-18T13:07:43Z

@Jaeyoung-Lim It's never too late. Is there an easy way to reproduce such that we can find the issue?

Jaeyoung-Lim · 2020-05-18T13:24:38Z

@MaEtUgR You can use the ROS node I created, but if this is too much overhead I can also create a simple mavsdk app for testing

MaEtUgR · 2020-05-18T13:29:55Z

I can also create a simple mavsdk app for testing

I think that would be useful not just for me but also to put in CI to make sure it does not break again.

Before #14212 the velocity control gains used in the multicopter position controller were defined as a scale between velocity error in one axis (or it's integral and derivative respectively) and the unit thrust vector. The problem with this is that the normalization of the unit thrust vector changes per vehicle or even vehicle configuration as 0 and 100% thrust get a different physical response. That's why the gains are now defined as scale between velocity error (integral/derivative) and the output acceleration in m/s².

The acceleration setpoint gets implicitly inherited from the altitude flight task since #14212. This feed-forward adds an unwanted acceleration when the right stick is deflected. Instead I'm using it to command the expected centripetal acceleration when flying in a circle for better orbit tracking.

Before #14212 the velocity control gains used in the multicopter position controller were defined as a scale between velocity error in one axis (or it's integral and derivative respectively) and the unit thrust vector. The problem with this is that the normalization of the unit thrust vector changes per vehicle or even vehicle configuration as 0 and 100% thrust get a different physical response. That's why the gains are now defined as scale between velocity error (integral/derivative) and the output acceleration in m/s².

The acceleration setpoint gets implicitly inherited from the altitude flight task since PX4#14212. This feed-forward adds an unwanted acceleration when the right stick is deflected. Instead I'm using it to command the expected centripetal acceleration when flying in a circle for better orbit tracking.

MaEtUgR added Admin: Enhancement (improvement) 💡 Multirotor 🛸 labels Feb 22, 2020

MaEtUgR added this to the Release v1.11.0 milestone Feb 22, 2020

MaEtUgR requested a review from bresch February 22, 2020 18:19

MaEtUgR self-assigned this Feb 22, 2020

MaEtUgR force-pushed the acceleration-control branch from e7ff219 to 78c3f1d Compare February 22, 2020 18:51

weekly-digest bot mentioned this pull request Feb 23, 2020

Weekly Digest (16 February, 2020 - 23 February, 2020) #14213

Closed

MaEtUgR force-pushed the acceleration-control branch from 78c3f1d to bb48644 Compare February 25, 2020 11:24

MaEtUgR marked this pull request as ready for review February 25, 2020 11:25

Jaeyoung-Lim mentioned this pull request Feb 26, 2020

Test offboard acceleration feedforward setpoints in PX4 Jaeyoung-Lim/mavros_controllers#120

Merged

MaEtUgR force-pushed the acceleration-control branch from bb48644 to e0b9e5a Compare February 26, 2020 16:51

MaEtUgR mentioned this pull request Feb 26, 2020

vehicle_attitude_setpoint: get rid of unused q_d_valid flag #14248

Merged

bresch mentioned this pull request Feb 27, 2020

PID autotuner for velocity loop #12479

Closed

2 tasks

weekly-digest bot mentioned this pull request Mar 1, 2020

Weekly Digest (23 February, 2020 - 1 March, 2020) #14268

Closed

MaEtUgR force-pushed the acceleration-control branch from e0b9e5a to 9e84122 Compare March 1, 2020 13:52

MaEtUgR force-pushed the acceleration-control branch from 9e84122 to 09681c7 Compare March 4, 2020 12:46

MaEtUgR force-pushed the acceleration-control branch from 09681c7 to 5f0a4a0 Compare March 4, 2020 13:18

MaEtUgR dismissed bresch’s stale review via 7131d7c March 28, 2020 20:41

MaEtUgR force-pushed the acceleration-control branch from 4aaad24 to 7131d7c Compare March 28, 2020 20:41

bresch approved these changes Mar 30, 2020

View reviewed changes

MaEtUgR merged commit bda0725 into master Mar 30, 2020

MaEtUgR deleted the acceleration-control branch March 30, 2020 07:58

This was referenced Apr 21, 2020

Multicopter velocity control gains backwards compatibility depends on hover thrust #14720

Closed

PositionControl: deconflict velocity control gains from thrust #14749

Merged

MaEtUgR mentioned this pull request Jul 13, 2020

FlightTaskOrbit: correct acceleration feed-forward #15320

Merged

Jaeyoung-Lim mentioned this pull request Sep 8, 2020

Enable acceleration setpoint based takeoff #15707

Closed

MaEtUgR mentioned this pull request Oct 26, 2020

Intuitive manual position control by mapping stick input to acceleration #16052

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Acceleration based control/feed-forward #14212

Acceleration based control/feed-forward #14212

MaEtUgR commented Feb 22, 2020 •

edited

Loading

MaEtUgR commented Feb 25, 2020 •

edited

Loading

Jaeyoung-Lim commented Feb 26, 2020 •

edited

Loading

MaEtUgR commented Feb 26, 2020

Jaeyoung-Lim commented Feb 26, 2020 •

edited

Loading

Jaeyoung-Lim commented Feb 26, 2020

dannyfpv commented Feb 28, 2020

Junkim3DR commented Feb 29, 2020 •

edited

Loading

jorge789 commented Feb 29, 2020

MaEtUgR commented Mar 1, 2020 •

edited

Loading

MaEtUgR commented Mar 4, 2020

hamishwillee commented Mar 5, 2020

MaEtUgR commented Mar 5, 2020

MaEtUgR commented Mar 6, 2020

MaEtUgR commented Mar 28, 2020 •

edited

Loading

bresch left a comment

Jaeyoung-Lim commented May 17, 2020

MaEtUgR commented May 18, 2020

Jaeyoung-Lim commented May 18, 2020

MaEtUgR commented May 18, 2020

Acceleration based control/feed-forward #14212

Acceleration based control/feed-forward #14212

Conversation

MaEtUgR commented Feb 22, 2020 • edited Loading

MaEtUgR commented Feb 25, 2020 • edited Loading

Jaeyoung-Lim commented Feb 26, 2020 • edited Loading

MaEtUgR commented Feb 26, 2020

Jaeyoung-Lim commented Feb 26, 2020 • edited Loading

Jaeyoung-Lim commented Feb 26, 2020

dannyfpv commented Feb 28, 2020

Junkim3DR commented Feb 29, 2020 • edited Loading

Tested on NXP FMUK66 v3

Tested on Pixhawk 3 v4Pro

jorge789 commented Feb 29, 2020

Tested on PixRacer V4

Tested on CUAV nano V5

MaEtUgR commented Mar 1, 2020 • edited Loading

MaEtUgR commented Mar 4, 2020

hamishwillee commented Mar 5, 2020

MaEtUgR commented Mar 5, 2020

MaEtUgR commented Mar 6, 2020

MaEtUgR commented Mar 28, 2020 • edited Loading

bresch left a comment

Choose a reason for hiding this comment

Jaeyoung-Lim commented May 17, 2020

MaEtUgR commented May 18, 2020

Jaeyoung-Lim commented May 18, 2020

MaEtUgR commented May 18, 2020

MaEtUgR commented Feb 22, 2020 •

edited

Loading

MaEtUgR commented Feb 25, 2020 •

edited

Loading

Jaeyoung-Lim commented Feb 26, 2020 •

edited

Loading

Jaeyoung-Lim commented Feb 26, 2020 •

edited

Loading

Junkim3DR commented Feb 29, 2020 •

edited

Loading

MaEtUgR commented Mar 1, 2020 •

edited

Loading

MaEtUgR commented Mar 28, 2020 •

edited

Loading