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.
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
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.
seems apply a leaky integrator to the swash angle. This is the similar to what
is done by Phubar (http://code.google.com/p/phubar/) as well although we refer
to the gyro term as the proportional and the flybar angle as the integral
LED support was dropped from the BU images due to a lack
of proper abstraction for LED definitions between CC and
CC3D HW variants in the CopterControl board family.
Use the new LED abstraction to hide board revision details
from the BU image so it can once again flash some LEDs.
Every board has at least one LED (HEARTBEAT). Not all
users of LEDs need to be directly aware of which LED
configuration to choose when there may be more than one
possible configuration.
Hide the details of the differences between LEDs used in the
different HW revs for CC. This will allow generic code to
run on CC and CC3D without being exposed to the details of
the different pins used for the LEDs.
