Robohub.org
 

Configuring multiple USB devices: An alternative to udev


by
16 December 2015



share this:

USB_iconsEvery time I need to add multiple USB devices to a computer I get nervous and dread the architecture. The problem is that when a computer boots it automatically brings up USB devices in whatever order it sees fit (think crazy race conditions). So if you have a motor controller, a camera, and a LIDAR that all use USB, it can be difficult to know which device on the computer is which. You could check and manually change these every time you run your programs, but it’s better to have your programs auto-detect which device to connect to.

There are some specialty cases that can make this problem easier. Most USB devices (in Linux) show up as /dev/ttyUSBX, where X is the number in which that device was initialized (ex. /dev/ttyUSB0). Some devices will come up differently. For example Hokuyo LIDAR’s show up as /dev/ttyACMX. And USB joysticks show up as a joystick device in /dev/input/jsX. So if you have one each of a joystick, a Hokuyo, and a motor controller, you might get lucky and have them all map to different devices. But for the many times you are not lucky, how should you deal with it?

(Random note: ACM refers to a USB modem. Most devices that we use are not really modems and just ‘lie’ and claim to be an ACM device (often when they do the USB “stuff” on the main processor). Many USB-to-serial converter chips (such as FTDI) do not lie and show up as /dev/ttyUSB.)

The traditional answer is to use udev rules. The basic idea is to make a file in /etc/udev/rules.d/ that will control how a device gets mapped and started. This allows you to change the links, change permissions, or run a script when a device is detected. A basic udev rule can follow the format of:

SUBSYSTEMS==”usb”, KERNEL==”ttyACM[0-9]*”, ACTION==”add”, ATTRS{idVendor}==”15d1″, ATTRS{idProduct}==”0000″, MODE=”666″, PROGRAM=”/opt/ros/hydro/lib/urg_node/getID /dev/%k q”, SYMLINK+=”sensors/hokuyo_%c”, GROUP=”dialout”

A great tutorial on udev (and also where I got the rule above) is the “Do more with udev” tutorial from Clearpath Robotics.

In my experience using udev rules work well to set startup permissions (to allow non-root access to the device) or to run a script when a device is connected. However the symlink that maps a device to a specific name will sometimes create a link that you cannot open (ie. when open(/dev/newSymLink) fails). There are also cases where you cannot use udev in certain embedded systems or where you do not want to “install” udev rules.

There are several ways to avoid using udev. For example you could run the dmesg command to find where the USB device was connected. Another way is to have a script run whenever a device is plugged in that updates a text file that stores the device name.

Another solution (presented below) is ugly but it has tested well in cases where udev was giving me a hard time. The solution below is easier than parsing dmesg and does not require a udev rule to create a symlink that needs to be installed.

The first step, which I got from here, gets the mapping of all your devices and the associated port numbers.

#!/bin/bash
for sysdevpath in $(find /sys/bus/usb/devices/usb*/ -name dev); do
(
syspath=”${sysdevpath%/dev}”
devname=”$(udevadm info -q name -p $syspath)”
[[ “$devname” == “bus/”* ]] && continue
eval “$(udevadm info -q property –export -p $syspath)”
[[ -z “$ID_SERIAL” ]] && continue
echo “/dev/$devname – $ID_SERIAL”
)
done

Running the script above will give you a list of all the attached USB devices. You can save the script above into a file called list_usb_devices.sh.

The next step is to run that script from your program. To do that I found some code that allows you to run a system call and get the output into a string.

#include <string>
#include <iostream>
#include <cstdio>
#include <memory>

std::string system_exec(char* cmd)
{
std::shared_ptr pipe(popen(cmd, “r”), pclose);
if (!pipe) return “ERROR”;
char buffer[128];
std::string result = “”;
while (!feof(pipe.get())) {
if (fgets(buffer, 128, pipe.get()) != NULL)
result += buffer;
}
return result;
}

Adding the above to the driver for the USB device, you can now use the following to get the port that you need to open:

// get the names, grep to search for the device we want, cut the name of the port from the full line of text
std::string port = system_exec(“//list_usb_devices.sh |grep -m 1 |cut -c 1-12″);

// Get rid of any newlines (n) in the string
port.erase(std::remove(port.begin(), port.end(), ‘n’), port.end());

// switch to string to c style for using in the open command
const char * device = port.c_str();

// Finally we can now open our device
fd = open(device, O_RDWR | O_NOCTTY);

This approach is ugly, but it works. By simply using the bash script and the system call from the c++ portion you can easily adapt this to any programming environment.

The above approach is often the wrong approach (since it is ugly), but it can help when udev is not working as expected or it can not be used.

I still avoid using USB devices when possible since they are a pain and are often not reliable. However if you must use them, then the information above **might** make your life a little better. I hope it helps! Please leave comments below if this helped you or with other ways to handle USB devices.

 

 



tags:


Robots for Roboticists David Kohanbash is a Robotics Engineer in Pittsburgh, PA in the United States. He loves building, playing and working with Robots.
Robots for Roboticists David Kohanbash is a Robotics Engineer in Pittsburgh, PA in the United States. He loves building, playing and working with Robots.





Related posts :



AI-powered robots help tackle Europe’s growing e-waste problem

  12 May 2025
EU-funded researchers have developed adaptable robots that could transform the way we recycle electronic waste, benefiting both the environment and the economy.

Robot Talk Episode 120 – Evolving robots to explore other planets, with Emma Hart

  09 May 2025
In the latest episode of the Robot Talk podcast, Claire chatted to Emma Hart from Edinburgh Napier University about algorithms that 'evolve' better robot designs and control systems.

Robot Talk Episode 119 – Robotics for small manufacturers, with Will Kinghorn

  02 May 2025
In the latest episode of the Robot Talk podcast, Claire chatted to Will Kinghorn from Made Smarter about how to increase adoption of new tech by small manufacturers.

Multi-agent path finding in continuous environments

  01 May 2025
How can a group of agents minimise their journey length whilst avoiding collisions?

Interview with Yuki Mitsufuji: Improving AI image generation

  29 Apr 2025
Find out about two pieces of research tackling different aspects of image generation.

Robot Talk Episode 118 – Soft robotics and electronic skin, with Miranda Lowther

  25 Apr 2025
In the latest episode of the Robot Talk podcast, Claire chatted to Miranda Lowther from the University of Bristol about soft, sensitive electronic skin for prosthetic limbs.

Interview with Amina Mević: Machine learning applied to semiconductor manufacturing

  17 Apr 2025
Find out how Amina is using machine learning to develop an explainable multi-output virtual metrology system.

Robot Talk Episode 117 – Robots in orbit, with Jeremy Hadall

  11 Apr 2025
In the latest episode of the Robot Talk podcast, Claire chatted to Jeremy Hadall from the Satellite Applications Catapult about robotic systems for in-orbit servicing, assembly, and manufacturing.



 

Robohub is supported by:




Would you like to learn how to tell impactful stories about your robot or AI system?


scicomm
training the next generation of science communicators in robotics & AI


©2025.05 - Association for the Understanding of Artificial Intelligence


 












©2025.05 - Association for the Understanding of Artificial Intelligence