Resolve premature controller initialization

[miguelprada]

In my (admittedly limited) tests this resolves #206.

It partially reverts the changes in Zagitta#6, in particular the code that ensures the controllers are updated at a minimum rate of 125Hz.

[miguelprada]

I reverted the original commit in this PR and replaced it with a different solution to the issue. It basically avoids calling ControllerManager::update (and therefore avoids starting controllers) until at least one RTPacket has been received.

Feel free to squash merge if you're happy with the final result.

[v4hn]

one nitpick, otherwise this looks good to me.

[AndyZe]

Works great for me.

[miguelprada]

Ping @gavanderhoorn, @ipa-nhg. Any chance you can review this?

Not sure why the tests are marked yellow here, since they show as passed in Travis CI.

[gavanderhoorn]

I've restarted the build.

Travis can be a bit strange sometimes.

[gavanderhoorn]

@miguelprada: this seems like it should fix running controllers without knowing the current state of the robot, but may I suggest we change it for readability to check state_initialized_ in ROSController::update()?

So something like:

bool ROSController::update()
{
  // don't run controllers if we haven't received robot state yet
  if (!state_initialized_)
    return;

  ...
}

I'm assuming the compiler will in-line the call to ROSController::update() in ROSController::onTimeout() (with #225, if it isn't doing it already), so the unconditional call to ROSController::update() should not really matter.

[gavanderhoorn]

I would suggest using robot_state_received_ as the name for the variable. state_initialized_ is too generic and doesn't convey the fact that the variable really captures whether the driver has received the initial state from the robot.

[miguelprada]

I believe all requests have been fulfilled.

[gavanderhoorn]

Thanks @miguelprada for the fix and for iterating on it with me. 👍