openplotter-pypilot 3.x.x beta released

[Sailoog]

First of all, sorry for the delay, job and other projects required our attention.

The first beta version of pypilot for OpenPloter 3 has been released. You just have to click "get candidates" in settings app and install pypilot from the list.

If you already have compiled openplotter-pypilot for OpenPlotter 3 following this manual: https://github.com/pypilot/workbook/file...lation.pdf, I recommend you to start from scratch using a fresh OpenPlotter 3 image because you can have unexpected errors. Thanks to ironman and seandepagnier for filling the gap all this time.

There are several differences with that compiled version, the main one is that pypilot modes no longer run as services and we no longer need sudo. this version is fully integrated with all OpenPlotter apps:

• Signal K connection request and approve are managed by OpenPlotter and saved in pypilot settings
  
• Pypilot is added to the "check system" routines
  
• Network connections are monitored to find conflicts with other applications
  
• Serial connections are monitored to find conflicts with other applications
  
• You can set serial devices for pypilot from openplotter-serial app too
  
• GPIO connections are monitored to find conflicts with other applications
  
• If pypilot code is updated you just have to re-install openplotter-pypilot app and everything will be checked and reinstalled
  
• The Rescue feature allows you to disable pypilot (and other apps) when your system gets unstable. Rescue mode can be enabled at startup.
  

Currently I do not have a pypilot controller nor a pypilot HAT, so there are still a lot of things that you will have to test before going to stable. "IMU only" mode is tested and working right.

Please do not use it in production environments yet and post any issue here. Thanks.

   

[Sailoog]

Actually I have the first question. When in autopilot mode, pypilot tries to connect to any existing serial device. If any application (like Signal K) is already using that device, pypilot starts fighting for it and the device stops working.

In openplotter-pypilot we have the serial tab to add/remove devices to the serial_ports file. I understand that this automatic checking of the serial devices is necessary for other environments but in OpenPlotter or similar it is a problem. My question is, could this behavior be optional?

[seandepagnier]

It is my intention that pypilot only access serial ports assigned to it.
I made a small update to https://github.com/pypilot/openplotter-pypilot just now, and hopefully it will fix.

I see you made many changes... I will try to merge.

[Sailoog]

Yes, lot of changes. As you can see I do not use wxFormBuilder and the code structure has also changed, if you want to update your fork with the fix for the serial devices I can try to adapt it to the new code.

[seandepagnier]

Can you use wxformbuilder? It makes big changes to the gui a lot easier.

[Sailoog]

Buff I tried but I have more control over the GUI this way. Perhaps for more complex structures it is worth using wxformbuilder but our GUI is really simple.

[seandepagnier]

ok.

I will work without it for openplotter-pypilot. I will try to merge our work.

[ironman]

If that's ok with you two guys, I'll update the workbook with the openplotter release as first option, mentioning Sean's github as good alternative and identifying the differences, pros and cons for the time being, pending the merge.

Whereas I saw the openplotter distribution as a good learning experience, and the tinypilot distribution as the only reliable solution to go out sailing with, the deck has been somewhat shuffled, now pizero's are practically impossible to get. An openplotter instance on a pi4 with only pypilot on it seems to become the de facto way to build a pypilot system in these days. Drawbacks are obviously the windowing UI and the OS usage of the SD-card, resulting in decreased reliability and much increased power consumption. Am I the only one to see this, or are there other options that are worth mentioning?

[mgrouch]

If that's ok with you two guys, I'll update the workbook with the openplotter release as first option, mentioning Sean's github as good alternative and identifying the differences, pros and cons for the time being, pending the merge.

Whereas I saw the openplotter distribution as a good learning experience, and the tinypilot distribution as the only reliable solution to go out sailing with, the deck has been somewhat shuffled, now pizero's are practically impossible to get. An openplotter instance on a pi4 with only pypilot on it seems to become the de facto way to build a pypilot system in these days. Drawbacks are obviously the windowing UI and the OS usage of the SD-card, resulting in decreased reliability and much increased power consumption. Am I the only one to see this, or are there other options that are worth mentioning?

Pi4 is about 5w, with a screen about 12w. And motor controller for autopilot ?w. Add router, Ethernet hub, USB hub (1w).
How big should be a LiPo battery charged from solar and dedicated just for autopilot and chartplotter with a screen and pi4?

Thanks

---

And another thought. Old android phones are common thing. Might be whole autopilot can be run just on an android phone.
Hardware has to be modified to work with it. And software needs to be adopted for android. But is can be quite power efficient and
attractive for many users.

[seandepagnier]

there is another javascript autopilot that uses an old android phone: https://github.com/yOyOeK1/ykpilot

I did not decide to take this path with pypilot:
1) the inertial sensors vary from phone to phone. There are a lot of marginal inertial sensors that dont give as good performance. I am not sure if you can access and read the inertial data directly with the same low latency either, but its probably possible.
2) I did some simple ping tests to an android phone and the latency is ok 95% of the time, but often enough 50ms which is borderline for degrading autopilot performance especially on light or fast boats. I think it can do much worse in theory at times, a lag of 200ms could cause my boat to go at least 5 degrees off course at speed which just means less efficient sailing and more power for the motor to correct. I would consider this likely usable but not desirable. The wifi link has an unreliable nature.
3) This may possible to completely solve, but I am not sure about how to make the critical processes have realtime priority on android.

raspberry pi was available when I started pypilot and cheap enough that the above issues did not seem worth the trouble. In any case, python can run on android so it is potentially viable.


As for battery size, it depends on the boat and so forth. I typically average 3-6 watts on the motor steering in most conditions for the motor, but other boats can consume much much more power to hold course. To power for 24 hours a day even in overcast weather you need to multiply your load (in this case say 12 watts average if you turn the screen off a lot) by 40, so 480 watts of solar would allow a minimal battery size of 200 watt hours to ensure continuous 24 hour operation even in winter in my area. You can get away with much much less solar if you expect some direct sun or better solar conditions and/or a larger battery capacity.

On my boat I have about 250watt hour main battery now, plus up to 300 watt solar (200 normally stored below but panels can be deployed in overcast if needed) I also have a tow generator which can produce 30-40 watts all the time under sail, so there is really not a question of power.