[ros-users] ROS driver supporting Sparkfun IMU
Eric Perko
wisesage5001 at gmail.com
Wed Mar 16 17:53:19 UTC 2011
On Wed, Mar 16, 2011 at 1:22 PM, Patrick Goebel <patrick at pirobot.org> 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"?
- 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 <wisesage5001 at gmail.com>wrote:
>
>> On Wed, Mar 16, 2011 at 10:17 AM, Jeff Rousseau <drzaiusx11 at gmail.com>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 <patrick at pirobot.org>
>>> 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 <abhy.12354 at gmail.com> 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 at code.ros.org
>>> >> https://code.ros.org/mailman/listinfo/ros-users
>>> >
>>> >
>>> > _______________________________________________
>>> > ros-users mailing list
>>> > ros-users at code.ros.org
>>> > https://code.ros.org/mailman/listinfo/ros-users
>>> >
>>> > _______________________________________________
>>> > ros-users mailing list
>>> > ros-users at code.ros.org
>>> > https://code.ros.org/mailman/listinfo/ros-users
>>> >
>>> >
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing listros-users at code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110316/187b2efd/attachment-0003.html>
-------------- next part --------------
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.0/video4linux/video0':
KERNEL=="video0"
SUBSYSTEM=="video4linux"
DRIVER==""
ATTR{name}=="UVC Camera (046d:0809)"
ATTR{index}=="0"
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.0':
KERNELS=="2-6:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="uvcvideo"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="01"
ATTRS{bInterfaceClass}=="0e"
ATTRS{bInterfaceSubClass}=="01"
ATTRS{bInterfaceProtocol}=="00"
ATTRS{modalias}=="usb:v046Dp0809d0010dcEFdsc02dp01ic0Eisc01ip00"
ATTRS{supports_autosuspend}=="1"
ATTRS{iad_bFirstInterface}=="00"
ATTRS{iad_bInterfaceCount}=="02"
ATTRS{iad_bFunctionClass}=="0e"
ATTRS{iad_bFunctionSubClass}=="03"
ATTRS{iad_bFunctionProtocol}=="00"
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2/2-6':
KERNELS=="2-6"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 4"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bMaxPower}=="500mA"
ATTRS{urbnum}=="10140"
ATTRS{idVendor}=="046d"
ATTRS{idProduct}=="0809"
ATTRS{bcdDevice}=="0010"
ATTRS{bDeviceClass}=="ef"
ATTRS{bDeviceSubClass}=="02"
ATTRS{bDeviceProtocol}=="01"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="2"
ATTRS{devnum}=="3"
ATTRS{devpath}=="6"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="0"
ATTRS{quirks}=="0x0"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{authorized}=="1"
ATTRS{serial}=="724DEF89"
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2':
KERNELS=="usb2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="66"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0206"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="2"
ATTRS{devnum}=="1"
ATTRS{devpath}=="0"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="6"
ATTRS{quirks}=="0x0"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 2.6.35-27-generic ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:00:1d.7"
ATTRS{authorized_default}=="1"
looking at parent device '/devices/pci0000:00/0000:00:1d.7':
KERNELS=="0000:00:1d.7"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x3a3a"
ATTRS{subsystem_vendor}=="0x1043"
ATTRS{subsystem_device}=="0x82d4"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="23"
ATTRS{local_cpus}=="00000000,000000ff"
ATTRS{local_cpulist}=="0-7"
ATTRS{modalias}=="pci:v00008086d00003A3Asv00001043sd000082D4bc0Csc03i20"
ATTRS{numa_node}=="-1"
ATTRS{dma_mask_bits}=="32"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
ATTRS{companion}==""
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
More information about the ros-users
mailing list