-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use velocity_setpoint for feedforward instead of constraint #14155
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Tested on PixRacer V4Flight Card 2 Modes Tested Procedure Armed form QGC. Logs: Log: Tested on CUAV nano V5:Flight Card 2 Modes Tested Procedure Armed form QGC. Logs: Log: |
Tested on pixhawk4 v5 f-450 Modes Tested Procedure Armed form QGC. Logs: |
6f9ad0f
to
4218771
Compare
Thanks @jorge789 @dannyfpv , looks like there's an issue. It seems using the existing contraints causes problems because it is later used in mc_pos_control, and when it step-changes later on, this causes a step in power straight from the controller. Unfortunately I think this will need a different approach. |
4218771
to
c649d33
Compare
// emulate the motor ramp (also done in the controller) so that the controller can actually track the setpoint. | ||
if (_type == WaypointType::takeoff && _dist_to_ground < _param_mpc_land_alt1.get()) { | ||
z_vel_constraint = _param_mpc_tko_speed.get(); | ||
z_accel_constraint = math::min(z_accel_constraint, _param_mpc_tko_speed.get() / _param_mpc_tko_ramp_t.get()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI @bresch This fixes the tracking while the controller is doing the velocity ramp with constraints.
Before:
https://review.px4.io/plot_app?log=0b49ba68-dd07-4bbb-9f91-1ac0a8aee33f
After:
https://review.px4.io/plot_app?log=a703e396-eddd-420d-8815-4f4f85b09422
@PX4/testflights Could you give this another test? Same as before, run a mission that includes a takeoff and a landing. |
Tested on pixhawk4 v5 f-450 Modes Tested Procedure Armed form QGC. Logs: |
Tested on PixRacer V4Flight Card 2 Modes Tested Procedure Armed form QGC. Logs: Log: Tested on CUAV nano V5:Flight Card 2 Modes Tested Procedure Armed form QGC. Logs: Log: |
Thanks @jorge789 @dannyfpv , looking good now. This PR also fixes the velocity overshoot on takeoff, since that was a problem before: @bresch this is ready for review. Not 100% happy with where I had to put the logic, but I don't see a better way of doing it considering that the constraints introduce tracking problems. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just change alt1 to alt2 and this is ok. Having to check the WP type in the flight task isn't great, but you can't have a better solution without more changes. Sorry, I was confused because we have a ramp between alt1 and alt2 in position mode. We can update the logic later if needed.
src/lib/flight_tasks/tasks/AutoLineSmoothVel/FlightTaskAutoLineSmoothVel.cpp
Show resolved
Hide resolved
2e707d4
to
7ec42ed
Compare
7ec42ed
to
a5fb513
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
Unfortunately the constraints cannot be implemented using the _constraints because the controller uses that directly. This causes discontinuities in the velocity and/or accel at various points of the flight. In particular this was used in Takeoff. Instead this was done by changing target accel/velocity in the jerk-optimal velocity planner for Z.
a5fb513
to
abb4873
Compare
This is a very nice improvement, we should move the takeoff and landing logic to be used within the flight task. That would leave no unexpected/external setpoint adjustment between task setpoint and position control. |
Describe problem solved by this pull request
We want to be able to track a moving setpoint from the avoidance interface. However, right now velocity setpoints are used as constraints, which prevents their being used for the feedforward term to be able to specify the position setpoint as a moving target
Describe your solution
Use the _velocity_setpoint as a feedforward (which the name would imply), instead of using it as a constraint.
Use the _constraints to constrain the takeoff velocity, which was the only usage of the velocity setpoint term for contraining velocities from position setpoints before._constraints is used in mc_pos_control which introduces lots of discontinuities.Ported the the only previous usage of the velocity constraint (takeoff speed) in the FlightTaskAutoLineSmoothVel. When the _constraints are removed from mc_pos_control this small code block can be moved to FlightTaskAutoMapper instead, and the constraints passed through via a constraints struct instead.
Test data / coverage
Test flown a bunch in SITL. Everything seems to behave exactly as it did before.
@PX4/testflights could you do some flights here? Specifically, make sure auto-takeoffs for missions seem the same as they were before.