This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
openplotter-pypilot 3.x.x beta released
#11
Before I update the workbook I first ran the install myself and updated the how-to, herewith attached. I have a few questions, but before that, may I say what a significant and momentous effort this is, and how impressive it is to see two brilliant initiatives in the openmarine universe come together in this way!

I have done the install only once, and possibly not in the right order. I could see a number of checks and balances kick in, and that was very helpful. However, these checks seem to cut off a few options:
  • The HAT service does not seem to start without the HAT hardware. This seems incorrect; even without PyPilot HAT it should be possible to enable the service to assign raspberry GPIO pins or IR codes to keys.
  • I could not start pypilot without the connection to signalk having been established. If this is intended, I understand, but pypilot can run very well without, and the dependency on signalk could be seen as complication.
  • I think the reason why the app did not automatically approve the signalk access request was that I had not logged in once to signalk yet, and no admin account had been created. Is that right? In that case, a simple reshuffle of the installation steps would solve this.
  • The UART mechanism requires an additional reboot, which is a bummer. I did enable the UART in Raspi-Config. Can this mechanism be streamlined? Without having the insight you guys have, I'd say just check for ttyS0 instead of serial0.
Hope this makes sense. Thanks again!

https://github.com/pypilot/workbook/file...ion.v3.pdf
Reply
#12
I didnt merge yet...

you will have to reboot for uart since it is in the boot config.
Reply
#13
(2022-09-20, 11:47 PM)ironman Wrote:
  • The HAT service does not seem to start without the HAT hardware. This seems incorrect; even without PyPilot HAT it should be possible to enable the service to assign raspberry GPIO pins or IR codes to keys.

I did not know that. Easy fix.

(2022-09-20, 11:47 PM)ironman Wrote:
  • I could not start pypilot without the connection to signalk having been established. If this is intended, I understand, but pypilot can run very well without, and the dependency on signalk could be seen as complication.

I think here we are talking about the integration of pypilot in openplotter and signal k server is the core of the project, so I really think that SK is a dependence on this case. If you do not need openplotter you can always install just pypilot.

(2022-09-20, 11:47 PM)ironman Wrote:
  • I think the reason why the app did not automatically approve the signalk access request was that I had not logged in once to signalk yet, and no admin account had been created. Is that right? In that case, a simple reshuffle of the installation steps would solve this.
signal k access requests must be always approved manually. You also would need manual approbation in standalone pypilot installations. OpenPlotter just "overwrites" the pypilot request system to integrate it with the rest of apps, checking system...
thanks for the review Smile
Reply
#14
sailoog... Lets try to coordinate changes better in the future.. I made a lot of improvements you ignored or did not know I made, and continue with new changes.. it became hard to merge. I redid everything this time without wxformbuilder and keeping your improvements.

The main change is to use systemd for pypilot services. This is really is required for a sane setup because it can respawn any crash, but more importantly it starts pypilot sooner at boot and a command can be used to configure the pypilot processes without requiring the gui, and the log output managed by journald.

Anyway, I think I managed to merge finally. Please test:
https://github.com/pypilot/openplotter-pypilot

both hat and web services can be run without pypilot as well.. in this case they will attempt to locate and use a remote pypilot such as tinypilot for example.

ironman:
As for running without signalk, openplotter has signalk server by default. Did you disable signalk server? There is no technical reason pypilot should not work if you do this.
Reply
#15
Of course, better coordinate.

In this version of Openplotter 3, we're trying to get rid of "sudo" because we're thinking of a web interface for future versions of Openplotter and non-sudo processes make our lives easier. You need sudo to start/stop systemd services and that's why we tried to switch to GUI managed pypilot services and python startup scripts. We return to systemd, no problem.

With pypilot running as a systemd service, the "Rescue" function no longer makes sense. I will remove it

At first glance, I can see that there are still some minor changes to be made and I will do it as soon as possible but I have a question. You removed openplotterPypilotRead.py and that script was there because pypilot_boatimu mode was not sending data to signal k server. Is pypilot sending data to Signal k server in both modes pypilot_boatimu and pypilot now?
Reply
#16
Do you mean sudo will not work without a password? If so, I need to also find a solution for the processes that switch to realtime priority.

