Publish sensors tfs as static, and allow configuring odom frequency#202
Publish sensors tfs as static, and allow configuring odom frequency#202corot wants to merge 2 commits intostdr-simulator-ros-pkg:indigo-develfrom
Conversation
There was a problem hiding this comment.
Thanks for your PR. I went ahead and created a review with some minor comments. It generally looks good; we would need to make some changes in the future to address the use case of a moving sensor (proposed by #201), but this is not in the scope of the current PR.
| tf::TransformBroadcaster _tfBroadcaster; | ||
|
|
||
| //!< ROS tf2 static transform broadcaster | ||
| tf2_ros::StaticTransformBroadcaster static_broadcaster; |
There was a problem hiding this comment.
Prepend underscore to comply with the coding styleguide (I know it's ugly...).
| //we should not start the timer, until we have a motion controller | ||
| _tfTimer = n.createTimer( | ||
| ros::Duration(0.1), &Robot::publishTransforms, this, false, false); | ||
| ros::Duration(1.0/odometry_rate), &Robot::publishTransforms, this, false, false); |
There was a problem hiding this comment.
Could we put the default to 100Hz and not use the parameter? If you use the parameter you would need to check for division by zero. I also don't know what would be the computational impact if we increase to 100Hz though...
There was a problem hiding this comment.
Impact is small, I get similar same CPU usage (~85% vs. ~90% in my machine). What is normal as the function is quite light. But 50 Hz would be equally fine.
| getName(), | ||
| _sensors[i]->getFrameId())); | ||
| } | ||
| _odomPublisher.publish(odom); |
There was a problem hiding this comment.
In this function the same time can be used when publishing odometry and the pose tf, instead of ros::Time::now() twice, in order to avoid the issue that you mentioned in your ROS Answer.
There was a problem hiding this comment.
true. In fact, using the same timestamp also for the sensors made things better (though using static tf is much much better anyway and the reasonable thing to do)
As explained in this ROS answer, the 10Hz at witch STDR publishes odom and sensors TFs causes important delays when processing sensor readings. So solution has two parts: