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

Can't see topics published by LoCoBot on remote using ROS 2

Check that the RMW configuration for ROS 2 matches that described in the RMW Configuration Guide for the Create® 3, the LoCoBot's computer, and your remote computer.

If your RMW configuration does match, try the following:

  • Restart the ROS 2 daemon on your remote computer using the commands below:

    $ ros2 daemon stop
$ ros2 daemon start

  • Restart the ROS 2 daemon on your LoCoBot's computer using the commands below:

    $ ros2 daemon stop
$ ros2 daemon start

  • Restart the Create® 3 base.

  • Restart the LoCoBot's computer.

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.

Create® 3 base not responding to commands, can't see topics or webserver from LoCoBot computer (ROS 1 or ROS 2)

  • Check that the base's adapter board is fully plugged in and that the switch is set to USB mode.

  • Check that the base's USB-to-Ethernet adapter and Ethernet cable are fully plugged in.

  • Check that the base is powered on.

  • Check that you can ping the base from the LoCoBot's computer.

    $ ping 192.168.186.2

  • Check that your Create® 3 base is running the latest firmware for the LoCoBot computer's ROS distribution. For example, if running ROS Noetic or ROS 2 Galactic, the Create® 3 base should be on the latest G.X.X release. If running ROS 2 Humble, the Create® 3 base should be on the latest H.X.X release. See the iRobot® Create® 3 Releases 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:

  1. On your LoCoBot's computer, install chrony NTP server package

    $ sudo apt install chrony

  2. 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.

  3. 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

  4. 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

  5. Restart chrony

    $ sudo service chrony restart

  6. Verify compute NTP server is talking to the Create® 3

    $ sudo chronyc clients

  7. 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

  8. 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.

Note

Sometimes it helps to disconnect both the Create® 3 and the LoCoBot's computer from the Internet and just have them run on an isolated network.

Note

As of Create® 3 firmware versions G.4.3 and H.1.0, you can use its webserver to restart the ntpd from the Beta menu. This attempts to force the base to resync its clock. Because this is a beta feature, it may not be stable and improper use may result in an inoperable robot. See Restart ntpd for details.

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:

  1. 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.

  2. Edit the LoCoBot's .bashrc file

    $ nano ~/.bashrc

  3. 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

  4. 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.

  5. Source your .bashrc file

    $ source ~/.bashrc

  6. 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
#                                                                ^^^^^^