Saves a further 8 bytes of RAM per object.
Saves 1.5KB of flash by removing all of the const strings for
all of the object names and the corresponding meta object names.
This leaves room for more code.
Refactored the updating of ChannelUpdateFreq so that it is done only when the actual update rates changes.
The actual update of the servo channel is moved inside the ActuatorTask.
Now the problem happen only in very few cases when modifying update rates.
It is now possible to have 1 to 6 flight mode switch positions
(usefull for guidance, position hold and similar use).
The input channel range is divided into N (1 to 6) zones and each
zone represents a flight mode. Default is 3 zones (backward compatible),
but more can be chosen.
How to use: configure Tx mixers in a way they provide required number
of different values for the same FlightMode channel. For instance,
using Turnigy 9X radio with ER9X firmware, one can create a mixer like
this:
-100 MAX ID0 Manual
R -50 MAX ID1 Stabilized1 (Rate)
R 0 MAX ID2 Stabilized2 (Attitude)
R 50 MAX RUD PositionHold
R 100 MAX ELE ReturnToBase
And set number of flight mode positions to 5. As a result, the 3-pos
switch (ID0, ID1, ID2) will provide first three flight modes, the rudder
D/R switch will override those and enable the 4th flight mode, and
elevator D/R switch will have highest precedence and activate the 5th
flight mode.
This will change the ManualControlSettings objectID.
The module can be configured to enable what's needed from board voltage, battery voltage and battery current measurement.
In GCS the POWER box in system healt will show alarm related to the supply voltage to the board.
If a power warning/critical alarm is raised, the warning condition is left even if the board voltage return to an acceptable value.
Conflicts:
ground/openpilotgcs/share/openpilotgcs/diagrams/default/system-health.svg
shared/uavobjectdefinition/systemalarms.xml
flash so it says completed. However, it still blocks the system for a long
time. During an erase the heartbeat will flash at 10 Hz to indicate what's
happening.
This still blocks telemetry even after lowering hte system priority (and there
is a vTaskDelay) which makes me think that the SPI bus being locked is blocking
Sensors or somethign else. This should not be permited when the system is
armed.
The reason the system locks up during the erase is that the file system
operations occur within the event dispatcher thread. It is very bad practice
for anything to block this (i.e. callbacks should never take very long). We
should probably move the object persistence handling into the system thread or
something but that can be a separate issue.
