move_base acting weird with nodes running on different hosts.

edit

Hello All,

Using examples from "ROS by example" to get move_base working, the trajectory is erratic when the code, apart from rviz, is running on ANOTHER host. It gets there in the end, but is moves very strange, as if it is very "drunk"...

The commands I use are:

  roscore
  roslaunch rbx1_bringup fake_turtlebot.launch
  roslaunch rbx1_nav fake_move_base_blank_map.launch
  rosrun rviz rviz -d `rospack find rbx1_nav`/nav.rviz

When all commands are run on my regular PC (PC, i5, ubuntu 14.04, indigo), all is well. But when the 2 roslaunch commands are running on another host the strange paths occur.

That other host is a quad core i.MX 6Quad from Freescale, 1GHZ, 1GB, running ubuntu 14.04 with indigo. There is no swapping, and nothing else is running there.

Communication is via a 5GHz Wifi link that can sustain 15MB/sec.

I would assume that for this simple setup the performance of the arm-system and wifi-link is not the problem. What could be the cause of this, and how can I proceed in nailing this down further?

EDIT:

roswtf gives the SAME output in both situations. It does give the following error:

ERROR The following nodes should be connected but aren't:
 * /move_base->/move_base (/move_base/global_costmap/footprint)
 * /move_base->/move_base (/move_base/local_costmap/footprint)

but that probably is not relevant now.

move_base often does not start properly, the initialization normally ends with "odom received!", but sometimes it takes a long time (20 seconds) for that last line to appear. It also sometimes does not come at all. I already asked about that in my question "remote core with move group". When I stop the hung program it complains about: Failed to contact master. But it uses it all the time....

When I use the move_base parameters that come with this example, I get the following warnings when the controller and move_base are running on the arm-board.

[ WARN] [1455012218.435531811]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 1.0281 seconds
[ WARN] [1455012218.953750145]: Control loop missed its desired rate of 3.0000Hz... the loop actually took 0.5194 seconds

I find it strange that calculation one loop takes that much time, given that both global and local maps are empty. Am i missing something?

If I lower the rate to 1 Hz it basically works, but it has hard time following the track, and most of the time it looks like an highly unstable system. After changing some more parameters I can get it better, but only a little bit: not usable.

If move_base now only gives a single /cmd_vel per second, I can imaging that it is difficult to keep it on track. Wouldn't it be better if move base gave a complete trajectory to the final goal, and update that each second? Then the rates of move_base and execution the trajectory could be decoupled.

In summary, two questions. Why does the "odom received!" sometimes not come or after a long delay? And ... (more)