On a recent project with a rushed development schedule, there was a little issue. The workaround of booting the Jetson into a graphics desktop without a monitor attached is worth sharing.
Background
As is the case with a lot of projects that involve visual processing, the example framework for this project was written using a Graphical User Interface, or GUI. In the rush of development, this framework was used as the structure for building a demonstration application.
In this particular demo (Flying Robot Demo), an image stream is acquired from a camera sensor and each image is examined for the presence of a fiducial marker. The fiducial marker in this case is an April Tag, which looks like a big QR code. If a fiducial marker is recognized, then commands are sent out to the robot to control its position corresponding to the markers meaning. For example, a marker recognized as code 20 might tell the robot to move left 2 meters. A very simplistic concept.
Having a graphics program, in this case one written using the framework Qt, is useful for a person to help in the debugging purposes. In this case the camera stream is placed on the monitor, and any markers recognized are highlighted by placing a colored rectangle over the marker on the screen.
Now the computer doesn’t really care about this visual representation, it’s there purely to help the person writing the program. But here’s the thing: as a developer working with a tight deadline you need all the help you can get. The easiest thing to do in this case was to use the example framework and build on that.
Once the program was ready to be tested on the robot standalone, the demo program was marked as a startup application using the Startup Applications app through the desktop. In this case the permissions were fiddled with so that the program could talk to the USB camera. Everything was tested once more, to make sure everything worked on startup as expected.
Now this being a flying robot and all, you probably have guessed that the robot does not carry an attached HDMI monitor on board. So when the program was to the point that it was working on the bench and ready to be tested standalone, the monitor and external peripherals were detached and everything booted up. What happened next? Nothing. The robot sat there like a big fat pig and ignored any attempt at recognizing markers. Of course the natural inclination was to hook everything back up to make sure everything works. It does. Disconnect, startup. Nothing.
What Happened?
What took a little while to realize was that if there is no monitor attached to the Jetson, then the X11 graphics manager does not load, which in turns means that the desktop manager does not load. If the desktop manager does not load, the startup applications do not load. Then what happens? In this case, nothing. It just sits there silently like a big fat pig dog.
For most robot applications, programs are written as console applications. This allows for easy communication with the robot through SSH from another computer. Unfortunately in this case, the framework for controlling the robot is commingled with the graphics user interface. Given the short amount of development time available, it was unlikely that the program could be rewritten as a console app to meet the deadline.
Solution
After Googling like a chicken with its head cut off, the solution that was implemented for the demo was based on attaching a HDMI monitor emulator to the Jetson. Here’s the HDMI display Emulator used:
Headless Display Emulator @ Amazon
This emulator appears to the Jetson to be a HDMI monitor. X11 and the desktop happily load, none the wiser.
As it turns out after going to GTC 2016 and talking to knowledgeable NVIDIA people, there is a software workaround.
Allow X without HDMI at Boot
Edit /etc/X11/xorg.conf
Section "Device"
...
...
Option "AllowEmptyInitialConfiguration" "true"
EndSection
Which will allow X11 to startup without a monitor attached.
Conclusion
So there you have it. If you wander down the wrong path during development, and find yourself in a similar situation of hopeless despair, you too can tell the developer gods “Not Today!” and snatch victory from the jaws of defeat.
13 Responses
Hello, I did not have this problem with my TX1. I have only put it in auto-login with remote desktop activated. Don’t know if it is the reason it worked for me.
The resolution is small in remote desktop but could be changed by “xrandr -s 1024×768”
Interesting! Maybe the remote desktop activation does something at the lower levels to tell the desktop to load. Thank you for reading, and thank you for sharing.
which remote desktop did you use to achieve this?
Where do you get the dongle. I’ve run into the same situation. Made it work but this way is a lot easier. For some reason on the mac it will fire up if you use the alternate X server for the mac and ssh -X.But if I try on Linux its no go although lightdm is running. I’ve made it work in the past on other machines its usually a major pain. The auth and display are the sticking points. Some of the ROS stuff like rqt and the messages for the Zed won’t compile on the MAC so the dongle will be a much easier way.
Click the image to go to Amazon to buy the HDMI Emulator.
And they wonder why software projects are sometimes late and over budget!
I understand your requirements were for GUI for configuring the robot. But do you have any thoughts on how to disable VGA system altogether? Basically, i don’t want TX1 to have any desktop. SSH works and thats plenty enough. This will save bit of energy and not to mention precious memory/resources.
I don’t know, sorry.
I have bought a fit-headless, inserted in the tx1 hdmi mouth, set x11 /etc/X11/xorg.conf and restart, I use the pc machine how to connect to the tx1 desktop? Is the remote ip login?
I don’t know enough about what you’re asking to be helpful. You need to set up screen sharing on the Jetson, and have a connection with a PC program. Please ask this question in the official NVIDIA Jetson support forums: https://devtalk.nvidia.com/default/board/139/jetson-embedded-systems/
People there should be able to answer your question.
What happens if I don’t have a /etc/x11/xorg.conf file? I don’t even have an x11 directory?
Difficult to say since you do not say what type of machine you have, which version of L4T you are running, if you are running in headless mode and so on.
Hello. I’m using my jetson nano in headless mode and I’m experiencing a flickering problem using nomachine as client on windows 10 and no machine as server on ubuntu. Yesterday I’ve just bought the dummy plug model EZDIY-FAB HDMI and I’ve attached it to the jetson nano HDMI port. And under Ubuntu I went under monitor setting and I have chosen : “HDMI-0,resolution 1920 x 1080,refresh rate 60. In addition,I went under the display configuration panel of NoMachine and I’ve chosen “adapt to the window” ; I have also clicked on “modify display settings” and I have chosen “use a custom resolution to 1920 x 1080” ; quality = better. But the flickering problem is still there. Should I edit the xorg.conf file like you have explained ?