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.
Capabilities fail to start, throw error
On a system with ROS, when capabilities don't start and these errors appear in the log:
sh: 1: /opt/ros/humble/setup.bash: Bad substitution
sh: 6: /opt/ros/humble/setup.bash: builtin: not found
sh: 11: .: cannot open /setup.sh: No such file
Then the default shell for the user running the Transitive agent is probably sh
instead of bash
.
Solution
As the user running the agent, run:
chsh -s /bin/bash