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 #
blockserver 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 columnHostname 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 blockexport 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
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
# ^^^^^^