0
$\begingroup$

I use 2 USB ports on my robot for the motor driver and lidar. Ports can sometimes change when I start the robot. For example; While my lidar port was "/dev/ttyUSB1" when I first started the robot, the port could be "/dev/ttyUSB0" in any subsequent startups.

I'm trying to write a udev rule so I don't have to deal with this all the time. But after making the changes, I was not successful in running the launch file. Where am I making a mistake?

Step 1: Determining idVendor and idProduct values ​​with the lsusb command

Bus 001 Device 010: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 015: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

Step2: Creating a usb-serial.rules file in the /etc/udev/rules.d directory and adding the following code to the file

SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666", SYMLINK+="usb_lidar"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE="0666", SYMLINK+="usb_motor"

Step 3: Run the following code to load the rules

sudo udevadm control --reload-rules
sudo udevadm trigger

Step 4: Adding port numbers to the launch file.

 <arg name="port_motion" default="/dev/usb_motor"/>
 <arg name="usb_motion" default="/dev/usb_lidar"/>

Additionally, when I run the ls -al /dev/usb_* command, I get the following output:

lrwxrwxrwx 1 root root 7 Jul 3 12:05 /dev/usb_motor -> ttyUSB1
lrwxrwxrwx 1 root root 7 Jul 3 12:05 /dev/usb_lidar -> ttyUSB0
$\endgroup$
2
  • $\begingroup$ What do you see when you type ls -l /dev/serial/by-id without your custom udev rules? $\endgroup$
    – ʀᴏʙ
    Commented Jul 5 at 2:19
  • $\begingroup$ I get output like this: total 0 lrwxrwxrwx 1 root root 13 Nov 21 2023 usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -> ../../ttyUSB1 lrwxrwxrwx 1 root root 13 Nov 21 2023 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_3aec6cc04636ec11a7b29e75b659684c-if00-port0 -> ../../ttyUSB0 $\endgroup$
    – furkan
    Commented Jul 5 at 5:08

2 Answers 2

0
$\begingroup$

Can you try using the following instead?

# For the FTDI cable connecting to the motor
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyUSBMotor"

# For the YDLidar
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyUSBLidar"

I'm taking a guess here, but I think the problem arises from the fact that although these systems are communicating via the USB port, they are actually communicating using the Serial interface (teletype, or TTY). You had assigned rules to the USB devices, but since they are detected as teletype devices, you needed to make the change to the tty subsystem instead.

Additionally, when I run the ls -al /dev/usb_* command, I get the following output:

lrwxrwxrwx 1 root root 7 Jul 3 12:05 /dev/usb_motor -> ttyUSB1
lrwxrwxrwx 1 root root 7 Jul 3 12:05 /dev/usb_lidar -> ttyUSB0

This behaviour can also be explained by the fact that you are renaming the USB devices and not the tty devices that they are treated as.

$\endgroup$
1
  • $\begingroup$ I made the changes you said. With these changes the ttyUSB_motor worked. But unfortunately the lidar part did not work. $\endgroup$
    – furkan
    Commented Jul 4 at 10:48
0
$\begingroup$

Broadly there's a couple of approaches for device configuration in robotic deployments. The tty USB device <-> ROS driver association has to be captured in a configuration file somewhere, either:

  1. Symlinks created by custom udev rules, e.g. the /dev/usb_motor proposed in the question: This puts per-device configuration management in system files that must be modified by root at deploy time for each robot.
  2. Symlinks created by the existing udev rules in /lib/udev/rules.d/60-serial.rules that are generally unique, e.g. /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 as noted in the question: This approach has the advantage of not requiring any custom udev rules-- instead the already-unique symlinks can be added into launch files etc.

Our preference has shifted from 1. to 2. over the years as it allows per-robot configuration to be stored in launch files that are probably also version controlled, e.g. in git. I'd recommend 2. This SO post explores symlink uniqueness-- I've never seen identical symlinks.

You didn't specify the error you're getting. Ensure your user is in the correct group, likely using sudo usermod -a -G dialout $USER. Logout so it takes effect.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.