Need guidance for operating nano+gps without display/kboard

Autonomous Machines Jetson & Embedded Systems Jetson Nano
, ,
1

I’ve not a great deal of experience with Jetson nano. I’m attempting to run a python script after startup, without peripherals - no display, keyboard or mouse. Just a jetson unit accessing a GPS (at this point, but later, a camera and USB drive to save images)

I’ve set up the script so it initiates with boot up, using a systemd.service file.

[Unit]
Description="My service"
[Service]
ExecStart=/usr/bin/python3 /usr/local/bin/myscript.py
User=username
[Install]
WantedBy=default.target

This works fine and the python script (in usr/local/bin/myscript.py) starts, as long as I have a monitor connected, but otherwise it will not.
It seems that while the systemd service is being executed and the python script is started - it just never gets the information it’s looking for, from the GPS.

I’ve also had to implement a rule to allow access to ttyTHS1:

Kernel == "tyTHS*", Mode = "0666"

And I stopped ngvetty, disabbled nvetty and restarted.

The script to access the GPS is just this:

try:
	gps.update()
	while not gps.has_fix:
		GPIO.output(gpsled_pin,ledon)
		time.sleep(0.2)
		print("waiting for fix..")
		gps.update()
		GPIO.output(gpsled_pin,ledoff)
		time.sleep(0.2)

So it seems that it never gets a gps fix.

Does anyone have any thoughts on what I can do? or what is going on?
I dont even know how to find out what might be stopping my script from accessing the GPS - the monitor isnt connected!

Is setting the system to start in headless mode appropriate or useful in this case? I dont need wifi access, the unit will be isolated in the middle of nowhere, just accessing gps and writing files.
Thanks.
E.

2

I can’t help much with either Python or the GPS itself. However, I will ask, can you also write to that port? If you can, using some simple test text (e.g., “Hello World”), then instead of connecting your GPS you can use loopback mode: Wire the TX to RX on the Jetson itself. This should produce an echo of “Hello World” (or whatever text or data you send). Your test data could be a line of data you expect a GPS might “typically” send.

Also, once your program starts running, what do you see from:
ls -l /dev/ttyTHS1 /dev/S1

I ask because I am suspicious of the permissions in the systemd startup. Normally these ports have group “dialout” if the port is available, and you’d simply add your user to that group. If the group happens to be “tty”, then you probably also have serial console trying to run on it. Ports “ttyTHS1” and “ttyS1” are the same hardware, but different drivers (you might or might not have both a THS# and an S# driver).

3

Thanks for your information and suggestions.
ls -l /dev/ttyTHS1 /dev/S1 returns this (incidentally, this unit is necessarily not connected to internet, so the clock is wrong).
ls: cannot access ‘/dev/S1’: No such file or directory
crw-rw-rw- 1 root dialout 238, 1 Jun 21 16:51 /dev/ttyTHS1

doing:
groups myuser

will return
myuser : myuser adm tty dialout cdrom sudo audio dip video plugdev i2c lpadmin gdm lightdm gpio weston-launch sambashare flirimaging

I think the user is part of the group?

I’m not sure what an S* driver is and I couldn’t find much online about it, but it looks like I lack it. Could you point me to more information, or suggest how I might go about including one?

Since I’m just detaching the screen, I wonder if I need to include an environment definition in the service script -
such as this forum post here… (though I’m not exporting anything to screen)

4

Yes, the serial port is free for your use, and your user should have permission to directly access the port without sudo.

You don’t need the “/dev/ttyS1” if you are using “/dev/ttyTHS1”. It is probably better to have just the “ttyTHS1” running. The exception is if the port has to work in early bootloader stages prior to the Linux kernel running.

As far as exporting of environment variable “DISPLAY” is concerned, this is not needed for using the serial UART. Normally this is needed for something needing GPU access, e.g., OpenGL/OpenGLES/CUDA. It isn’t possible to give a more definite answer without knowing a lot more about the program being run, e.g., if it uses CUDA or a GUI application.

5

Thanks again,
From the point of view of the python, it doesn’t need to run at early stages at all.
The python script does nothing other than write to the GPS to set a data format, then read from it at ~2 Hz, parse the output and do a little processing to compute a location and local time; at least, it does this successfully with the screen attached. It doesnt use CUDA nor GUI - there are no display requirements at all.

I’m wondering more about what you’d said earlier regarding writing to the TX port on the Jetson; It’s hard for me to diagnose any problems with this: I don’t know how to test if the port can be accessed (written/read), when the screen isnt connected - because I cant see what’s going on!.
Do you think you could suggest a way to test the port access after startup without the screen connected? Some linux process might be sufficient at this point…

Thanks again.

6

Is the Jetson networked? If so, then you can access it remotely via ssh. If not, then perhaps you could use serial console. See:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/

If you are physically near the Jetson, then serial console would be the method of choice. ssh works as well, but you wouldn’t be able to test in loopback mode without physical access.