Running a code on Jetson with having some remote control

[mona.jalal]

Currently, to run a code on Jetson AGX ORIN, I need to have access to a display so that I can see what I am typing in terminal.

How can I run my code in Jetson and also see what I am doing without connecting a display?

Is there a way to remotely control the Jetson upon knowing its IP or other methods?

[EduardoSalazar96]

Hi @mona.jalal
You can connect over ssh using your IP address. For example:

ssh username@IP
pass:<board_password>

Also, you can use a vscode extension for remoting development. Check the following wiki Remote development vscode - RidgeRun Developer Wiki

I hope this information is of value to you. Please, let us know how it goes!

Eduardo Salazar
Embedded SW Engineer at RidgeRun

Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

[linuxdev]

I install my public key to Jetsons so I don’t need a password. However, let’s say your user name is “ubuntu”, and the address of the Jetson is 192.168.55.1. Check this example as run from the host PC with ssh access:

• ssh ubuntu@192.168.55.1 whoami
• ssh ubuntu@192.168.55.1 ps

To expand on this, commands which do not try to maintain connection after their initial output run over ssh just like they do in a local terminal. You’d get an error with this:
ssh ubuntu@192.168.55.1 top

The reason is that it needs a continuing environment and ssh was told to disconnect.

Now if you want to run a remote program that uses the GUI, it gets more complicated because you need to forward X events when doing this on an X server. The “not so obvious” part of forwarding events is that the GUI portion runs on your host PC, and not on the Jetson. The “-X” or “-Y” options might have security setup changes required, but mostly this should just work (try both -X and -Y if there are issues):
ssh -Y ubuntu@192.168.55.1 xterm

Note that this does not use the Jetson’s GPU. If you run an OpenGL app on the Jetson, then the same OpenGL must be present on the host for it to work. If you run a CUDA command on the Jetson, and then forward instead with “ssh -Y” (or “-X”) to your PC, then that release of CUDA must exist on the PC. Commands and calls which do not require a GUI still run on the Jetson (for example, a shutdown GUI tool would shut down the Jetson, not the host PC).

Events and event forwarding are a thing for “X” servers, and both ends must have their part of the X software.

Now if you are running a GUI on the Jetson, but accessing remotely, you could cause the app to show up on the Jetson instead of on the PC. You’d have to know the environment variable “DISPLAY” to do that, and be the same user. If your user is logged in to the GUI on the Jetson, and in a terminal you do this:
echo $DISPLAY
…then this would likely reply “:0”. Then, without forwarding, logging in as the same user “ubuntu”, you could display to the Jetson from the host PC:

ssh ubuntu@192.168.55.1
export DISPLAY=':0'
xterm

(xterm would show up on the Jetson)

If you were to forward a file manager, then no matter where it appears, it would still be a file manager for the Jetson, not the host PC.

If you truly want everything to run on the Jetson, including CUDA, any AI, OpenGL, Vulkan, so on, then you must have a GUI running on the Jetson itself. The less obvious part is that the GUI does not have to be a physical monitor. X normally associates to a video card’s monitor, but you can get virtual X servers. A virtual server looks exactly the same to the software running on it so far as that software is concerned, but is purely a buffer with alternate program access. You run a virtual server on the Jetson, and then a virtual desktop client can run on any computer. That virtual client can be on Windows, Mac, Linux, FreeBSD, so on. I’m the wrong guy to tell you though how to set up a virtual client/server.

Something people often don’t realize is that X is not really a GUI. It is a standardized API for a buffer whereby various events result in the driver manipulating the buffer. That buffer just happens to be visible to a computer monitor, and if the commands perform graphical operations, then you see graphics. CUDA does not alter what you see on the monitor, but often it talks to the GPU via the X API (e.g., adding or multiplying an array). If your particular GPU use is designed to go through the X API then you must have X running (but it can be a virtual X without a monitor).