Publish sensors tfs as static, and allow configuring odom frequency

[corot]

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:

• Broadcast sensor tfs as static (though this will probably require changes on PR Added sensor pose read & write services #201 to republish the static tf if pose changes). This is already a good thing by itself, as it reduces simulation cost.
• Allow speeding up odom tf (and odom topic) with a parameter odometry_rate

[czalidis]

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.

[czalidis]

Prepend underscore to comply with the coding styleguide (I know it's ugly...).

[corot]

right

[czalidis]

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...

[corot]

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.

[czalidis]

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.

[corot]

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)