PositionControl: skip controller only if adjusted thrust setpoint are… #11056
Conversation
Stifael
commented
Dec 17, 2018
•
Stifael
commented
- consider landed if not armed
- vehicle_local_position_setpiont publication: follow the logic here to improve logging analysis
- do not publish the adjusted thrust setpoint from ground-contact/maybe-landed to simplify landed/maybe-landed analysis
- initialize the landed-structure with safe values
… not finite PositionControl: update comment about the order of thrust and position mc_pos_control: reset setpoints to NAN if required MulticopterLandDetector: consider to be landed if vehicle is not armed mc_pos_control: initialize landing struct with landed mc-pos-ctrl: adjust thrust-setpoint and yaw during ground-contact/maybe-landed without capturing that information within vehicle-local-position-setpoint topic because that information does not belong to user intention PositionControl: set local position/velocity setpoint to NAN if not used in the control pipeline mc-pos-ctrl: Fill vehicle_local_position_setpoint_s structure as follow: The message contains setpoints where each type of setpoint is either the input to the PositionController or was generated by the PositionController and therefore corresponds to the PositioControl internal states (states that were generated by P-PID). Example: If the desired setpoint is position-setpoint, _local_pos_sp will contain position-, velocity- and thrust-setpoint where the velocity- and thrust-setpoint were generated by the PositionControlller. If the desired setpoint has a velocity-setpoint only, then _local_pos_sp will contain valid velocity- and thrust-setpoint, but the position-setpoint will remain NAN. Given that the PositionController cannot generate a position-setpoint, this type of setpoint is always equal to the input to the PositionController. mc_pos_control: switch to designated initializer for landed It's less error prone because it produces an error on every discrepancy.
MaEtUgR
force-pushed
the
position-ctrl-vehicle-local-pos-improvement
branch
from
88e3775 to
a1a2c2f
Compare
|
rebased for the fmu-v2 savings and hopefully CI passing |
NaN is now used to indicate velocity-control only. See PX4/PX4-Autopilot#11056
There was a problem hiding this comment.
Looks good. Flight Review is updated: PX4/flight_review@2ba9648.
@PX4/testflights can you test this?
| @@ -55,8 +55,25 @@ void PositionControl::updateState(const PositionControlStates &states) | |||
| _vel_dot = states.acceleration; | |||
| } | |||
|
|
|||
| void PositionControl::_setCtrlFlagTrue() | |||
There was a problem hiding this comment.
How about void PositionControl::_setCtrlFlag(bool value)?
There was a problem hiding this comment.
true. not sure what I was thinking
There was a problem hiding this comment.
@MaEtUgR will do the change. thanks
|
Thanks to @bkueng! The review comment will be addressed in my follow up pr. |
@Stifael Quick post-merge question... How exactly does this PR simplify landed/maybe-landed analysis? I'm asking because I just had a case where ground-contact was detected inadvertently, causing the xy thrust set to zero resulting in a crash. If the thrust is logged unchanged this will be even harder to debug..(?) |
|
@bramsvs with this PR vehicle_local_position_setpoint now always agrees with the logic here, even during landing. However, that does not change anything in terms of landing behavior. It is to note, that the vehicle_local_position_setpoint topic is so far only used to detect vehicle intention (upwards or downards motion). The vehicle_local_position_setpoint.thrust[0..2] is only used for logging. This means that when you look at vehicle_local_position_setpoint topic, the different messages should now agree with what the controller is using and spits out. |
|
Found a regression: #11197 |
