Pyboard control system design

[pythoncoder]

A number of people are interested in using the Pyboard to control machines such as quadcopters and balancing robots so I thought it might be informative to start a general discussion on the best way to implement such designs.

These machines are inherently unstable, and the software generally has two tasks to perform. Firstly it has to stabilise the machine and secondly it needs to respond to events such as commands from a radio control, reading GPS signals or other sensors, and so on. The first task can be seen as mapping an unstable real machine onto a stable virtual one: a machine which will respond to commands like "turn pi/2 radians clockwise", "move at 100mm/s" and suchlike. To achieve stability this task needs to run in real time: in the case of balancing robots a 5mS loop time is typical.

The task of responding to events and communicating with the stable virtual machine does not usually require realtime performance.

I can see four implementation options:

• Use two Pyboards.
• Write a single high speed control loop performing both functions.
• Use cooperative multi-tasking.
• Run the real time loop as a timer callback.

Option 1 is cheating Option 2 rapidly gets messy for anything other than the simplest systems. Option 3 is unlikely to achieve adequate realtime performance. Which leaves the final option of running the control code as a timer callback.

In principle it's ideal. The code is executed at a precise frequency with time critical elements like integrators and filters being serviced at known intervals regardless of the behaviour of the rest of the code or of the garbage collector. But it does impose limitations on the code, and of that in any device drivers it calls, namely they must not use the heap. This immediately rules out floating point processing (unless done in assembler). Integer processing is usually feasible but does require a good deal of attention to scaling issues. As for device drivers, these vary. And I've yet to establish whether the basic communications methods of the various links supported by MicroPython are interrupt friendly (i2c.send(), i2c.recv() for example). Likewise for other buses and interfaces.

Any thoughts or comments?

[eduardo]

You might want to look at

https://www.indiegogo.com/projects/rasp ... extension/

They run a naked binary on the M0 core in the extender board which is connected over SPI to the rasperry pi.

therefore it it deterministic.

the Rasperri pi does only IO and higher level stuff.

[eduardo]

There is a project evaluating the use of an FPGA for handling the control loops.

The FPGA could be programmed/configured by the microcontroller (therefore the reverse engineering of the bitstream)

the microcontroller would then do only the high level stuff.

even he would be able to go sleeping for some time until a trigger wakes him up to take care
about some stuff.

If you are interested, you might want to look at

http://www.clifford.at/icestorm/

e.g. an FPGA is loaded every 3 seconds with a new predistortion filter for an RF amplifier.

[kfricke]

eduardo, i do assume it is pythoncoders intent to use MicroPython for this task!

[MarkHaysHarris777]

hi, me thinks a 'trinity' of pyboards would be beneficial each mounted within its own primary axis. Three processes, all interrupt driven, working together to achieve all flight-sensor tasks would be optimal. I've thought about the 'Shuttle' system, and its five-way processors and how a 'triboard' approach to automated flight might be achieved in similar ways.

Also, having played a bit with the on-board accelerometer, I think gyro sensors are best for flight control of all kinds for the same reason they are beneficial for human flight control. Balance and accelerometer sensors are not good attitude sensors for generalized flight- for humans nor for automated aircraft; gyros are needed.

There were times when I was flying small planes with my Dad, when I 'felt' like I was up-side-down heading 'down' when in fact I was right-side-up and level. You have to use your instruments, and those need to be gyro based sensors.

I do believe that three pyboards working together is optimal for general automation and telemetry. And, without good telemetry what is the point?

[pythoncoder]

@eduardo I am familiar with general solutions to problems of realtime process control. I was aiming to start a discussion on the specific issue of how best to employ the Pyboard for such tasks.

@MarkHaysHarris777 The issue of determining the attitude of an aerial platform is well established. In general you need a sensor with ten degrees of freedom: three (x,y,z) for the accelerometer, three for gyros, three for a magnetometer, plus one for altitude (atmospheric pressure). Combining these is rather involved because the accelerometer is affected by changes in the velocity of the aircraft as well as by changes in its orientation. Further, while gyros are unaffected by acceleration they suffer long term drift. It is a sufficiently difficult problem that the best solution is likely to be to port some existing code to the Pyboard, something I might consider doing if nobody else gets there first. If you're interested in learning how this is usually done you'll need to get a grasp of Quaternions, a rather unfamiliar (to me) bit of maths.

By the nature of this computation my view is that attitude sensing would have to be done by a single Pyboard. Whether the other aspects of flight control would be best handled by another board, or could be shared, is a moot point. I do think that a useful way to view the problem, as I suggested in my original post, is to envisage two notionally concurrent tasks. One, operating in realtime, transforming a real unstable platform into a virtual stable one. And a second, with less stringent time constraints, communicating with the virtual craft. I was hoping for some feedback on that concept and on how people think it might best be implemented using Pyboards.

[pfalcon]

To get discussion back on topic set by pythoncoder.

I think tasks like these are great chance to further progress of MicroPython. Supporting dismissal of extensive, bloat-like solutions, I may add couple of intensive, innovative ways:

1. Use "hardware" multithreading - there was great work by @dpgeorge to isolate and encapsulate interpreter state, so next logical step is spawning 2 (or more) interpreters running in different "OS" threads.

2. Follow top/bottom half interrupt handling approach - let IRQ handler set a flag, and make uPy VM test a flag and dispatch on it itself.

[pythoncoder]

Hardware mutlithreading sounds ideal.

Returning to the ideas in my original post and the existing Pyboard implementation, I've looked some more at the idea of running the real time loop as a timer callback. I'm almost certain it's practical for a balancing robot. I2C will work in a callback, and the complementary filtering can be done using integers - I plan to try it soon. My doubts are with airborne applications: how feasible it is to do sensor fusion using integers? How fast dos the control loop need to run to stabilise a multi-copter? Has anyone built one, using MicroPython or otherwise?

[pfalcon]

how feasible it is to do sensor fusion using integers?

Apparently, as feasible as doing that on 8-bit MCU, and a lot (should I say majority?) copter boards I saw (but I don't watch them closely) were AVR-based.

[pythoncoder]

Interesting. With the approval of @turbinenreiter I'd like to add interrupt-capable sensor fusion to the MPU-9150 library but it'll have to wait while I finish two other projects.

To hell with AVR's: the Pyboard makes an ideal platform for control systems given the ease of stopping the program, tweaking parameters at the REPL, and restarting. It's like working with an in circuit emulator