-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create udev rules for usb devices #51
Comments
In general, sound like a nice idea. But why did you do it? We never had any problem with those devices being confused... I'm sure @marc-hanheide was a previously against using udev rules for the joystick? |
We had to add a USB-controlled device that allows to switch the docking light on and off independently of the cameras. |
That device appears sometimes as ttyUSB5 and sometimes as ttyUSB0. |
Was I? I don't recall that... Did I give a reason?
|
The scenario you gave: A new student plugs in the joystick and can't figure out why he doesn't get a /dev/input/js[01], wastes time when it turns out a UDEV rule lurking somewhere has changed the normal device path. "It worked my laptop/pc, why is it not working on the robot?" I'm certainly for UDEV rules, we have one for the joystick here. However, we need to document them, especially if we use them for the devices above, because it means that if a non-strands robot owner wants to use the drivers, they also need to create the UDEV rules, or change the attributes XML... |
Hi,
I think we should create a set of udev rules for our usb devices. Right now we created this rules for Linda so the laser is connected to /dev/laser instead of /dev/ttyUSB0 and the can bus to /dev/can instead of /dev/ttyUSB2.
This would only mean replacing the name for these devices on:
@gestom can send instructions on how to do this but he would need to make sure that the device IDs for every device on the robots is the same, you can get the ids by running
udevadm info --name=/dev/ttyUSB0 --attribute-walk
Any coments on this? @hawesie @bfalacerda @nilsbore @cburbridge
The text was updated successfully, but these errors were encountered: