It's amazing the contribution Andrew Tridgell is making. I love how the new version installations are automated on my APM 2.5.  I'm waiting for the next major upgrade (3 ?) before flying my big plane on the new Pixhawk.  The 32-bit STM32F427 Pixhawk processor with single precision FPU has the compute power to support the coming new features.

Above is a link to my Mission Planner recording of the second flight taken by my plane since 39 years as seen here using APM 2.5 and Mission Planner:

My job right now is inspecting the quality of C/C++ code inside digital radios.  I used to write C code controlling earth terminal communications to geosynchronous satellites.  I've fixed a lot of bugs in my day, and I've been a key participant in the architectural design of several systems.  I watched twice Dr Tridgell's presentation, "A peek into the future of ardupilot." I loved it and have the following thoughts:

1.  I think a Memory Management Unit or a separate processor is needed to separate Linux desktop applications (like in flight compilers) from the safety critical autopilot code.  Beagle Bone Black does not have a MMU although it could be a stepping stone to something like a Xilinx Zynq SoC.  For example, the Zynq has dual core ARM Cortex A9 each with MMU and separate double precision FPU plus FPGA fabric integrated on one SoC.  See MicroZed or ZYBO (Digilent).  One core could run the autopilot and its RTOS while the other core runs Linux.  The cores share a common large external RAM protected by MMU's.

2.  I think the autopilot RTOS needs to be light weight, fast, simple, and very reliable.  Simplicity is the first step towards reliability.  "Flexibility" and "Power" are code words for complexity and trouble whether it be the choice of computer language or choice of Operating System.  There is an added wattage and monetary cost to going airborne with Linux. It weakens reliability unless the processor hardware has a MMU to protect the autopilot code.

3  If I could, I'd say all memory shall be allocated statically at compile and link time.  There shall be no “heap”, no memory allocation or de-allocation at run time, no malloc, no instantiations.  Before initialized data is transfer from ROM to RAM, all RAM memory shall be initialized to zero, including the stacks, uninitialized and initialized memory space.

4.  Limit “If Else” decision making to two levels, four states.  Handle all states including the unexpected. Limit “switch” statements to one level (no nested switches).  All “switch” statements shall implement the “default” case.  For more complex decisions, use single dimension function tables or multi-dimension state-event tables in order to assure every case is considered by the designer and coder.  All states in function tables have a function handler including the, ignore(), unexpected(), and forbidden() cases. Function table logging may be enabled or disabled on command at run time.

Those are my thoughts for what they are worth.  I continue to be pleased by the amazing work the community is doing, and particularly Andrew Tridgell.

Sincerely,

Francis Nelson Henderson