-
Notifications
You must be signed in to change notification settings - Fork 0
Linux services (on boot script startup)
Services using systemd are perfect for a scenario where you want your script to startup straight on boot. With systemd services we gain great tools for monitoring, logging and handling. You can easily check if your service is running or look up logs when you wonder why it failed. Its also possible to switch services on and off with one command. You can also perform the test run before you switch a service if you worry it might brick your system on boot.
There is a ton of resources on writing systemd services. It's easy to find how to menage systemd service (setup/run/monitor etc.), therefore this info is not included on this page. The purpose of this page is to show the path where to look for some startup scrits lunching and what to think about when preparing those services for our use case.
REFER TO THIS THREAD ON SETUP. It is not necessary to create new user for specific service, as you can run into issues with python libs, but overall tutorial is really easy to follow and descriptive.
For autonomous robot, we want it to start working right when its brain (Jetson) gets a power. This way we can drop robot in water, turn it on and watch the magic happen. System service will fire just at the moment when the system is ready to perform. auto_recorder.service is a great example of such a service. With svo_auto_recorder.py Python script we record ZED camera footage. Running it in auto_recorder.service enables us to drop the robot straight into the pool and enjoy the recorded footage when we fish the robot out and connect external PC to Jetson to download files. We obviously can use such service with more advanced script, performing whole mission at the competition.
We want to setup the service in a way that uses our linux account with correct setup, environment and Python libraries. We can specify environment variables just like in Environment="OPENBLAS_CORETYPE=ARMV8". This line is important for Jetson and ARM in general, because otherwise some Python libraries fail (f.e. NumPy). It's also possible to setup PYTHON_PATH etc.
There are some specific issues related to Jetson, which takes our task further than running just one Python script. We might want to use system configuration to enable highest possible performance of Jetson (check out jetson_clocks and nvpmodel power plans).
With current state of auto_recorder.service I didn't succeed to setup this service for a new user (user made specific for this service) as I hit errors when I tried to reuse packages for ZED. I think it's the most complicated part of service setup to get the right environment. We should investigate more, as we might want to run more services in the future and we want to minimize the time it takes to setup and lunch our service. Every second counts at competition.