Troubleshooting

Jetson Nano: Capabilities fail to start

Problem

The latest Jetpack version available for Jetson Nano's does not permit the creation of overlayfs' inside a unshare -rm environment, which causes capabilities to fail to start. The log will say something like:

using unshare -r
preparing sandbox for @transitive-robotics/foxglove-webrtc (robot)
mount: /home/robot/.transitive/tmp/tmp.gJHqvyLkRF/usr/merged: permission denied.
mount: /home/robot/.transitive/tmp/tmp.gJHqvyLkRF/opt/merged: permission denied.
...

Solution

Grant the user you are using to install and run the Transitive agent password-less sudo (by adding USERNAME ALL = NOPASSWD: ALL to /etc/sudoers using visudo, where USERNAME is your username). Alternatively you can run Transitive in Docker.

Encrypted home-folder

If your home directory is encrypted, the overlayfs' Transitive uses to sandbox its capabilities will fail.

Test

If mount | grep $HOME | grep ecryptfs returns anything, then your home folder is encrypted.

Solution

Create a folder on an unencrypted filesystem anywhere else on your system (e.g., /home/$USER_unencrypted), then sym-link it to ~/.transitive (e.g., ln -s /home/$USER_unencrypted ~/.transitive). Then reinstall the Transitive agent in the newly created folder.

The device doesn't show up in the Transitive Portal

There can be several reasons for this, but most of the time it's a restriction on the network to connect to port 8883 on our cloud instance.

Test

Run:

curl -m 3 transitiverobotics.com:8883

When the port is working you will see

curl: (56) Recv failure: Connection reset by peer

If it is not working, it will be something like:

curl: (7) Failed to connect to transitiverobotics.com port 8883: Connection timed out

Solution

Talk to your network admin, which often is the IT staff of the customer where your robots are deployed, and request that they permit all traffic to transitiverobotics.com (or when self-hosting your own cloud instance), but for the very least permit port 8883.