Move_base posting incorrect goal_ID timestamp

edit

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 ... (more)