Restablishing service scripts on V3 - part I
Date: 2021-02-23
Author: Andrew
For the GPS and M6050 need to get the services running at start up and modify them slightly to publish to redis. The python files are in github (https://github.com/axb2035/beach_robot) so they are easy to grab. However, the service files were still on the V2 SD card. Fired up V2 robot which still has the Raspberry Pi with the V2 card in it. When I fitted the Pi and battery to teh 3D printed parts as I had to jam it in and getting it out again is going to be a problem.
When I fired the up the Pi with the V2 card in it I couldn't get it to show the GUI. I tried both HDMI ports without any success. Tried VNC'ing in if for some reason there was a problem with the display hardware and still nothing. I want to do one more clean with the V2 robot with everything working before I retire it so chose not to rip it apart to get to the SD card and transfer to anotehr Pi. Reverting back to old-school command line ssh got me in. Everything seemed to be running except the GUI.
While I was doing this I noticed that the leads of the LEDs were covered in rust. Looks like operating in a sea-side environment is going to be tough on the components. In the past I have had to blow sand out of the HDMI port, though if VNC is not working then it would suggest a different problem from the hardware ports. Anyway - not to worry as I found the files I needed. Eventually.
Seems that the Raspberry OS allows you to store your service files in multiple locations. In the case of V2 I used /lib/systemd/system. For V3 I used /etc/systemd/system. Both seem to work fine. However I should be consistent. Also for the V2 service names used br_[service] which the V3 used br-[service] so again some inconsistency which made it a bit trickier to find the files when searching. Need to fix it up and make it consistent!
I also need to enable the wait-for-timesync service for all the beach robot services so that the clock can update before they start. Actually the time on the Pi is something I can add to the pi_stats. Alternatively I could use the timestamp off the GPS. Both have pros and cons. If I can't update the clock because I'm somewhere really remote then the services won't start. If I don't have a GPS lock for some reason then all the timestamps will be wrong.
I think the solution is to start the web server and provide an option to use GPS time if the clock doesn't update within a minute or so. Need to put some more thinking into this problem. Just realised I may need to cover the situation when neither are available.
One of the clear messages of this mornings work is that need better organisation to set up card from scratch. As the number of steps now is getting substantial and it's not documented anywhere besides a few notes here and there in various text files.