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².
There was a gap where the attitude controller already used the estimate
with a new reference but the last known attitude setpoint was still based
on the old reference. This leads to a big glitch on reset because until
the attitude setpoint gets updated the error is wrong and as large as the
attitude delta of the reset.
The last attitude setpoint that is known from the position controller
is now kept inside the AttitudeControl class such that we don't
keep the whole vehicle_attitude_setpoint struct and always copy over from
there to run an update step.
- only record start time on first run rather than init
- increase name length
- round average interval to nearest microsecond
- basic formatting consistency (google style guide)
* Add basic GPIO test app for R/W on pins from nuttx shell
* Add gpio command to fmu-v3 and fmu-v4
* Sanitize gpio commands by pin configs, --force to override
In particular this together with the previous commit reduces timesync
round-trip time spikes by more than 10ms, and makes it generally more
stable.
Other streams are reordered according to onboard priority.
The `_deadreckon_time_exceeded` flag is used in
`local_position_is_valid()`. This means that
`_params.valid_timeout_max` after startup, in my observed case 5
seconds, the local position switche from valid to invalid and then after
a while back to valid again.
With this fix, the local position is flagged invalid from boot and gets validated after the first aiding event.
Co-authored-by: Julian Oes <julian@oes.ch>
This is a workaround for a warning in GCC 10.1:
src/drivers/gps/devices/src/ubx.cpp:520:8: error: writing 4 bytes into a
region of size 0 [-Werror=stringop-overflow=]
Also see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91707
* ekf: disable xy accel bias learning before takeoff
As those biases are usually poorly observable before takeoff because
they are almost perpendicular to the gravity vector, learning is often
driven by noise and numerical issues. This results in incorrect bias
learning before takeoff when the drone is static on ground for a long
period of time.
* ekf: update unit test and change indicator
Matthias Grob