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.
Extra message context is also useful even when building more
than one target in the same invocation of make.
This example would enable extra context:
make fw_coptercontrol bl_coptercontrol
When building the various all_* targets, it was hard to tell which
board/build-type that each line of output applied to. Now, the
all_* target types will include something like:
CC [fw|cc ] flight/PiOS/STM32F10x/pios_gpio.c
which includes the necessary additional context.
This will help with identifying the context for warnings and errors
when building a group of targets.
Conflicts:
Makefile
The simposix build doesn't work on Windows or Mac so it shouldn't
be in the all_flight build target that is used as a pre-submit
check on all platforms.
as an attribute on the uav object definition. This attribute is
optional. If absent no category (empty string) is assigned to the uav
object type.
Added category attribute to a small selection of uavo definition files
to test parsing.
number of QTimer instances and the number of redraws to hopefully
increase performance.
Changed so that when a child gets hilighted it will hilight its parent.
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.
