Troubleshooting

This guide walks a user through possible issues that can occur when using an Interbotix LoCoBot and how to fix them. If, after following this guide, the issues persists, take a look at the interbotix_ros_rovers bug tracker. If you can't find an answer there, feel free to open your own issue.

Note

For troubleshooting tips on the mobile X-Series Arm or the pan-and-tilt camera mount, see the X-Series Arms Troubleshooting documentation.

Common Issues

Create® 3 base stutters or reflexed are triggered when driven

If the robot stops, turns, or reacts in an unexpected way when moving, it's possible that the reflexes are not turned off on the Create® 3 base. To fix this, you can either set the <base_namespace>/motion_control reflexes_enabled parameter to False using the ros2 param set command line tool, or set it to false in the Application ROS 2 Parameters File located in the Create® 3 webserver's ROS 2 Configuration page. If using Interbotix's default network configuration, this will be at 192.168.186.2/ros-config, assuming that the Create® 3 is turned on. See the Create 3 Configuration page for more information.

Less Common Issues

Create® 3 base clock is not synchronized

If transforms require a significant extrapolation into the past, it is possible that your Create® 3 base's clock is not in sync with the rest of your system. Errors like the one below may indicate that this is the case.

Error="Lookup would require extrapolation -27793617.761847734s into the future. Requested time 1667324891.111343861 but the latest data is at time 1639531273.349496126, when looking up transform from frame [locobot/base_footprint] to frame [locobot/odom]. canTransform returned after 0.200389 timeout was 0.2."

To solve this, check iRobot's Setup NTP on compute board to serve time to Create® 3 guide. In short, the steps are as follows:

On your LoCoBot's computer, install chrony NTP server package
```
$ sudo apt install chrony
```
Edit the config file
```
$ sudo nano /etc/chrony/chrony.conf
```
Note

To close nano with your changes, press Ctrl + S to save, and Ctrl + X to exit.

Add the following lines after the pool #.ubuntu.pool.ntp.org iburst maxsources # block

server 192.168.186.2 presend 0 minpoll 0 maxpoll 0 iburst  prefer trust
# Enable serving time to ntp clients on 192.168.186.0 subnet.
allow 192.168.186.0/24

Optionally add the following lines immediately afterward if your LoCoBot's computer will not have a connection to a reference clock (i.e., the Internet)
```
# Serve time even if not synchronized to a time source
local stratum 10
```
Restart chrony
```
$ sudo service chrony restart
```
Verify compute NTP server is talking to the Create® 3
```
$ sudo chronyc clients
```

Confirm 192.168.182.2 shows non 0 number in NTP column

Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
===============================================================================
192.168.186.2                  51      0   5   -    32       0      0   -     -
localhost                       0      0   -   -     -      31      0   7     4

Note that if there is a large jump in the time, the Create® 3 may not accept it until its next reboot. This can be verified by checking the Create® 3 robot's log for a line like
```
user.notice ntpd: ntpd: reply from 192.168.186.3: delay ### is too high, ignoring
```
If this happens, simply restart the base (not just the application) via the webserver over the USB network connection.
Sometimes the NTP daemon can be a bit sticky and will not update the base's time even when rebooted. In that case, you could connect the Create® 3 to your wireless network so that it can contact iRobot's ntp pools. For details on this process, follow the "Connect to Wi-Fi (ROS 2 Users)" steps in the Create® 3 Setup Guide.

Can't see/echo topics published by LoCoBot on remote using ROS 1

Your network may be configured incorrectly. See the ROS Multiple Machines Tutorial and the ROS Network Setup Tutorial. This may be as simple as changing the value of the ROS_IP environment variable. For example, your ROS_IP may be set to the value of the IP assigned in the connection to the Create® 3 base via the Ethernet connection, 192.168.186.3. To fix this, you can explicitly assign the variable to the IP assigned in the connection to the wireless network through the following steps:

Find all IP addresses assigned to your LoCoBot computer. You should get two addresses: one for the connection over the Ethernet network, and one for the connection over the wireless network.
```
$ hostname -I
192.168.186.3 192.168.0.171
```
If properly connected to the Ethernet network, that IP address will be 192.168.186.3. The address for the wireless network will be the other one, in this case, 192.168.0.171.
Edit the LoCoBot's .bashrc file
```
$ nano ~/.bashrc
```

Find the ROS_IP section of the Interbotix Configurations block

export ROS_IP=$(echo `hostname -I | cut -d" " -f1`)
if [ -z "$ROS_IP" ]; then
       export ROS_IP=127.0.0.1
fi

Comment this block out and add a line exporting the IP address for the wireless network
```
#export ROS_IP=$(echo `hostname -I | cut -d" " -f1`)
#if [ -z "$ROS_IP" ]; then
#       export ROS_IP=127.0.0.1
#fi
export ROS_IP=192.168.0.171
```
Note

To close nano with your changes, press Ctrl + S to save, and Ctrl + X to exit.
Source your .bashrc file
```
$ source ~/.bashrc
```
Your ROS_IP environment variable should now be properly assigned.
```
$ echo $ROS_IP
192.168.0.171
```

Can't see RViz displays on remote view using ROS 1

See Can't see/echo topics published by LoCoBot on remote.

`run_id on parameter server does not match declared run_id` when launching on remote using ROS 1

This occurs because roslaunch can't detect the roscore before starting up, leading to the run_id mismatch. To solve this, simply append the --wait argument when running roslaunch. This tells roslaunch to delay the launch until a roscore is detected.

$ roslaunch interbotix_xslocobot_descriptions remote_view.launch --wait
#                                                                ^^^^^^