- IMU integration move from drivers (PX4Accelerometer/PX4Gyroscope) to sensors/vehicle_imu
- sensors: voted_sensors_update now consumes vehicle_imu
- delete sensor_accel_integrated, sensor_gyro_integrated
- merge sensor_accel_status/sensor_gyro_status into vehicle_imu_status
- sensors status output minor improvements (ordering, whitespace, show selected sensor device id and instance)
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².
- skip avionics rail voltage check when USB connected
- skip forced reboot on USB disconnect if circuit breaker set
- avionics voltage preflight check don't silently fail if system_power unavailble
- explicitly set supply check circuit breaker (CBRK_SUPPLY_CHK)
This adds a sitl target and aiframe configs for the r1_rover, which is a differential rover example for SITL rover. The model is based on the aion robotics r1 rover
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.
-decrease L1 period for tighter mission tracking in fw mode
- increase backtransition duration, we can now do this is we have active
deceleration control
Signed-off-by: RomanBapst <bapstroman@gmail.com>
@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.
