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 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 wrote: > >> On Tue, Nov 13, 2012 at 2:55 PM, Edwards, Shaun M. >> 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@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 > >