Troubleshooting for Robotics SDK 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>
Copy to clipboard

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 Intel® Robotics SDK 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 Intel® Robotics SDK 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
Copy to clipboard

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
Copy to clipboard

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
Copy to clipboard

To fix this conflict, remove the brltty package:

sudo apt-get remove brltty
Copy to clipboard

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
Copy to clipboard

  • 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
Copy to clipboard

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 Intel® Robotics SDK and the i915 kernel mode driver in Linux* Kernel 6.7.5 or later.

For Intel® Core™ Ultra Processors, the recommended operating system for the Intel® Robotics SDK is the Ubuntu* 22.04 LTS (Jammy Jellyfish) Desktop image, as described in the Prepare the Target System section. Since this version of the Ubuntu* operating system uses a Linux* Kernel 6.8, this incompatibility will have an impact if you use the Intel® Robotics SDK 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"
Copy to clipboard

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

Device Type                                     CPU
Device Type                                     GPU
Device Type                                     Accelerator
Copy to clipboard

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
Copy to clipboard