On Wed, Mar 16, 2011 at 1:53 PM, Eric Perko wrote: > On Wed, Mar 16, 2011 at 1:22 PM, Patrick Goebel wrote: > >> Adam got my firmware situation worked out for the Razor IMU so I am now >> getting data over the /dev/imu device and the /imu ROS topic. >> >> And Adam's udev rule below (after substituting for my serial number) works >> perfectly for me under Ubuntu 10.04. However, the following rule based on >> the Eric's link to answers.ros.org does not: >> >> SUBSYSTEMS=="usb", KERNEL=="ttyUSB[0-9]*", ATTRS{idVendor}=="0403", >> ATTRS{idSeri >> al}=="A600eIpn", SYMLINK+="imu" >> > > I have a guess at why this might not be working. See below for details. > > >> >> Googling around for more info on this topic, it appears that some people >> use a command called "udevinfo" for getting device attributes but the >> command does not exist under Ubuntu 10.04. Instead, you're supposed to use >> udevadm. For example, on my system where the IMU is on device /dev/ttyUSB1 >> I get: >> >> $ udevadm info -q all -n /dev/ttyUSB1 >> P: >> /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1/tty/ttyUSB1 >> N: ttyUSB1 >> S: char/188:1 >> S: serial/by-path/pci-0000:00:1d.7-usb-0:1.3:1.0-port0 >> S: serial/by-id/usb-FTDI_FT232R_USB_UART_A600eIpn-if00-port0 >> E: UDEV_LOG=3 >> E: >> DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1/tty/ttyUSB1 >> E: MAJOR=188 >> E: MINOR=1 >> E: DEVNAME=/dev/ttyUSB1 >> E: SUBSYSTEM=tty >> E: ID_PORT=0 >> E: ID_PATH=pci-0000:00:1d.7-usb-0:1.3:1.0 >> E: ID_VENDOR=FTDI >> E: ID_VENDOR_ENC=FTDI >> E: ID_VENDOR_ID=0403 >> E: ID_MODEL=FT232R_USB_UART >> E: ID_MODEL_ENC=FT232R\x20USB\x20UART >> E: ID_MODEL_ID=6001 >> E: ID_REVISION=0600 >> E: ID_SERIAL=FTDI_FT232R_USB_UART_A600eIpn >> E: ID_SERIAL_SHORT=A600eIpn >> E: ID_TYPE=generic >> E: ID_BUS=usb >> E: ID_USB_INTERFACES=:ffffff: >> E: ID_USB_INTERFACE_NUM=00 >> E: ID_USB_DRIVER=ftdi_sio >> E: ID_IFACE=00 >> E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd >> E: ID_MODEL_FROM_DATABASE=FT232 USB-Serial (UART) IC >> E: DEVLINKS=/dev/char/188:1 >> /dev/serial/by-path/pci-0000:00:1d.7-usb-0:1.3:1.0-port0 >> /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600eIpn-if00-port0 >> >> From this output, I never would have guessed Adam's solution. For one >> thing, there isn't even a "product" attribute listed. Does this mean that >> people are using a different command/utility for getting the device info? >> > > Since udev can match attributes from the lowest device level (ie the driver > (ftdi_sio) ) or one level up the parent chain (so, say, generic USB at once > point or even up to the PCI bus the USB connects to), you will also want to > include the parent devices. To do this, include the "--attribute-walk" > option when you run the udevadm query. See the attached udevadm output for a > sample when I run "udevadm info -q all --attribute-walk" against my UVC > webcam. Note that there are a number of "parent devices" that are more > generic, such as the USB host controller in my PC. See > http://reactivated.net/writing_udev_rules.html#udevinfo for the rules > about using multiple parent devices when matching attributes in your udev > rules. The short of it is that you have to pick a single parent device to > match against. > > Now, to address your earlier difficulty with the modification to that rule. > I don't have an FTDI device handy, so I may be wrong, but is the serial you > are trying to match actually on the same "parent device" as the idVendor > attribute you are also matching against? If it's on a different parent > device, that would be the source of the problem. If you aren't sure about it > from the output (or if it looks correct), post the output of udevadm that > you had above, but including the "--attribute-walk" option as well and I'll > see if I spot anything weird. > > Though, thinking about it, I think the serial attribute would have to be on > whatever device got selected by "idVendor" for me to include it later on in > the %s{serial} bit in my symlink... Is it actually called "idSerial" or > "serial" in the output from adding "--attribute-walk"? > Well... I was just handed an Arduino I had forgotten was around and checked udevadm. The issue is that the attribute you want to match on is called "serial" not "idSerial". Change your modification to the udev rule I posted accordingly and I would expect it to work just fine. I definitely prefer the --attribute-walk version of udevadm since it outputs the actual names of the attributes (as udevinfo did) that you can match on in your udev rules. - Eric > > - Eric > > >> >> Thanks! >> patrick >> >> >> >> On 03/16/2011 07:56 AM, Adam Stambler wrote: >> >> Hello, >> >> Using a udev script like that is exactly what we are doing right now on >> our robots with all of our serial ports. We have udev scripts matching the >> FTDI serial number to the device name. >> >> For example: >> KERNEL=="ttyUSB[0-9]*", ATTRS{product}=="FT232R USB UART", >> ATTRS{serial}=="A700ek5i", SYMLINK+="imu" >> >> My end goal, was to have udev launch an avr_bridge script that queries the >> device for the name programmed into it. This name would then become the >> /dev symbol. However, I haven't gotten the udev script working for that >> yet. >> >> -Adam >> >> On Wed, Mar 16, 2011 at 10:50 AM, Eric Perko wrote: >> >>> On Wed, Mar 16, 2011 at 10:17 AM, Jeff Rousseau wrote: >>> >>>> Just a thought, but make sure that /dev/ttyUSB0 is actually the razor. >>>> I'd be careful doing a symlink from USB0 to /dev/imu unless you really >>>> only have a single usb serial device in your system. I have 3 on my >>>> robot, so I just created some udev scripts like shown on the hokyo >>>> tutorial: >>>> >>>> >>>> http://www.ros.org/wiki/hokuyo_node#Using_udev_to_Give_Hokuyos_Consistent_Device_Names >>> >>> >>> For an example udev script that will assign a unique device name to an >>> FTDI chip (which is what does serial->usb for the Sparkfun IMU), see >>> http://answers.ros.org/question/65/how-can-i-get-a-unique-device-path-for-my . >>> You could then symlink /dev/imu to that unique device path and be 100% sure >>> that /dev/imu is definitely the IMU, regardless of how many other ttyUSB >>> devices you have or the order they were plugged in in. >>> >>> - Eric >>> >>> >>>> >>>> >>>> On Sat, Mar 12, 2011 at 10:03 AM, Patrick Goebel >>>> wrote: >>>> > Hi Adam, >>>> > >>>> > Thanks for making this wrapper available. I have a Sparkfun 9d_razor >>>> and I >>>> > have upgraded the firmware using the .pde files in >>>> > imu_9drazor/src/SF9DOF_AHRS. I did this under Windows using the >>>> Arduino IDE >>>> > (version 0022) and the upload proceeded without errors. >>>> > >>>> > Back on Linux with the IMU on port /dev/ttyUSB0 I followed the Wiki >>>> > instructions: >>>> > >>>> > $ sudo ln -s /dev/ttyUSB0 /dev/imu >>>> > $ roslaunch imu_9drazor imu.launch >>>> > >>>> > The launch proceeded without errors with the output: >>>> > process[imu_node-1]: started with pid [23276] >>>> > process[imu_msg_converter-2]: started with pid [23277] >>>> > >>>> > However, when I echo the imu topic with "rostopic echo imu" there is >>>> no data >>>> > being published. Ditto for the topic imu/imu_raw. Both topics are >>>> listed >>>> > with "rostopic list". >>>> > >>>> > One silly question: aside from having the IMU connected to the USB >>>> port, do >>>> > I also have to apply power to the white power connector? I did not >>>> have to >>>> > do this under Windows to see data via the firmware test application. >>>> > >>>> > Any thoughts? >>>> > >>>> > Thanks! >>>> > Patrick Goebel >>>> > http://www.pirobot.org >>>> > >>>> > >>>> > On 01/10/2011 09:06 PM, Adam Stambler wrote: >>>> > >>>> > Hi, >>>> > >>>> > Just an IMU won't be able to track the position of the IMU over time. >>>> It >>>> > can be combined with odometry measurements with a kalman filter to a >>>> decent >>>> > estimate though. >>>> > >>>> > If you are looking for a sparkfun IMU with a premade ros-wrapper, I >>>> have a >>>> > wrapper for the sparkfun 9d razor imu called imu_9drazor. It is a >>>> part of >>>> > the rutgers-ros-pkg. >>>> > >>>> > Regards, >>>> > Adam >>>> > >>>> > On Mon, Jan 10, 2011 at 11:58 PM, abhy wrote: >>>> >> >>>> >> hello, >>>> >> >>>> >> Does ROS have Sparkfun IMU supporting driver? >>>> >> >>>> >> " >>>> http://www.robotshop.com/sfe-atomic-imu-6-degrees-of-freedom-xbee-ready-1.html >>>> " >>>> >> >>>> >> Is this IMU sufficient for giving X, Y, Z coordinates of the Robot? >>>> >> >>>> >> Thanks, >>>> >> Abhy >>>> >> -- >>>> >> View this message in context: >>>> >> >>>> http://ros-users.122217.n3.nabble.com/ROS-driver-supporting-Sparkfun-IMU-tp2232681p2232681.html >>>> >> Sent from the ROS-Users mailing list archive at Nabble.com. >>>> >> _______________________________________________ >>>> >> ros-users mailing list >>>> >> ros-users@code.ros.org >>>> >> https://code.ros.org/mailman/listinfo/ros-users >>>> > >>>> > >>>> > _______________________________________________ >>>> > ros-users mailing list >>>> > ros-users@code.ros.org >>>> > https://code.ros.org/mailman/listinfo/ros-users >>>> > >>>> > _______________________________________________ >>>> > ros-users mailing list >>>> > ros-users@code.ros.org >>>> > https://code.ros.org/mailman/listinfo/ros-users >>>> > >>>> > >>>> _______________________________________________ >>>> ros-users mailing list >>>> ros-users@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-users >>>> >>> >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >>> >>> >> >> _______________________________________________ >> ros-users mailing listros-users@code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users >> >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> >> >