Skip to main content

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

Agent install fails with npm error ETIMEOUT​

This can happen if your machine has IPv6 enabled but your ISP doesn't actually support it.

Test​

Check if you can reach registry.transitiverobotics.com using IPv4 and IPv6:

IPv4:​
🞂 ping -c1 registry.transitiverobotics.com
PING registry.transitiverobotics.com (54.184.68.133) 56(84) bytes of data.
64 bytes from ec2-54-184-68-133.us-west-2.compute.amazonaws.com (54.184.68.133): icmp_seq=1 ttl=54 time=34.6 ms

--- registry.transitiverobotics.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.626/34.626/34.626/0.000 ms

This should always work.

IPv6​

This is often the culprit. If IPv6 is not configured, you should see this, which is fine:

🞂 ping -c1 -6 registry.transitiverobotics.com
ping: connect: Cannot assign requested address

Alternatively, if IPv6 is enabled but not routed, you might see this which is fine, too:

🞂 ping -c1 -6 registry.transitiverobotics.com
ping: connect: Network is unreachable

If IPv6 is configured correctly, a healthy response looks like this:

🞂 ping -c1 -6 registry.transitiverobotics.com
PING registry.transitiverobotics.com(ip-172-31-0-118 (2600:1f13:765:7d00:8a08:72a4:2f97:499e)) 56 data bytes
64 bytes from ip-172-31-0-118 (2600:1f13:765:7d00:8a08:72a4:2f97:499e): icmp_seq=1 ttl=64 time=0.034 ms

--- registry.transitiverobotics.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.034/0.034/0.034/0.000 ms

If, however, the request times out, then something might be amiss with your or your ISP's IPv6 configuration, which leads to the seen ETIMEOUT issue.

Solution​

Disable IPv6 on your machine:

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 2>/dev/null || true
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1 2>/dev/null || true

If the agent installation works after that, you'll probably want to turn IPv6 off permanently, by adding this to your /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6=1