ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

urg_node timestamp way too far in the future

asked 2016-02-02 09:28:01 -0500

Reuben John gravatar image

updated 2016-02-02 09:29:59 -0500

I am trying to get the urg_node to publish scans to the default topic (laser) and the default frame_id (laser). It all works fine when I couple the commands: rosrun urg_node urg_node _ip_address:="192.168.0.10" _ip_port:-"10940" and rosrun tf static_transform_publisher 0 0 0 0 0 0 map laser 40 in two terminals.

But my original intention is to be able to publish it on the laser topic and have the map to laser transform as NOT static. But this means that the transform now has an additional requirement that they their time stamps should be synchronized. But they are not! The laser messages are being published with the time stamp on a scale of 1454425297 seconds as opposed to the rest of the nodes (including the ones publishing the other transforms) which are on a scale of just a few 100 seconds (corresponding to the time passed since I started the roscore).

I would also like to note that I am using gazebo to publish these other transforms.

My question is:
Obviously these time stamps have to match up and there are only two obvious approaches:

  1. Somehow get the lidar to publish laser messages with the timestamp of the gazebo nodes.
  2. Have all other nodes publish messages with the timestamp of the LIDAR.

Unfortunately, I am unable to do either.

Things I tried:

  • rosrun urg_node urg_node _ip_address:="192.168.0.10" _ip_port:-"10940" calibrate_time:="true"
  • rosrun urg_node urg_node _ip_address:="192.168.0.10" _ip_port:-"10940" time_offset:-"-1454425297.0"
  • <include file="$(find manas_ackermann_navigation)empty_world.launch"> <param name="use_sim_time" value="true"/> </include>
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2016-02-02 09:42:57 -0500

Pretty sure you accidentally set "use_sim_time" to true on the parameter server. Once this parameter is set, all ROS nodes started listen to the /clock topic for time. Make sure to kill your roscore, start up everything and then run

rosparam get use_sim_time

If it returns "true" you have some launch file that sets sim time to true, causing the observed problems.

edit flag offensive delete link more

Comments

Your right! rosparam get use_sim_time returns true! But even after tutorial command: roslaunch gazebo_ros empty_world.launch paused:=true use_sim_time:=false gui:=true throttled:=false headless:=false debug:=true, it shows true. rosparam set /use_sim_time false works but maybe the bad approach

Reuben John gravatar image Reuben John  ( 2016-02-03 07:31:32 -0500 )edit

Mixing simulation and real hardware drivers can be tricky, as the former uses sim time per default and the latter might expect to not run sim time. Maybe things work better when switching off the time sync for the urg_node (in case it's been true before).

Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2016-02-03 07:53:37 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2016-02-02 09:28:01 -0500

Seen: 696 times

Last updated: Feb 02 '16