- in practice this is mostly useful for identifying incorrect rotations
which we mostly have in 45 degree increments
- handling a vehicle on the ground can easily disturb one mag by more than 30 degrees, so this is often distracting noise
- the values of the parameters GND_MAX_ANG and GND_WHEEL_BASE are outdated. They belonged to another Rover setup.
- in the mixer file rover_diff_and_servo.main.mix the steering was controlled by roll, but in PX4 rover steering is controlled by yaw. And this was the reason why the attitude control did not work correctly
- the DF Robot GPX:Asurada rover has actual a steering angle of 60 degrees. And and wheel base of 0.17m. Parameter values in the airframe file are changed to this values
- avoids the need for ekf2_timestamp publications by q and lpe
- adds logger to the lockstep cycle and makes it poll on ekf2_timestamps
or vehicle_attitude. This avoids dropped samples (required for replay).
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².
Only have it higher for VTOL and fixed wing.
Multicopter position controlled flight is in our experience always <1g.
Acrobatic flying definitely exceeds the acceleration but if control
doesn't rely on the GPS velocity and position there shouldn't be any
problem.
@fury1895 reported very valuable feedback from testing
the acceleration feed-forward on VTOL:
> MPC_JERK_MAX 4.5 (from 5 on it felt too aggressive)
> MPC_JERK_AUTO 4
> some hovering, some transitions, and a mission. Everything good.
> I'd say you feel the difference in position mode and you see it in
> Auto modes. Great improvement!
rc.io is called from 2 places in rc.interface:
- if [ $OUTPUT_MODE = io -o $OUTPUT_MODE = uavcan_esc ]:
- 'set OUTPUT_MODE io' is only set within USE_IO=yes, so removing
the check in rc.io has no effect.
- in case of UAVCAN, we also want the IO for RC, now covered in the next
case.
- Further down ('Start IO for RC input if needed.').
This is intended to start IO for RC only, when fmu is already started.
However the previous check '$USE_IO = yes' in rc.io prevented that.
In addition we don't start rc_input in case of $USE_IO = no.
Fixes no RC on Pixhawk 2 with SYS_USE_IO=0.
