2024-04-12, 02:36 PM
Thanks for your reflections and help!
This is what interests me (a basic working autopilot). I'd be happy to work on that (albeit with not a lot of time available yet).
The battery backed autopilot is also of interest to me but that it should work whatever the hardware platform for pyPilot and the motor is going to be the biggest energy user.
The standby pilot is not so interesting for me as I plan to have windvane self steering to give the second option and would be planning to use that mostly on longer passages.
I have done a quick search and read. I had hoped that the microcontrollers had got powerful enough to be able to achieve pypilot directly onto the board with micropython. If we had to add an OS and extra hardware then it seems like a whole lot of coding work while losing most of the potential advantage.
Looking around it seems that there are Pi Pico clones with up to 16Mb flash memory and direct support for LiPo eg charging https://coolcomponents.co.uk/products/pico-lipo-16mb
So given the RP2040 has two cores I wonder if that makes the idea of a basic autopilot in just micropython more feasible (maybe as the standby, with an instant power up and battery backup it might be a good fit?)
But this seems a little different from the use_multiprocessing which is either multiple processes or a single thread. As there is (at least experimental) support in Micropython for threads and the RP2040 has 2 cores would it be possible to use the second core for a thread handling a queue of tasks currently handled by external processes?
Given that python is progressing toward eliminating the GIL maybe a threading alternative to multiprocessing might make sense on future Python releases as well as Micropython (providing the code handles both 2 and n cores)?
Is this already available? see https://micropython-icm20948.readthedocs...t/api.html
It is more than 40 years since I did matrix maths for A-Level :-) Googling seems to show that various people have needed this function and done some work on it. But I don't know enough to even ask sensible questions :-(
Thanks. I am interested in this and in contributing towards it. I am absolutely uninterested in forking PyPilot and would want to keep the changes as minimal as possible and as useful for the standard PyPilot as possible.
I guess my first step is to setup a Pi5 and get pypilot building and running on it. We have an original 1977 Neco with broken control panel and I want to get PyPilot working with that. Once I have a working PyPilot then the next step would be to start porting onto a microcontroller (which would get me nicely into understanding how the code base works).
Timing wise we move to live aboard in August 2025 and have a lot of basic boat refit to finish first. So it might be that the Neco project doesn't get much love before then.
Dave
Sustainable Sailing
Quote: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.
This is what interests me (a basic working autopilot). I'd be happy to work on that (albeit with not a lot of time available yet).
The battery backed autopilot is also of interest to me but that it should work whatever the hardware platform for pyPilot and the motor is going to be the biggest energy user.
The standby pilot is not so interesting for me as I plan to have windvane self steering to give the second option and would be planning to use that mostly on longer passages.
Quote: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.
I have done a quick search and read. I had hoped that the microcontrollers had got powerful enough to be able to achieve pypilot directly onto the board with micropython. If we had to add an OS and extra hardware then it seems like a whole lot of coding work while losing most of the potential advantage.
Looking around it seems that there are Pi Pico clones with up to 16Mb flash memory and direct support for LiPo eg charging https://coolcomponents.co.uk/products/pico-lipo-16mb
So given the RP2040 has two cores I wonder if that makes the idea of a basic autopilot in just micropython more feasible (maybe as the standby, with an instant power up and battery backup it might be a good fit?)
But this seems a little different from the use_multiprocessing which is either multiple processes or a single thread. As there is (at least experimental) support in Micropython for threads and the RP2040 has 2 cores would it be possible to use the second core for a thread handling a queue of tasks currently handled by external processes?
Given that python is progressing toward eliminating the GIL maybe a threading alternative to multiprocessing might make sense on future Python releases as well as Micropython (providing the code handles both 2 and n cores)?
Quote:[*][*][*]Quote:[*]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.
Is this already available? see https://micropython-icm20948.readthedocs...t/api.html
Quote: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)
It is more than 40 years since I did matrix maths for A-Level :-) Googling seems to show that various people have needed this function and done some work on it. But I don't know enough to even ask sensible questions :-(
Quote: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.
Thanks. I am interested in this and in contributing towards it. I am absolutely uninterested in forking PyPilot and would want to keep the changes as minimal as possible and as useful for the standard PyPilot as possible.
I guess my first step is to setup a Pi5 and get pypilot building and running on it. We have an original 1977 Neco with broken control panel and I want to get PyPilot working with that. Once I have a working PyPilot then the next step would be to start porting onto a microcontroller (which would get me nicely into understanding how the code base works).
Timing wise we move to live aboard in August 2025 and have a lot of basic boat refit to finish first. So it might be that the Neco project doesn't get much love before then.
Dave
Sustainable Sailing