This fixes a case where the px4 startup is not stopped when the
px4 process is killled using -SIGKILL against the px4 deamon.
In that case, the currently executing command/client is killed
and properly shutting down with result -1, however, the next command
is started anyway.
This means that the next time we try to run the simulation we get a
"PX4 daemon already running for instance 0" error and PX4 doesn't start
properly.
By adding exit on error, we properly exit in the case where the startup
script gets stopped/killed.
- cmake NuttX build wrapper compile in place instead of copying source tree to build directory
- slightly faster skipping necessary copying (depending on system)
- allows debugging in place
- easier to work directly in NuttX following official documentation
- simplifies overall build which should make it easier to resolve any remaining NuttX dependency issues in the build system
- the downside is switching back and forth between different builds always require rebuilding NuttX, but I think this is worth the improved developer experience
- also no longer builds px4io and bootloader in every single build, for most users these rarely change and we're wasting a lot of build time
Remove params from airframe configs that are just set again
to the param default value or to the value that is
specified in the mc_default, fw_default or vtol_default.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- no longer start sercon or mavlink usb by default
- on USB connection (VBUS) monitor serial USB at low rate and start Mavlink if there's a HEARTBEAT or nshterm on 3 consecutive carriage returns
- the mavlink USB instance is automatically stopped and serdis executed if USB is disconnected
- skipping Mavlink USB (and sercon) saves a considerable amount of memory on older boards
Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>