<div>Are there established conventions about the frame_id of imu messages, and the IMU pipeline of filters/publishers?</div><div><br></div><div>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.</div>
<div><br></div><div> Is this a good place to start discussing these conventions, or should we make another thread?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 7:51 PM, Chad Rockey <span dir="ltr"><<a href="mailto:chadrockey@gmail.com" target="_blank">chadrockey@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Rospy can also use fields that do not have to be the same in all types of messages.<div><br></div><div>For instance: 'rostopic echo /odom/header/stamp' or more extreme: 'rostopic echo /odom/pose/pose/position/x'</div>
<div><a href="http://www.ros.org/doc/api/nav_msgs/html/msg/Odometry.html" target="_blank">http://www.ros.org/doc/api/nav_msgs/html/msg/Odometry.html</a></div><div><br></div><div>The topic is /odom, the message type is nav_msgs/Odometry. At run time, rostopic uses this function (<a href="https://github.com/ros/ros_comm/blob/master/tools/rostopic/src/rostopic/__init__.py#L544" target="_blank">https://github.com/ros/ros_comm/blob/master/tools/rostopic/src/rostopic/__init__.py#L544</a>) 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: <a href="https://github.com/ros/ros_comm/blob/master/tools/rostopic/src/rostopic/__init__.py#L276" target="_blank">https://github.com/ros/ros_comm/blob/master/tools/rostopic/src/rostopic/__init__.py#L276</a>)</div>
<div><br></div><div>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.<br>
<br><div class="gmail_quote"><div><div class="h5">On Tue, Nov 13, 2012 at 3:46 PM, Brian Gerkey <span dir="ltr"><<a href="mailto:gerkey@osrfoundation.org" target="_blank">gerkey@osrfoundation.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div>On Tue, Nov 13, 2012 at 2:55 PM, Edwards, Shaun M. <<a href="mailto:sedwards@swri.org" target="_blank">sedwards@swri.org</a>> wrote:<br>
> I understand why you would want messages to have semantic meaning, but I<br>
> think the thin node wrapper method is problematic from a coding and<br>
> usability standpoint. From a coding standpoint, each wrapper node would be<br>
> a near copy and paste. This is almost universally bad coding practice.<br>
> From a usability standpoint, it would require someone to code *something*<br>
> anytime they wanted to take an average of a reading. I had a recent<br>
> application where I wanted to plot averages and current readings at the same<br>
> time to determine options for reducing noise. I’d hate to have to program a<br>
> special node every time I wanted to perform the experiment.<br>
><br>
> Perhaps there is a way (probably in python) to use some message<br>
> introspection to achieve a generic node. The node could simply look for<br>
> int/real types and then perform the filtering automatically. Perhaps a<br>
> parameter list could be used to specify the message members (as strings)<br>
> that should be filtered, intead. Such an approach may also work with<br>
> messages of multiple members (I’m thinking pose). What do you think?<br>
<br>
</div>Attached is a simple rospy script that uses some of rostopic. It can<br>
subscribe to any topic that contains a field called 'data' that Python<br>
can do arithmetic with, and can handle mixing types. It'll do a naive<br>
moving-window average on the received values and publish the result as<br>
a std_msgs/Float64.<br>
<br>
To try it, start some publishers:<br>
<br>
rostopic pub -r 10 in1 std_msgs/Float64 1.0 &<br>
rostopic pub -r 10 in2 std_msgs/Float32 2.0 &<br>
rostopic pub -r 10 in3 std_msgs/Int64 42 &<br>
<br>
Then start the averager:<br>
<br>
python avg.py<br>
<br>
That's just a quick and dirty demo; lots more can be done in that direction.<br>
<span><font color="#888888"><br>
brian.<br>
</font></span><br></div></div><div class="im">_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>