The default implementation for multicopter Position mode is FlightTaskManualAcceleration.
The last missing piece was support for CollisionPrevention in this implementation.
The default implementation for multicopter Position mode is FlightTaskManualAcceleration.
The last missing piece was support for CollisionPrevention in this implementation.
Failing checks caused failsafe flags to stay true when enabling the circuit breaker but not rebooting.
Resetting the failsafe flags state when the circuit breaker is set resolves this issue.
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.
This happens when BAT_CRIT_THR allows arming with a critical battery level. With this change it still fails the checks but only warns instead of doing the failsafe action because that would immediately land the vehicle before it has taken off.
This was already done before the refactor and was assumed to not be necessary.
The problem is that these mission items result in a strang looking vertical slow down directly followed
by an acceleration during the landing phase.
This adds explicit handling for the few things we want to allow through a MAVLink instance dedicated to a gimbal/(camera) payload as per the MAVLink gimbal mode configuration.
- the module documentation parser can only resolve defines from the same file
- also it cannot deal with defines embeded in strings
- what board should it add for the general documentation anyways?
As a result of these issues I suggest to stay with the original hardcoded
/fs/microsd for the documentation. It's still the most common path as far as
I can see.
battery failures can occur upon arming when the load gets sgnificant.
In that case the safest thing to do is prevent a takeoff before anything
worse happens.
We had a case where someone took off with an experimental
system with 100% RAM usage on the embedded system
without noticing. This lead to problems during flight.
Since we already have a CPU load check it seems natural
to also check the reported RAM usage.
Without this flag the command silently succeeds even though the logs contains
an error. It's much more developer friendly to fail early in case of an error.
The log path is then also shown in the console output.
The case where the airframe maintainer wants to enforce a reset to airframe is
not covered anymore with the `param set-default` mechanism. For products based
on PX4 this is still required to ensure proper functionality after a major update.
This is a minimal change to make it harder to crash a
vehicle with an empty battery if the capacity was set wrong.
The disadvantage is that the state of charge estimate will
fluctuate more under load.
We need better documentation and improvements to the estimation.
The existing disarmed logic already handles disabled outputs
it makes sense to reuse it and not have lockdown handled
differently resulting in unexpeced corner cases.
This removes the duplication with unexpected differences
and allows to consistently handle the output instead of
overriding the output for some specific cases which
leads to unexpected corner cases. E.g. disabled outputs
suddenly outputing PWM in lockdown.
In HITL the actuators should not be mapped
and they are in lockdown.
We should not reconfigure disarmed, min, max PWM values
without updating the actual output values because the IO
will consider the last outputs before the FMU was rebooted
with the configuration of the new boot. This can result
in spinning motors when switching to SIH.
This matters for PWM when the last output gets disabled on either FMU or IO
it would just keep on running.
Also when rebooting with a parameters reset or new airframe with no mapped outputs
it would previously keep outputting PWM with the disarmed value of the new airframe
e.g. 1000us which is a safety hazard because servos could break the physical limit of the
model or miscalibrated ESCs spinning motors.
If the output is set to 0 then the FMU had this channel disabled/no function mapped
to it. In that case we do not want to suddenly start outputing failsafe or disarmed
signals.
This is a workaround to hotfix CI but the root cause is #22792
(MAVSDK test failing after EKF change, accelerometer simulation issues not learned anymore?)
Matthias Grob