This reverts a previous change because we're not entirely sure about all
implications on various airframes. It makes sense to change this default
after the failsafe state machines have been consolidated and the various
failsafe behaviours are more predictable for all airframes (not just
multicopter).
I propose two changes to the battery failsafes:
1. Remove the return only mode because it means the drone is likely
to crash during RTL. I think this is not expected by users chosing
the option and therefore better not exposed as an option.
2. Make Return/Land the default battery failsafe because it is expected
that a drone does the right thing when battery is low.
Also, this changes the description of the Return/Land behaviour to make
the drop down menu less long and awkward in QGC.
Condition to enter the prearmed state, an intermediate state between disarmed and armed
* in which non-throttling actuators are active.
*
* @value 0 Disabled
* @value 1 Safety button
* @value 2 Always
It doesn't affect fixed wing flying anymore. I disabled it for the
deltaquad since I presume @sanderux prefers to have the feature disabled
even when flying in multicopter mode.
AAs discussed in the devcall this functionality is only useful for
rotary-wing (multicopter) flying since it's a big safety hazard to
accidentally bring a fixed wing out of an auto mode e.g. a mission
and fly away in a straight line or into an obstacle.
This param has no effect within the Firmware.
The param can be used for example:
* in log post processing to have context about the flight
* in ground stations to adapt the UI automatically
With this commit the use cases will be:
Success case:
- booting, no messages about OA, pre-arm check would fail if you try to arm and OA is not yet running
Fail case:
- if OA takes longer than timeout time defined in COM_ONB_BOOT_T, then an error message is triggered.
Signed-off-by: Claudio Micheli <claudio@auterion.com>
Since onboard controllers bootup times are hardware dependent, it makes sense to have the possibility to adapt timeout time according to the specific HW.
Signed-off-by: Claudio Micheli <claudio@auterion.com>
Since Timeout from onboard controller is something that does not require a lot of modifications there is no sense to having it parametrized.
Signed-off-by: Claudio Micheli <claudio@auterion.com>
Added COM_ONB_LOSS_T and COM_ONB_REG_T parameters to specify thresholds that triggers "onboard link lost" and "onboard link regained".
Signed-off-by: Claudio Micheli <claudio@auterion.com>
Major changes:
- Prevent "HIGH LATENCY DATA LINK LOST" message to appear if iridium telemetry is not used.
- Prevent "DATA LINK LOSS" mavlink messages flooding when QGC is open and then closed.
- Changed "DATA LINK REGAINED" condition (use _datalink_last_heartbeat_gcs insthead of _datalink_lost)
Signed-off-by: Claudio Micheli <claudio@auterion.com>
Switch to the high latency telemetry, if available, if every low latency link is lost. Switch back if any low latency link is regained. Only indicate that all links are lost if all high and low latency links are lost. Allow different timeouts for high and low latency links.
Jacob Dahl