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?)
* events: pass relative paths plus base path to source parser script
to work around maximum Makefile command lenght limits.
* events: correct cmake comment typo
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
---------
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
wait_until_altitude() checks for absolute altitude being
close so checking for 1m below the setpoint can fail
if the speedup results in no sample inside the altitude
window being checked.
Ideally the test could check if the takeoff is done directly
instead of comparing altitudes in the first place.
As discussed in the maintainer call we should adhere to the
parameter naming scheme that makes it clear what vehicle type the
configuration is good for.
by only applying the sqrt linear drag when brakeing.
It was originally not done this way to avoid discontinuities and
the exact speed bewlo 1m/s didn't matter. With the position slow mode
the exact slow speeds now matter. And the discontinuities are avoided by
reusing the brake boost filter.
The velocity smoothing library constrains the maximum vellocity.
I set the default constraint to 0 to find these exact issues.
The heading smoothing did not initialize the maximum velocity
which in this use case is the maximum heading.
So heading was always constrained to 0 -> north until this change.
The defintion of the custom symbol M_PI_PRECISE
was not included in one of the only places it's used.
Looks like a mistake that happened in
34c852255e
possibly because a lot of things are included
almost everywhere and if the include order
ligns up there are no compile errors.
Note that the unit test also passes without
thechange. But the VelocitySmoothing's
local_time would get NAN. This would leads to
wrong trajectory calculations.
Problem: Zero maximum jerk and/or zero
direction would lead to divisions by zero in
various cases depending on the exact configuration and code path.
Solution: There was already one check for the
direction being zero in one path and I
summarized to check in both
updateDurations...() functions the product
of direction * max_jerk to not be zero
because that's exactly the value calculations
devide by.
Matthias Grob