[ros-users] sensor_msgs Low Cost/Android review

[Ivan Dryanovski]

Are there established conventions about the frame_id of imu messages, and
the IMU pipeline of filters/publishers?

I find this to be a source of confusion. I've seen IMU messages with frames
like "imu" or "imu_link" implying this is the frame attached to the sensor
(just like laser scan messages have a frame "laser"). However, the
orientation in the IMU message is expressed in reference to a fixed frame,
so this implication is misleading. Using "odom" or "map" seems to be bad
practice too - if the IMU publisher publishes a transform, it starts
creating conflicts in the tf tree.

Is this a good place to start discussing these conventions, or should we
make another thread?


On Tue, Nov 13, 2012 at 7:51 PM, Chad Rockey <chadrockey at gmail.com> wrote:

> Rospy can also use fields that do not have to be the same in all types of
> messages.
>
> For instance: 'rostopic echo /odom/header/stamp'  or more extreme:
> 'rostopic echo /odom/pose/pose/position/x'
> http://www.ros.org/doc/api/nav_msgs/html/msg/Odometry.html
>
> The topic is /odom, the message type is nav_msgs/Odometry.  At run time,
> rostopic uses this function (
> https://github.com/ros/ros_comm/blob/master/tools/rostopic/src/rostopic/__init__.py#L544)
> to determine which piece of the message is relevant and return that type.
>  (This is where the /odom/header/stamp' gets converted into
> msg.header.stamp:
> https://github.com/ros/ros_comm/blob/master/tools/rostopic/src/rostopic/__init__.py#L276
> )
>
> This is best used for types that are not passed back over the wire.
>  'rostopic echo' prints these values to console.  rqt's plot will plot
> numerical values for immediate display.  It's likely possible to create a
> publisher based on the received types and publish a more appropriate output
> message.  However, you still encounter the difficulties I mentioned
> previously.
>
> On Tue, Nov 13, 2012 at 3:46 PM, Brian Gerkey <gerkey at osrfoundation.org>wrote:
>
>> On Tue, Nov 13, 2012 at 2:55 PM, Edwards, Shaun M. <sedwards at swri.org>
>> wrote:
>> > I understand why you would want messages to have semantic meaning, but I
>> > think the thin node wrapper method is problematic from a coding and
>> > usability standpoint.  From a coding standpoint, each wrapper node
>> would be
>> > a near copy and paste.  This is almost universally bad coding practice.
>> > From a usability standpoint, it would require someone to code
>> *something*
>> > anytime they wanted to take an average of a reading.  I had a recent
>> > application where I wanted to plot averages and current readings at the
>> same
>> > time to determine options for reducing noise.  I’d hate to have to
>> program a
>> > special node every time I wanted to perform the experiment.
>> >
>> > Perhaps there is a way (probably in python) to use some message
>> > introspection to achieve a generic node.  The node could simply look for
>> > int/real types and then perform the filtering automatically.  Perhaps a
>> > parameter list could be used to specify the message members (as strings)
>> > that should be filtered, intead.  Such an approach may also work with
>> > messages of multiple members (I’m thinking pose).   What do you think?
>>
>> Attached is a simple rospy script that uses some of rostopic.  It can
>> subscribe to any topic that contains a field called 'data' that Python
>> can do arithmetic with, and can handle mixing types.  It'll do a naive
>> moving-window average on the received values and publish the result as
>> a std_msgs/Float64.
>>
>> To try it, start some publishers:
>>
>> rostopic pub -r 10 in1 std_msgs/Float64 1.0 &
>> rostopic pub -r 10 in2 std_msgs/Float32 2.0 &
>> rostopic pub -r 10 in3 std_msgs/Int64 42 &
>>
>> Then start the averager:
>>
>> python avg.py
>>
>> That's just a quick and dirty demo; lots more can be done in that
>> direction.
>>
>>     brian.
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121114/0d123890/attachment-0004.html>