I think you will find its too much work to replicate everything systemd does and it will be confusing for users and end up less good. I would like users be able to use ssh and systemctl. Let me know if there are any specific issues. If we remove sudo, a box pops up and asks for the user password.

I am not sure what the rescue button was supposed to do. I made it reset the pypilot configuration.

as for openplotterPypilotRead: yes I did not consider trying to use signalk in boatimu mode. Generally you can run the full autopilot without a motor controller.. but it may use more cpu than only boatimu mode.

pypilot can now output gps smoothed with imu data, so the openplotterPypilotRead.py script would need even more updates and it will be extra work to maintain and still not provide all the functions. I'm trying to figure the best solution... add signalk and nmea to boatimu mode.. or maybe just run the full pilot with all serial ports disabled (ensuring no motor controller probing) Do you think nmea input/output is needed in imu only mode or just signalk? Not really sure what users intend.
Reply
#17
The goal was to be able to start/stop pypilot without using sudo. Pypilot in openplotter 2 works as systemd service and non-sudoers users are prompted for the password when any action requires sudo but sudoers users (like the pi user in Raspberry OS) have to do nothing. You may be right, the alternative to stop pypilot using systemd is just killing it in a dirty way. Let's keep systemd, no problem.

The rescue button is also shown during the openplotter startup process and you have some seconds before some openplotter "services" start to block them. This was added thinking of the notifications app where you can accidentally set non sense actions that can brick your system. I will remove it for pypilot because there is not much risk of bricking anything.

The usual (and massive) use case for boatimu in openplotter is users that do not use pypilot, they just have a IMU to send heading and attitude data to signal K, they do not need anything else. What is the expected use of boatimu in pypilot?
Reply
#18
I see the issue with sudo/systemd, but switching away creates new problems. Let me know if the the pi user no longer can sudo without root. We may need to add a pypilot user instead.

The rescue button is interesting at least but I agree you can remove it. I thought it could be useful to reset pypilot settings but I will probably build that into the normal user interfaces of pypilot instead.

The boatimu in pypilot was mostly for debugging but also as a way to only use the IMU and not have the cpu use of other processes, or probing. About the
openplotterPypilotRead.py script
1) It doesn't seem to handle the normal access requests to request a token. Do you generate this token when building the openplotter image, or how does this even work?
2) pypilot can now do sensor fusion. For example, compensating wind sensors on top of the mast using the gyros, or using accelerometers to smooth gps data giving smooth speedometer with many updates per second. I plan to add more fusion in the future, and also potentially provide means to calibrate water speed sensors compute leeway and so on... I dont think it makes sense anymore to maintain this script.

I will look into the best solution for this, either adding sensor support to boatimu, or adding command line to pypilot to disable motor control and serial port probing, whichever works best.
Reply
#19
1) Many openplotter apps need connect to Signal k server, so we have added a global system to manage all requests. This system creates requests, notifications and warnings when some app has not approved the request yet or something is not working as it should. Right now pypilot is integrated on it and the .pypilot/signalk-token file is edited when needed to match the token managed by openplotter.

2) IMUs are always managed by pypilot in openplotter, we need a pypilot mode to have only IMU data in signal K server. Running an entire autopilot process to just get IMU data will always consume more than openplotterPypilotRead.py. I think the easiest way of doing this with out openplotterPypilotRead.py is just sending signal k data from boatimu script. No need of more sensors, just the IMU.

I will merge your changes into a branch and I will edit this:

- I will check if your changes reverting to systemd work right.
- I will remove Rescue button.
- I will check that the openplotter token management still works for pypilot

Wait for my changes before adding anything else please. I will do nothing with openplotterPypilotRead.py until you decide the best way to replace it.
Reply
#20
I will find the lowest cpu way to achieve the IMU goal. The additional sensors and the ability to blend sensors and produce improved outputs are not enabled by default but I think should be available to IMU only mode.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)