[ros-users] ROS driver supporting Sparkfun IMU

Wed Mar 16 17:59:30 UTC 2011

On Wed, Mar 16, 2011 at 1:53 PM, Eric Perko <wisesage5001 at gmail.com> wrote:

> 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"?
>

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 <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/d9de3676/attachment-0003.html>