Pypilot on Micropython?

[seandepagnier]

I'm very interested in not using a board with an OS because of the time it takes to boot.  If the PyPilot we have today loses power, it's around 40 seconds before the autopilot is back on line.  That's a loooong time if you're on your boat and hell's breaking loose, and you really need the autopilot to take the helm now.

I can agree about the boot speed being an issue.  It could in theory be optimized a little,  the boot speed is already much faster on quad core.  To a lesser extent, power consumption (and cost) is a bit lower on these boards too but not really significant.  It would take a lot of work to support certain features of pypilot, but a working autopilot should be the goal first.

There are 2 other potential things that could help with this:
run pypilot with it's own power pack offering it sort of like a UPS to last at least an hour or so (including moving the motor) using one or more 18650 cells.    You said "if pypilot loses power"  that is going to be an issue for any autopilot, so if by this you mean a fuse blows or something like that and you replace it,  then yes boot speed is annoying, but having backup power pack is already better no matter what the autopilot boot speed.

  standby pypilot --  It is in planning stages, but to offer the ability to have 2 (or more) pypilots running at the same time.  Only one is working, however if the standby pilot detects the main one is not working, eg:
1) software crash
2) power failure (wires powering stuff on primary pilot break)
3), motor controller fails for whatever reason, eg: fuse blows, or water gets on it etc
4) inertial sensors not working, or sudden distortion (someone moved a magnet near the compass sensors)
5)  just generally fails to hold course (wrong settings)

the standby pilot would then activate the clutch output on its motor controller which is wired to a relay that allows it to take over the motor without back driving the primary motor controller, and it would take over steering.  Other configurations could be to have 2 hydraulic pumps for added redundancy in drives where this is possible, but the idea is having a standby pilot.  This could of course have one or more pilots with #1 (backup battery pack)

I've looked into the possibility of a MicroPython port.  I see six main obstacles:

[*]Multiprocessing / multithreading.  As currently written, PyPilot spawns Linux processes, and uses the Python multiprogramming library.  Neither of these is supported by MicroPython.  MicroPython programs should be written to use async/await, and/or use the _threading library, although support for the latter is still experimental.  Rewriting to use these would result in code that would be too different to keep in one codebase, although code written to use async/await may work In CPython and MicroPython.

[*]There is at least preliminary work in place to decouple this.  So to sequentially execute the critical parts.  It is not really tested, but search for "use_multiprocessing" and multiprocessing in the code and there are some initial tests in place to make pypilot work as a single process.  This is not really better if processes can be used.    In more recent micropython it seems it _is_ possible to spawn multiple threads each running as a separate freertos thread (can utilize dual core) and execute python code this way.  Not sure how viable it is without external ram (psram)    It might make sense to use fewer processes but not only a single one in this way, to ensure that still the main process that performs the control loop is prioritized.

[*]PyPilot as written uses TCP sockets, unix domain sockets, and does I/O by doing reads/writes on Linux character device files.  The way MicroPython programs do networking, interprocess communication, and device I/O is quite different.  See above re divergent codebases.

[*]Not sure this is correct.  At least not in the sense that it would not work because the read/write is fully implemented on micropython using the same calls.  Already the pypilot_hat works on micropython as a control interface to pypilot.

[*]Some of the autopilot algorithms use the TensorFlow AI library.  Not a dealbreaker as the main algorithm doesn't.

[*]Yes, not important at all, the tensorflow is not even working yet (still)

[*]PyPilot as written uses the RTIMULib2 IMU library.  This library would either need to be ported to an MCU, or replaced with something else.

[*]I dont see a huge reason why this library could not be given micropython support wrapper.  Another option that could be easier/more efficient  would be to rewrite the icm20948 driver specifically for esp32 and utilize dma, then either wrap this in something that works like rtimulib2, or just support this new library.

[*]PyPilot as written calls SciPy to do IMU calibration (least squares calculation, and Orthogonal Distance Regression).  SciPy is never going to run on an MCU.  This code would need to be replaced with something else.

[*]Yes, it is relatively straightforward to implement the regression using matricies.  Essentially a matrix inverse, and while would use less processing power it is also less flexible (requires partial derivatives)    I think instead a different algorithm could be implemented though to replace the scipy.optimize.leastsq  or perhaps even just port this one function (since all of scipy is too big to consider)

[*]Sean may give his blessing for such a port, and may not.  Who would work on a port if Sean did not?

[*]I do want such a port, but if possible I would like to separate the esp32 specific parts into different python files, and reuse as much of pypilot as possible in regular python, similarly to the pypilot_hat port.  This way it is possible to maintain pypilot adding new features and support micropython in the main code base without a separate fork.