The config mode uses high rates for many streams, leading to high CPU usage
(9-10% for the mavlink sender). The normal mode contains almost the same
set of messages but at lower rates.
This reduces the CPU load on a Pixracer by 3-4%.
This change limits all mission items to the maximum flight altitude. The mission will still be executed and flown,
but the vehicle will never exceed the mission altitude. This ensures the vehicle can always reach the mission
items. Wether or not the entire mission should be rejected if it falls outside of the fenced area is enforced
in the mission feasibility checker function.
This commit is an attempt to fix a race condition happening on takeoff
between the land detector and the multicopter position controller.
Previously, an auto-takeoff leads to the following events:
1. A takeoff setpoint is given.
2. The thrust setpoint spikes because we don't enter smooth takeoff yet.
3. The land detector detects a takeoff because of the high thrust.
4. The position controller sees the landed state transition and
initiates the smooth takeoff. Thrust goes back down.
5. Depending on control gains the takeoff is successful or fails
if the smoothing takes too long which causes thrust to be too low, so
the land detector detects land again.
The two obvious problems with this are:
- The intermittent spike.
- The failed takeoff because of the smoothing leads to a delay..
With this change, the logic for a takeoff detection is moved from the
land detector to the position controller.
The events are now:
1. A takeoff setpoint is given.
2. The position controller detects the takeoff setpoint and initiates
the smooth takeoff.
3. As thrust ramps up, the land detector detects the take off.
In the same way, we now detect the intent to takeoff in manual,
altitude, control, position control in the position controller instead
of in the land detector.
This adds support for parsing git tags which include a vendor version.
E.g. vX.Y.Z-A.B.Crc1, whereas X.Y.Z are numbers defining the upstream
version and A.B.C is the vendor version.
This warning message would often be printed during normal configuration and does not represent a good indicator for true GPS lost states. Instead the system flags should be used, which are available through the normal logging system.
The hardfault keeps track of the number of reboot without a
commit to disk. A commit to disk is the act of writing the
fault data from the bbsram to the hardfault file, not the
ulog file. The sucessful commit rearms the hardfault system.
When ulog appending was added it treated the lack of a ulog
file as an error. This prevented the hardfault_log reset
from being called because the hardfault_log commit returned
an error.
if hardfault_log check
then
if hardfault_log commit
then
hardfault_log reset
fi
fi
This change treats the lack a a ulog as a non error.
