- IMU init requires valid published data (device ids, etc)
- orb_group_count will include advertised instances before data is published, so this can't be used to throttle IMU init attempts
* commander: send parachute command on termination
This sends the DO_PARACHUTE command to parachute component.
* commander: fix lying comments and printf
* commander: use one flag for termination triggered
This merges the duplicate flags _flight_termination_triggered and
_flight_flight_termination_printed.
* commander: correct variable name
* commander: always send tune with parachute
* commander: fix target_component for parachute cmd
The previous changes were wrong in that all commands were now sent to
the parachute component which doesn't make any sense. Of course only the
parachute command should be sent there.
For historical reasons, there is a check in EKF2 to only publish global
position if it has moved for 1mm.
This is no longer necessary, and also this if doesn't save any cpu cycles
in real conditions where GPS errors are always much bigger that this.
When using simulated or fake GPS, based on some other positioning
system, the GPS coordinate input can be very accurate due to quantization
or true accuracy. In this case this check bites and perfectly valid position
doesn't get published.
Just removed this if.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
When user override using the RC sticks is allowed, I would expect this
feature to also work in the case where GPS is lost and the vehicle goes
into a blind land/descent.
Without this commit, the vehicle would switch to Land mode and a pilot
could not take over control unless they switch to Altitude control in
a ground station.
With this commit, user override works as I would expect it and it will
switch to Altitude control allowing a pilot to recover in this
situation.
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.
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.
- 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.
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.
