This patch is based on work of Crubier (LPF) and Cossacs (AxisLock mode).
I've just reworked it a bit by adding a dynamic memory allocation for
static module data.
This module and its associated settings uavo can be used
to test various fault conditions during initialization.
To enable the module, add the TEST_FAULTS=YES to your make
command line:
make fw_coptercontrol TEST_FAULTS=YES
Once this module is part of your firmware load, you can
enable it in the hwsettings uavo and then select the
type of fault to insert by editing the faultsettings uavo.
On the next reset, the configured fault will be inserted
into the init sequence to allow you to test the boot fault
recovery code.
With a fault inserted, you should see 3 failed boot attempts
followed by a successful (recovery) boot. You will see the
BootFault alarm set to Critical, and the RAM version of your
hwsettings will be reset to defaults. Since the defaults have
all optional modules disabled, the fault module will be out of
the way during the recovery boot.
You can then "Load" the flash version of the hwsettings uavo
in the object browser, disable the Fault module and then "Save"
the hwsettings module back to the board. The next reset will
boot normally without the fault inserted.
After 3 failed warm start attempts, the init sequence
will force the RAM version of the HWSettings object
to its defaults. This should allow a user to regain
connectivity to a board that is continually faulting
during init.
This is accomplished by:
- Incrementing a boot counter that is stored in the
STM32 BKP registers. These registers survive a
warm start but are cleared on a cold start (ie. powerup).
- On multiple failures, force hwsettings to defaults
and raise the (new) BootFault alarm to prevent arming.
- Resetting the boot counter whenever the system manages
to successfully run the System Module task.
NOTE: This does not actually change the hwsettings object in
flash. That's up to the user.
This is intended to catch ONLY faults during early initialization.
It should not be used to recover from faults after the application
is up and running.
This allows the HID and VCP functions to be configured
separately so that additional functions can be more easily
bound to the VCP port.
This change also provides a safety net that forces either
the HID or VCP to be configured for USB Telemetry. This
safety net may vanish in the future once the GCS can check
it. Disabling USB Telemetry entirely would save more than
400 bytes of RAM.
- both CC serial ports are now disabled by default (no telemetry);
- serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options;
- ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options.
For DSM2 protocol there is an explicit resolution bit in the stream, so
the DSM2 should be selected. For DSMX there is no such bit, and user
should choose the resolution from the list configuring the spektrum port.
ReceiverGroups have single DSM option which is handled by the same driver.
Downside: this implementation saves received frame first, unrolls by the
end of frame. This should be ok, but may be improved by unrolling channels
on the fly in the rx callback.
Another minor difference is that a ChannelGroup is now bound to port:
DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable
solution in order to not have 6 DSM options for each ChannelGroup and
even more in case of new DSM protocol variations.
Known problem: it is not possible to choose same protocols like
DSM2/DSM2 for two ports. It can be enabled by adding an exception to
common rule, though.
The DSMX throttle channel misbehavior (zero value) is not treated
specially yet. It should trigger the failsafe being out of bounds.
More info and data dumps are required to handle this properly.
PPM. This saves resources. Good suggestion Os. In this configuration we
could allow 12 channels of output but for now I'll leave it capped at 10 to
lessen resources on the mixer table.
With spektrum and camera stab enabled there was
1632 bytes heap remaining
180 bytes irq stack remaining
TelemetrySettings object removed (saved 200+ bytes of RAM). Telemetry
port speed moved to the HwSettings object. Added GPS port speed setting.
GCS code updated to reflect changes and support both fields.
Besides of knob PID tuning it is now possible to use throttle channel
to ramp-shape PID coefficients. This can be used to lower some PIDs on
VTOL while sinking to prevent wobble.
To use the feature select throttle as control input, choose throttle
range max and min values, assign the instance to particular PID
coefficient and define a range for it. When throttle is lower than
defined throttle range min value (or higher than max), then min and max
PID values will be used accordingly. Changing throttle from throttle
min to max will linearly scale PID value.
Note that it is possible to set MinPID > MaxPID. In that case increasing
control input value will decrease the PID coefficient.
Up to 3 independent instances can be configured. The number can be
increased changing the UAVO definition, but at the cost of extra RAM.
This module will periodically update values of stabilization PID settings
depending on configured input control channels. New values of stabilization
settings are not saved to flash, but updated in RAM. It is expected that the
module will be enabled only for tuning. When desired values are found, they
can be read via GCS and saved permanently. Then this module should be
disabled again.
Move the configuration files for INS from AHRS* to INS*. Strip out unused
fields in settings and merge calibration and settings since settings has
basically no information.
needed by users because if too much changes I change the FS magic and trigger a
wipe.
Possibly the erase should require a particular "magic" object id value to
execute? This would make it harder to do manually through UAVOs though.
This allows the GCS to emulate a receiver device via the
telemetry link.
Select "GCS" as your input type in the manualcontrol config
screen and calibrate it as normal.
Note: The expected values for the channels are in microseconds
just like a PWM or PPM input device. The channel values
are validated against minimum/maximum pulse lengths just
like normal receivers.
Also reduce heap has it does not fit in SRAM anymore (not with current compiler).
(that's ok since if there is more space available, it will be reclaimed).
Merge branch 'master' into OP-423_Mathieu_Change_Init_To_Reduce_Memory_Footprint
Conflicts:
flight/CopterControl/System/inc/pios_config.h
flight/Modules/ManualControl/manualcontrol.c
high RateKp terms. However it might be sensitive to gyro noise (vibrations).
In addition it is mathematically similar to lead shapign so probably only use
one or the other.
stabilization output a bit more resilient to the high frequency noise from
gyros. However this value shouldn't be too high as it will increase the phase
delay of the feedback loop and decrease stability. Default is 5 ms.
Note: this resests the stabilizationsettings object. Sorry guys.
heap reamining is low (about 500) but stacks can be ajusted (specially the 200 bytes from system) to give the level close to 1Ko if needed.
Merge branch 'master' into OP-423_Mathieu_Change_Init_To_Reduce_Memory_Footprint
Conflicts:
flight/CopterControl/System/inc/FreeRTOSConfig.h
flight/CopterControl/System/inc/pios_config.h
- use IRQStack for ISRs (at begening of SRAM) (let's call it the irq stack)
- use end of heap for stack needed during initialization (let's call it the init stack).
- the systemStats in GCS indicate the remaining bytes in the IRQ stack (this is realy usefull to monitor our (nested) IRQs.
This is the base ground to provide as much memory as possible available at task creation time.
Next step is to re-organize the initialization in order to move all the init out of the thread's stacks onto the init stack.
This will provide as much memory as possible available at task creation time.
Basically the stack during initialization will be destroyed once the scheduler starts and dynamic alloc are made (since the init stack is at the end of the heap). We will need to make sure we don't clobber the heap during initialization otherwise this will lead to stack corruption.
outputs. Warning: This has no failsafes like arming. We should discuss if
this is appropriate.
In addition accessory objects can be routed throught the mixer for collective
or flaperon.
Also change AttitudeActual to update at 10Hz rather than 2 Hz. The increased bandwidth is minimal and the resulting "polish" that it adds to the look-and-feel of the GCS is signifcant.
rotate sensors to make sure stabilization behaves well so don't use till then.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3100 ebee16cc-31ac-478f-84a7-5cbb03baadba
Note: AttitudeSettings changed so you'll need to re-zero it
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@3090 ebee16cc-31ac-478f-84a7-5cbb03baadba
Warning: The memory utilization when importing objects is unacceptably high making it unusable in the flight code at this point. It can be however used with the SITL simulator. Some more investigation is needed to understand why several kb of memory are used each time a module is imported (even before any functions are called or objects from the module are created).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2938 ebee16cc-31ac-478f-84a7-5cbb03baadba
Feel free to revert the layout change part - but I'm trying to make it clear
that "stabilization1" no longer naturally matches "position1"
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2936 ebee16cc-31ac-478f-84a7-5cbb03baadba
modes so that the FlightMode field is complete in terms of being informative
enough
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2935 ebee16cc-31ac-478f-84a7-5cbb03baadba
Stabilization, carries the desired rate or attitude as well as a flag on how to
intepret it.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2930 ebee16cc-31ac-478f-84a7-5cbb03baadba
Move channel StabilizationSettings from ManualControlCommand to
AttitudeDesired, unify channel normalization and put them all into ManualControl
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2797 ebee16cc-31ac-478f-84a7-5cbb03baadba
that it will completely follow the accel attitude each cycle and is way too
high. Ki=1 means the gyro bias wil be correct by accels each cycle (way too
high).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2755 ebee16cc-31ac-478f-84a7-5cbb03baadba
The UAVObject definition (.xml) files are used by both the
GCS build as well as the flight software builds.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2526 ebee16cc-31ac-478f-84a7-5cbb03baadba
