# Troubleshooting for Autonomous Mobile Robot Tutorials ## 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: ```bash export ROS_DOMAIN_ID= ``` 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-ros-environment](../../gsg_robot/prepare-system.md#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](https://github.com/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: ```bash 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: ```bash 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. ```console [ 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: ```bash 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](../../gsg_robot/prepare-system.md). ::::{tab-set} :::{tab-item} **Jazzy** :sync: jazzy ```bash # When using different machines, set the same ROS_DOMAIN_ID as on the robot source /opt/ros/jazzy/setup.bash export ROS_DOMAIN_ID= rviz2 ``` ::: :::{tab-item} **Humble** :sync: humble ```bash # When using different machines, set the same ROS_DOMAIN_ID as on the robot source /opt/ros/humble/setup.bash export ROS_DOMAIN_ID= rviz2 ``` ::: :::: - open options menu in Rviz2 ![aaeon_rviz2_options](../../images/aaeon_rviz2_options.png) - enable 3D display ![aaeon_rviz2_3Doption_selected](../../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: ```bash 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](../../gsg_robot/install-openvino.md), 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](https://github.com/intel/compute-runtime/releases/tag/24.09.28717.12), 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)](https://releases.ubuntu.com/22.04) Desktop image, as described in [Prepare the Target System](../../gsg_robot/prepare-system.md). 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: ```bash sudo apt install clinfo clinfo | grep "Device Type" ``` The output of the `clinfo` command will report the detected OpenCL™ devices: ```console 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](https://github.com/intel/compute-runtime/releases/tag/24.09.28717.12). If you export the following debug variables before you run any of the GPU-related workloads, the GPU will be detected appropriately: ```bash export NEOReadDebugKeys=1 export OverrideGpuAddressSpace=48 ```