If the user disconnects USB we reboot the system to bring it back into a nominal condition before arming. Otherwise we would either have the USB stack running without a cable connected (code running for no reason, which is violating the principle of not running unnecessary code in aviation). Or we would not allow to arm at all if USB was ever connected, which can be confusing if the system is powered off a battery.
- this doesn't currently change anything, but gets us ready to start
experimenting with using the small amount of instruction tightly memory
on STM32F7
- the .ramfuncs section works with NuttX CONFIG_ARCH_RAMFUNCS
Only have it higher for VTOL and fixed wing.
Multicopter position controlled flight is in our experience always <1g.
Acrobatic flying definitely exceeds the acceleration but if control
doesn't rely on the GPS velocity and position there shouldn't be any
problem.
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.
When disconnecting USB poll returns successfully, but the read returns
-1 with ENOTCONN.
In addition this also ensures there's no busy loop when poll returns an
error.
MAVLink continues to work after reconnecting USB.
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.
This fixes the issue where the last lines of the log output was not
printed in case of error or on the verbose setting. This meant that
essentially the actual test error was not printed.
The fix involves two parts:
1. Firstly collect the output again even if a process has exited.
2. Collect all lines at once and not one line per iteration.
Lorenz Meier