Before _was_landed was set to the same value as the current
_land_detector.landed, thus outside of the update condition,
_was_landed && !_land_detector.landed could never be true.
This affects setting the home position, which is now set upon arming AND
upon takeoff.
If arming and already !landed, _have_taken_off_since_arming will not be set
and thus auto-disarm after 10s will be triggered (with default config).
This can only happen due to quick state changes, as land detector generally
sets landed=true if !armed.
This moves the handling of the BAT%d_SOURCE param inside of the battery
library. Users of the library now pass the source instead of the flag
whether to publish. The battery library then checks if the source is
selected using the param and publishes accordingly.
Since we removed the strange system_source flag, we now need to look at
all batteries in commander.
For current estimation - I think - it makes sense to sum them up.
Previously if in a cycle only a disconnected battery status updated, the
battery health state would switch to unhealthy during that time.
Fixes intermittent 'Arming denied! Check battery' preflight failures on
v5x with 1 power module connected.
During the first few seconds after takeoff, the failure detector is allowed to
trigger motor lockdown.
This is done for safety reasons to detect tipping-over or unstable
tuning gains
The checks did previously only report the first failure (to not overload the radio link). As we are moving to buffered messages and higher bandwidth links this design choice is not any more in the best interest of the drone operator. We are now reporting all detected failures. To ensure architectural consistency more checks have been moved from the commander mainloop into the respective classes.
This enables us to have better situational awareness during development and when inspecting a system in the field as to which subsystem is currently faulty. These flags are from standard MAVLink and are not sufficient nor do they match well the actual critical path to a safe flight. This will be addressed in a second step with the addition of a new MAVLink message and new flags.
As we are checking the current pre-flight state and validate wether the system could be armed, we do not want to spam the console or user with continously failing checks. These checks are reported to the GCS separately and are processed and displayed there.
The implementation before this change had two timeouts, a hard-coded
timeout of 0.5 seconds as well as a by param configurable timeout with
certain failsafe actions set.
This change aims to fix two problems:
1. The hard-coded offboard timeout can be triggered easily with sped up
lockstep simulation. Since i t is hard-coded it can't be adapted to
the speed factor.
2. The offboard signal can time out but no action will be taken just
yet. This means we end up in an in-between stage where no warning or
failsafe action has happened yet, even though certain flags are set
to a timeout state.
This patch aims to fix this by unifying the two timeouts to the existing
configurable param. The convoluted double timeout logic is replaced by a
simple hysteresis.
For anyone that has previously not changed the default timeout param (0),
the param will now be changed to 0.5 seconds which reflects the
previously hardcoded time. For anyone with a specific timeout
configured, the behaviour should remain the same.
Also, going forward, timeouts lower than 0.5 seconds should be possible.
Regression from https://github.com/PX4/Firmware/pull/13613.
VEHICLE_CMD_COMPONENT_ARM_DISARM from CLI would enter the
ARMING_STATE_IN_AIR_RESTORE logic. This was never intended for disarming
(and leads to state machine transition failures), and IMO it is also not
intended for commands from CLI.
Regression from 6dec451bab, leading to
preflight failures not being reported at all. Only after a failed arming
attempt the messages would be sent. And for GPS check failures, in case
they are set to optional (default), arming would be possible, but switching
to position would be rejected w/o error.
We need to run the preflight checks periodically, but this at least restores
the previous behavior.
This was inverted, i.e. set to false in most cases, whereas it should be
true.
As a consequence, both powerCheck and airspeed.confidence checks were not
executed.
- landed, maybe_landed, or ground_contact required before the safety
button is able to disarm
- this reduces the risk of a faulty safety button triggering in regular
flight
The bulk of this change was tightly coupled and needed to be deleted in one pass. Some of the smaller changes were things that broke as a result of the initial purge and subsequently fixed by further eradicating unnecessary platform differences. Finally, I deleted any dead code I came across in the related files I touched while going through everything.
- DriverFramework (src/lib/DriverFramework submodule) completely removed
- added dspal submodule in qurt platform (was brought in via DriverFramework)
- all df wrapper drivers removed
- all boards using df wrapper drivers updated to use in tree equivalents
- unused empty arch/board.h on posix and qurt removed
- unused IOCTLs removed (pub block, priv, etc)
- Integrator delete methods only used from df wrapper drivers
- commander: sensor calibration use "NuttX version" everywhere for now
- sensors: update to px4_{open, read, close} instead of DevMgr wrapper (adc open for analog differential pressure)
- battery_status: update to px4_{open, read, close} instead of DevMgr wrapper (adc open for analog differential pressure)
- cdev cleanup conflicting typedefs and names with actual OS (pollevent_t, etc)
- load_mon and top remove from linux boards (unused)
- delete unused PX4_MAIN_FUNCTION
- delete unused getreg32 macro
- delete unused SIOCDEVPRIVATE define
- named each platform tasks consistently
- posix list_devices and list_topics removed (list_files now shows all virtual files)
Beat Küng