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.
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.
