This fixes a tricky bug that we discovered in MAVSDK:
https://github.com/mavlink/MAVSDK/pull/1464
It turns out the target_system and target_component fields can
potentially be:
1. at the end of a message payload,
2. and zero,
and therefore they get trimmed. When you then try to read it you
potentially read some garbage from the CRC fields.
The hrt_abstime value used to control the 1s pub rate was the value of
the timestamp_usec of the CanardTransfer, which has a timeout of 100ms
added to it.
Since hrt_abstime is an unsigned datatype, if the hrt_elapsed_time()
check was called <100ms apart, the negative value would result in a
large hrt_elapsed_time, and the bus would be spammed with Heartbeat
messages (or error messages from canardTxPush).
This logic was introduced to avoid large altitude drifts in velocity
mode (altitude not controlled) due to potential velocity estimate bias
in case of IMU problems (see PR #8445). After some refactorings,
the logic started to be used in altitude-controlled modes as well, which is not needed.
* Update to use libcanard callback
Reworked param system with lambda
* Use callback instead of lambda saves 500 bytes of flash
* [UAVCANv1] Added ServiceRequest class, subscribers decoupled
* PX4 UAVCANv1 portID param default CANARD_PORT_ID_UNSET (65535U)
* [UAVCANv1] uORB sensor_gps modify timestamp for now untill we've got timesync working
* UAVCANv1 update parameter definition to use -1 as unset
- avoids tecs always climbing and sinking and max rates and allows to fine tune these rates
- avoid numerical calculation of feedforward velocity using derivative, this
was prone to jitter in dt
Signed-off-by: RomanBapst <bapstroman@gmail.com>
This makes sure that the vehicle_command topic is properly
initialized from the beginning.
orb_exists returns -1 or 0 and not a bool as one would expect.
- Updating PWM params on param change was interfering with VTOL
parameter settings (e.g. PWM_MIN is set by VTOL at init, and
was then overwritten here after an arbitrary param change).
Only update PWM params on initialisation.
Updating PWM params on param change was interfering with VTOL
parameter settings (e.g. PWM_MIN is set by VTOL at init, and
was then overwritten here after an arbitrary param change).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This fixes a regression introduced in
https://github.com/PX4/PX4-Autopilot/pull/16646
which meant that the acceptance radius was no longer used at all for
multicopter, and instead only the NAV_ACC_RAD param was used.
With this change we use the acceptance radius of the mission item again
if it is actually set (and not NAN) which we did not do before, and we
only do that for multicopter.
- apply sensor scaling immediately to keep things simple (FIFO vs regular)
- inline filter helpers (minor performance improvement)
- dynamic notch filtering
- reorder by axis (applied per axis)
- don't remove notch filters immediately if ESC or FFT data times out
- constrain notch filter frequency and bandwidth to safe range (minimum bandwidth for flaot precision, Nyquist, etc)
- add safe constraint on dt
- merge NotchFilterArray into regular NotchFilter (apply vs applyArray)
- only use direct form 1 to prevent reset confusion
- safe default field initialization
- update VehicleAngularVelocity usage
- use WelfordMean library to determine sensor sample rate average
- if gyro samples exceeds queue depth, instead round to nearest even integer to ease scheduling
- force update if publication latency is falling behind
- remove redundant sample interval perf counters
- status print accel & gyro interval standard deviation
Peter van der Perk