I'm not sure if this a bug or a 'feature', but I'm seeing that if I do something like:

rostopic pub -r 50 /sometopic geometry_msgs/TransformStamped '{header: auto, child_frame_id: /bla, transform: {translation: {x: 0, y: 0, z: 0}, rotation: {x: 0, y: 0, z: 0, w: 1}}}'

or

rostopic pub -r 50 /sometopic geometry_msgs/TransformStamped '{header: {stamp: now, frame_id: foo}, child_frame_id: /bla, transform: {translation: {x: 0, y: 0, z: 0}, rotation: {x: 0, y: 0, z: 0, w: 1}}}'

.. then the header timestamp is populated, but only with a single time (I guess the time the first message is sent). It would make more sense to me to have the timestamp change with every message. Is there a reason it doesn't?

change log:
Changed 15 months ago by kwc

similarly,

https://code.ros.org/trac/ros-pkg/ticket/5192

rostopic doesn't subscribe to simtime, so the timestamp is always walltime

ticket 5192 follows:

When I have gazebo running, "rostopic pub" fills the time stamp with the wall time instead of the simulation time:

<launch>
  <param name="/use_sim_time" value="true" />

  <node name="gazebo" pkg="gazebo" type="gazebo" args="-u $(find gazebo_worlds)/worlds/empty.world" respawn="false" output="screen"/>

  <node pkg="rostopic" type="rostopic" name="fake_wheel_joint_states"
    args="pub -r 1 /joint_states sensor_msgs/JointState '{header: auto, name: [dummy_joint], position: [0.0]}'" /> 
</launch>

As you can see, the stamp is filled with wall time; also, the time stamp doesn't change:

$ rostopic echo /joint_states
header: 
  seq: 1
  stamp: 
    secs: 1317580589
    nsecs: 692742109
  frame_id: ''
name: ['dummy_joint']
position: [0.0]
velocity: []
effort: []

---
header: 
  seq: 2
  stamp: 
    secs: 1317580589
    nsecs: 692742109
  frame_id: ''
name: ['dummy_joint']
position: [0.0]
velocity: []
effort: []

---

This seems to be caused by this line:

# disable /rosout and /rostime as this causes blips in the pubsub network due to rostopic pub often exiting quickly
rospy.init_node('rostopic', anonymous=True, disable_rosout=True, disable_rostime=True)

Wouldn't it be more sensible to enable rostime if

rostopic is called with the '-r' parameter (in other words, it won't exit quickly), and/or
the parameter use_sim_time is set?
Currently, "rostopic pub" is almost useless in simulation.

ticket 5192 change history:
Changed 15 months ago by gerkey

owner changed from gerkey to kwc
This ticket should really move to the ros Trac, but the TicketMoverPlugin seems have been disabled or removed in the recent server upgrade.

Changed 15 months ago by martin_guenther

Ooops, sorry about that. I actually started off at the right entry page ( https://code.ros.org/trac/ros/) without realizing that this was already the entry page, saw the list of available tracs and clicked right through to ros-pkg, since that seemed to fit best.

Perhaps the entry pages of the ros, ros-pkg and wg-ros-pkg tracs could have a message at the top saying something like "This is the bug tracker for the ROS core software (e.g. ROS client libraries, roslaunch, rostopic). To file a ticket, log in and select "new ticket" on the right." (like on http://www.ros.org/wiki/Tickets). Perhaps this would help with other people like me who can click faster than they can think.

Changed 15 months ago by kwc

status changed from new to closed
resolution set to duplicate
duplicate:

https://code.ros.org/trac/ros/ticket/3174

Changed 15 months ago by kwc

status changed from closed to reopened
resolution duplicate deleted
actually, this is different (read to fast, reopen)

Changed 15 months ago by kwc

status changed from reopened to closed
resolution set to duplicate
rather than fix the ticket move plugin, I updated 3174 with the additional detail of simtime vs. walltime as it's generally the same block of code at fault. Unfortunately, it's also a tricky block of code to fix as it requires a general API rewrite.