Move_base posting incorrect goal_ID timestamp
I'm attempting to create a program that can send a series of waypoints to a turtlebot3 performing 2D slam with AMCL and using move_base as the controller. Doing all this as a simulation.
I'm trying to get this all running in gazebo. I have followed the turtlebot3 navigation and simulation tutorials, I can get gazebo running, see the robot, launch Rviz, reset the pose, and even send a command via the Rviz 2N nav goal GUI, and it all works.
First I run:
roslaunch turtlebot3_gazebo turtlebot3_world.launch
Then:
roslaunch turtlebot3_navigation turtlebot3_navigation.launch map_file:=$HOME/map.yaml
However, when I go to give it a second goal (either from terminal, or the rviz GUI), nothing happens. No new global or local plan is generated, it just sits there.
Ive tried running rostopic echo move_base/status:
for the first goal, everything works fine and when it reaches goal I get this:
header:
seq: 1104
stamp:
secs: 285
nsecs: 411000000
frame_id: ''
status_list:
-
goal_id:
stamp:
secs: 2690710792
nsecs: 32577
id: "/move_base-1-2690710792.32577"
status: 3
text: "Goal reached."
When I set a new 2nd goal, it seems to be immediately rejected because another goal?
header:
seq: 1308
stamp:
secs: 326
nsecs: 8000000
frame_id: ''
status_list:
goal_id:
stamp:
secs: 2690710792
nsecs: 32577
id: "/move_base-1-2690710792.32577"
status: 3
text: "Goal reached."
goal_id:
stamp:
secs: 321
nsecs: 25000000
id: "/move_base-2-321.25000000"
status: 8
text: "This goal was canceled because another goal was recieved by the simple action server"
Ive dug through as many of these rostopic lists as I could looking for more clues, but have come up empty handed. Please hlep me shed light on this one!!
A few notes on system: ROS Kinetic running on Ubuntu 16.04, all on a virtual machine running in windows.
------ UPDATE-----
Interesting! I suspected time had something to do with this, but missed that clue.
More clues: I generated these messages from echo move_base/goal. The first is the very first message (successful), the second was rejected.
header:
seq: 0
stamp:
secs: 44
nsecs: 156000000
frame_id: ''
goal_id:
stamp:
secs: 0
nsecs: 0
id: ''
goal:
target_pose:
header:
seq: 0
stamp:
secs: 44
nsecs: 156000000
frame_id: "map"
pose:
position:
x: -0.520000100136
y: -1.67999970913
z: 0.0
orientation:
x: 0.0
y: 0.0
z: 0.010867499424
w: 0.999940946985
---
header:
seq: 1
stamp:
secs: 65
nsecs: 551000000
frame_id: ''
goal_id:
stamp:
secs: 0
nsecs: 0
id: ''
goal:
target_pose:
header:
seq: 1
stamp:
secs: 65
nsecs: 552000000
frame_id: "map"
pose:
position:
x: -0.58999979496
y: 0.510000050068
z: 0.0
orientation:
x: 0.0
y: 0.0
z: 0.702834457478
w: 0.711353446173
This is from move_base/status:
---
header:
seq: 277
stamp:
secs: 65
nsecs: 552000000
frame_id: ''
status_list:
-
goal_id:
stamp:
secs: 4294967295
nsecs: 0
id: "/move_base-1-4294967295.0"
status: 3
text: "Goal reached."
-
goal_id:
stamp:
secs: 1397513456
nsecs: 32765
id: "/move_base-2-1397513456.32765"
status: 8
text: "This goal was canceled because another goal was recieved by the simple action server"
From this it looks indeed like the goal ID handoff is getting botched ...
nitpick, but: the timestamp is not "garbage". It's unexpected, but it's a valid timestamp (it just happens to be in the future).
RViz is being used by many people, and has been for a long time, also in navigation contexts, so my first guess would be that something is either not right with the clock it's using/gets on your machine, or there is some weirdness going on with
use_sim_time
.Good point, I take back my garbage comment. Was late and I was frustrated...
Any tips on how I can troubleshoot those clock issues? How can I tell where move_base is pulling that data?