Troubleshooting for Autonomous Mobile Robot Tutorials troubleshooting#

Use ROS_DOMAIN_ID to Avoid Interference in ROS Messages#

A typical method to demonstrate a use case requires you to start several ROS 2 nodes and exchange ROS 2 messages between the ROS 2 nodes.

However, interference from unrelated nodes – whether on the same host machine or within the local network – can disrupt the process. Debugging and resolving such interference can be challenging in this scenario.

ROS 2 uses the ROS_DOMAIN_ID environment variable to isolate several use cases from each other. For this reason, you should set this variable to a certain number before you execute a tutorial:

export ROS_DOMAIN_ID=<value>

The ROS_DOMAIN_ID should be an integer between 0 and 101 and it should be the same for all the nodes launched for a particular use case. If you run only one use case at a time, you can set this variable in your .bashrc file, as described in the Prepare your ROS 2 Environment section.

Troubleshooting AAEON Motor Control Board Issues#

Several tutorials apply an AAEON UP Xtreme i11 Robotic Development Kit to demonstrate how the Autonomous Mobile Robot can interact with a physical robot. The AAEON UP Xtreme i11 Robotic Development Kit includes a motor control board, which implements the motor drivers and the USB interface towards the compute board. To support this motor control board, the Autonomous Mobile Robot provides the Deb package ros-humble-aaeon-ros2-amr-interface, which is based on the GitHub project AAEONAEU-SW/ros2_amr_interface with some adaptations for ROS 2 Humble.

The following subsections provide solutions to fix potential issues with the USB interface of the AAEON UP Xtreme i11 Robotic Development Kit.

Add the current user to the dialout group#

To control the AAEON UP Xtreme i11 Robotic Development Kit via the USB interface, the current user must be a member of the dialout group. Use the groups command to verify that the current user belongs to the dialout group. If the user does not belong to this group, add the group membership by means of:

sudo usermod -a -G dialout $USER

Solve conflicts with the BRLTTY daemon#

BRLTTY is a background process that operates Braille displays, a tool for individuals who are blind. There is a possibility that BRLTTY may block the USB interface utilized by the AAEON motor control board. To identify such a conflict, execute the following command:

sudo dmesg -w

Connect the AAEON motor control board to one of the USB ports of the compute board. Analyze the output of the dmesg command and search for any messages that contain BRLTTY or brltty. In the following example, the lines with the time stamps 7768.502123 and 7768.618382 indicate that there is a conflict between the BRLTTY daemon and the ch341 driver.

[ 7750.500707] usb 3-4: USB disconnect, device number 11
[ 7767.801366] usb 3-4: New full-speed USB device number 12 using xhci_hcd
[ 7767.951513] usb 3-4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 7767.951532] usb 3-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 7767.951537] usb 3-4: Product: USB Serial
[ 7767.953988] ch341 3-4:1.0: ch341-uart converter detected
[ 7767.954920] usb 3-4: ch341-uart converter now attached to ttyUSB0
[ 7768.502123] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input34
[ 7768.618382] usb 3-4: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[ 7768.618952] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 7768.618976] ch341 3-4:1.0: device disconnected

To fix this conflict, remove the brltty package:

sudo apt-get remove brltty

Troubleshooting RViz2 Issues#

Set Scale Display Mode to 100%#

If you encounter a segmentation fault or see errors such as libGL error: failed to create drawable when starting RViz2 with the -d flag, the issue may be caused by the display scale mode being set to a value other than 100%.

To resolve this issue, set the display scale mode to 100%:

  1. Open the system settings on your Linux system.

  2. Navigate to the Displays section.

  3. Set the Scale option to 100%.

Enable 3D options in RViz2#

Note

Displaying in 3D consumes a lot of system resources this may interfere with the robot control commands. Intel® recommends opening rviz2 on a development system. The development system needs to be in the same network and have the same ROS_DOMAIN_ID set.

To prepare the development system follow the instructions to Prepare the Target System.

# When using different machines, set the same ROS_DOMAIN_ID as on the robot
source /opt/ros/humble/setup.bash
export ROS_DOMAIN_ID=<YOUR_ROSID>
rviz2

  • open options menu in Rviz2

    ../../../_images/aaeon_rviz2_options.png

  • enable 3D display

    ../../../_images/aaeon_rviz2_3Doption_selected.png

Troubleshooting OpenVINO™ Issues#

File Permission Errors#

If you encounter an error stating permission denied /tmp/pipeline_object.yaml, you must adjust the file’s ownership and permissions accordingly. The file ownership can be reassigned using the chown command and file permissions can be adjusted using the chmod command. Execute the following commands in your terminal to make the necessary changes:

sudo chown $USER /tmp/pipeline_object.yaml
sudo chmod u+x /tmp/pipeline_object.yaml

The first command assigns the current user as the owner of /tmp/pipeline_object.yaml, while the second command grants the owner execute permissions for this file.

Missing Model files#

Some of the OpenVINO™ based tutorials in this SDK rely on the models that are provided during the installation of the ros-humble-openvino-node. In case you missed out on installing these models you may run into problem when executing these tutorials.

Follow the instructions on Install OpenVINO™ Packages, to troubleshoot potential issues with the OpenVINO™ installation.

GPU device is not detected with Linux Kernel 6.7.5 or later#

According to the Release Notes of the Intel® Graphics Compute Runtime, there is a known incompatibility between the Intel® Graphics Compute Runtime used in this release of the Autonomous Mobile Robot and the Intel® Graphics Driver kernel mode driver in Linux Kernel 6.7.5 or later.

For Intel® Core™ Ultra Processors, the recommended operating system for the Autonomous Mobile Robot is the Ubuntu OS version 22.04 LTS (Jammy Jellyfish) Desktop image, as described in the Prepare the Target System section. Since this version of the Canonical Ubuntu operating system uses a Linux Kernel 6.8, this incompatibility will have an impact if you use the Autonomous Mobile Robot on an Intel® Core™ Ultra Processor.

To test whether your system is impacted, you can use the clinfo tool. You can install and execute this tool by means of:

sudo apt install clinfo
clinfo | grep "Device Type"

The output of the clinfo command will report the detected OpenCL™ devices:

Device Type                                     CPU
Device Type                                     GPU
Device Type                                     Accelerator

If the list of devices not include the GPU, your system is impacted.

To fix the issue, you can apply the workaround that is recommended in the Release Notes of the Intel® Graphics Compute Runtime. If you export the following debug variables before you run any of the GPU-related workloads, the GPU will be detected appropriately:

export NEOReadDebugKeys=1
export OverrideGpuAddressSpace=48