Previously when switching e.g. from stabilized from acro, the stabilized
flight task kept running and publishing setpoints.
Luckily it caused no problems, but the log showed arbitrary attitude
setpoints.
As there is only one bit used in 'flags', and it is only used in case
update_interval is not null, we can move the bit to UpdateIntervalData.
The size of UpdateIntervalData does not increase (on 32 bit).
Reduces RAM usage by 3.6KB (tested on a Pixracer).
- move the update after the integration: a new computed jerk has an impact at the next epoch only
- add jerk reduction in case of too large integration time: when a jerk of "min_jerk" during dt is too much
- add jerk reduction if the integration time is larger than the predicted one and that integrating that jerk would lead to an acceleration overshoot
- rename some variables
- do not set zero throttle during the entire back-transition because otherwise
we need to make the back-transition really short
- added ramping up of throttle setpoint during backtransition to avoid
step inputs
- back-transition ends after back-transition time and not when motors are fully
rotated updwards. previously the vehicle would enter hover mode at high speed
which was not handled well by the mc position controller
Signed-off-by: Roman <bapstroman@gmail.com>
* Add attitude sub to mc_pos_control for yaw usage.
* Initialize pos control _states struct.
* Remove unnecessary init for struct in mc pos ctrl.
* Only use att topic for yaw setting in FlightTask.
- fsync can be a long blocking operation, so we need to make sure the main
logger thread does not block during this time, when it tries to aquire
the mutex
- fixes calling fsync on an invalid file descriptor
This change has two effects:
1. We always acknowledge a param write no matter if the value was
actually changed or not. This is according to the spec:
https://mavlink.io/en/services/parameter.html#write-parameters
2. This fixes the bug where int32 parameters were not actually acked
because the memory of the param value was casted directly to float
and then compared. In the case of a int32 parameter set from 0 to 1
it would mean that the cast to float of the memory representation
was still 0 and therefore it was assumed to be "no change" and the
ack was omitted.
The rate controller is now run directly after a gyro publication, and
as soon as it publishes the actuator controls, the output driver (fmu/...)
runs.
Test on a Pixracer:
Reduces fmu control latency from 219us to 134us.
If we run the rate controller last (same order as before, just increase
the prio), the latency is 201us.
CPU load is unchanged.
The drawback is that the attitude to rate setpoint generation is delayed
by one cycle (4ms), but it will be reduced to 1ms as soon as we run at
1kHz.
Beat Küng