Instead of tracking a fixed deceleration setpoint during the backtransition we added here position feedback,
such that the vehicle comes to a stop latest at the current position setpoint. This reduces the risk of
overshooting the landing point.
If no position feedback/position setpoint is present the old logic still applies.
It further moves the braking controller to the FlightTaskTransition instad of doing it in
the VTOL attitude mode.
* vtol_type: added position feedback to backward transition
* FlgithTaskTransition: refactored backtransition deceleration/pitch setpoint computation
* FlightTaskTransition: minor improvements
* FlightTaskTransition: use .dot() consistently and remove unnecessary comments
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: Silvan Fuhrer <silvan@auterion.com>
* uavcan: add GNSS heading from relposheading
* ekf2: new EKF2_GPS_YAW_OFF parameter to configure any offset in GNSS heading
Signed-off-by: dirksavage88 <dirksavage88@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The likelyhood can be really small when the innovation is suddenly
large. This can occur during a GNSS velocity glitch and shouldn't reset
the filter as it would bring it back to a really vulnerable state.
This fixes an issue where we dropped acks that we should have sent out
just because the queue was clogged with acks that have nothing to do
with us and just happen to be sent to us. We should just ignore them and
not publish them to uORB.
We should not send out acks for commands that are not targetted at us.
This can confuse other MAVLink components and MAVLink commands just
don't scale that way, and it unnecessarily fills up our ack queue.
This was likely introduced to debug when MAVLink components were
implemented incorrectly sending commands to a wrong target.
The most we should do in this case is to print/log an info.
The issue is that when the HAGL is low, the drone will usually
decelerate and then the check would run anymore. If the low HAGL
estimate is due to bad sensor readings (e.g.: reflections), it will be
stuck in that state.
Without this change the configured dialect would not get included
correctly in the simulator_mavlink module, only in the main mavlink module.
Configured using e.g. CONFIG_MAVLINK_DIALECT="development"
in e.g. boards/px4/sitl/default.px4board file.
* param: add a newline for the output of param show -q
Otherwise the output doesn't get flushed and doesn't show.
* param: remove deprecated PARAM_PRINT for QURT
We're not carrying platform defines in applications.
* SDLOG_ALGORITHM - AES option not implemented
* Update src/modules/logger/params.c
Co-authored-by: Daniel Agar <daniel@agar.ca>
---------
Co-authored-by: Daniel Agar <daniel@agar.ca>
The simulated attitude can disturb the gimbal estimator and lead to strange behavior of the gimbal. So, since the hardware is not moving in HIL/SIH, we fake a static attitude towards the gimbal.
* RTL Direct: fix rlt time prediction in final lanidng phase
It was previously checking if RTL was already running through
active(), which though actually is coming from the mission mode
that rtl_direct inherits from.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL Direct: remove unnecessary active() check
As the method setRtlPosition() is anyway not called when RTL is active,
plus it checks the wrong thing, as it is the active() method from
the Mission mode.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL Direct: remove unnecessary land_detector_sub.update()
It is already getting updated just before the .get()
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL time estiate: do not distinguish land from sink for MC
To avoid rtl time prediction jump when entering LAND phase due
to no correct handling of loiter altitude (LAND phase doesn't
have to start only when lower then RTL_DESCND_ALT).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Revert "RTL Direct: remove unnecessary active() check"
This reverts commit d5165ba902e65839e792cc13197761c7f77748f9.
* Revert "RTL Direct: fix rlt time prediction in final lanidng phase"
This reverts commit 5af7c928fbf86d560dcd35dd9aea3e38f1e4c735.
* RTL: Make sure to call the initialilze function of the Navigator RTL modes
* RTL: use the navigator_mode run function instead of the on_xxx function directly
* RTL: Make sure that for vtol the right vehicle type is used for each RTL state
* RTL: move to loiter distance estimate should substract the loiter radius for fixed wing
* RTL: time prediction: do not assume VTOL is in FW at start of RTL
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL: time estimation: fix is_in_climbing_submode
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL: time estimation: subtract loiter radius from distance in rtl_direct_mission_land
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL direct: poll important topics also on_inactive such that time estimate is correct
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* navigator rtl: fix setter spacing
* navigator rtl: check pointer before dereferencing
* RTL: only subract loiter radius when in FW
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: Konrad <konrad@auterion.com>
Co-authored-by: Matthias Grob <maetugr@gmail.com>
- fully absorb the libuavcan submodule (renamed libdronecan to deconflict) up to our last good working commit and preserve all history (upstream libuavcan was broken and then marked deprecated)
- fixes https://github.com/PX4/PX4-Autopilot/issues/23727
- this puts us in a much better position to be able to evolve the library going forward ow that we have full control in tree
RomanBapst