Bind device ID

When the robot uses two or more USB serial port devices, the correspondence between the device name and the device is not fixed, but is assigned in the order in which the devices are connected to the system. The relationship between the device and the device name can be determined by plugging one device first and then another device, but the device needs to be plugged in and out every time the system starts, which is very troublesome. The serial port can be mapped to a fixed device name. Regardless of the insertion order, the device will be mapped to the new device name. We only need to use the new device name to read and write the device.

Note: The ID of the supporting device has been bound to the system image. The following steps can be used as a reference for binding new devices.

5.1. Device View

After SSH connects to the car, enter in the terminal,

lsusb

Astra has an official file for binding the ID number of each device. The handle generally does not need to be bound. The main binding is PCB and radar.

Device number view

xxxxxxxxxx
ll /dev/

5.2, Device binding

5.2.1, Astra camera binding

The binding rule file of Astra camera is [56-orbbec-usb.rules], provided by Astra manufacturer, and Astra Pro is used for demonstration here.

Put the [56-orbbec-usb.rules] file in the following directory of the car:

xxxxxxxxxx
/etc/udev/rules.d/56-orbbec-usb.rules

Execute the following command in the terminal to refresh the USB rules to bind the Astra camera.

xxxxxxxxxx
sudo udevadm control --reload-rules && sudo udevadm trigger

After binding, enter the following command,

xxxxxxxxxx
ll /dev/astra*

The output is as above, indicating that the binding is successful.

5.2.2, PCB and radar binding

The car terminal executes the following command,

xxxxxxxxxx
#Enter the rules.d directory
cd /etc/udev/rules.d/
#Create a rules file and edit it
sudo vim yahboomcar.rules

Write the following content (see the tutorial [Linux Basics] for vim command usage)

xxxxxxxxxx
KERNEL=="ttyUSB*", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE:="0777", SYMLINK+="myserial"
KERNEL=="ttyACM*", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="55d4", MODE:="0777", SYMLINK+="oradar"

Save and exit, make the rules effective, execute:

xxxxxxxxxx
sudo udevadm control --reload-rules && sudo udevadm trigger

After binding, enter the following command,

xxxxxxxxxx
ll /dev/myserial #PCB
ll /dev/oradar #Radar

The output is as above, indicating that the binding is successful.

5.3, Syntax of rule file

xxxxxxxxxx
KERNEL=="ttyUSB*", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE:="0777", SYMLINK+="myserial"
KERNEL=="ttyACM*", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="55d4", MODE:="0777", SYMLINK+="oradar"

Analysis

xxxxxxxxxx
KERNEL # Match the device name of the event
ATTR{filename} # Match the sysfs attribute of the event device.
idVendor # Manufacturer number
idProduct # Product number
SYMLINK # Generate a symbolic link for the device file under /dev/. Just give this device an alias.
MODE # Set permissions for the device.

From [6.1], we can see that the device number of PCB is [ttyUSB0] which is easy to change, and the ID number is [1a86, 7523] which is fixed. [ttyUSB*] means that no matter the device number becomes [ttyUSB] followed by [0, 1, 2, 3, 4, ...], it will be bound to [myserial]; the same is true for radar device [ttyACM0]; the same is true for other devices that need to be bound.

Note: When taking an alias, do not take some device names that already exist in the system, otherwise it will fail.