Refactor Turtlebot Follower.

[kevincwells]

Pulled centroid-generation and publication out into a separate nodelet, leaving
Follower just responsible for listening for and responding to goal points.

In this version, the Follower nodelet subscribes to a /turtlebot_follower/goal
topic, and uses the geometry_msgs/Point message as the x, y, and z goal point
it should follow.

A separate Centroid nodelet contains the original centroid calculation logic,
and publishes its results to a topic that can be mapped to Follower's goal.
The already-existing change_state service is used to stop the robot when
the goal is out of range.

The purpose of this refactor is to allow any number of feature/object
detection-and-tracking packages to be used to generate the Follower goal, not
just the simplistic centroid calculation logic in the base implementation. A
more sophisticated person-tracking library, for example, could tell the
Turtlebot to follow only a specific person.

To see an example of an alternative person-tracking configuration like the one
mentioned above, see this fork.
Please note that the above-linked package relies on an internal, still-in-development
realsense_person package to be built and run, but you can still easily look at
the supplied launch file to see how the refactored turtlebot_follower package is
being included with the "generate_goal" parameter turned off, and instead the
realsense_person_turtlebot_follower package is used to generate the goal messages.

[kevincwells]

@tfoote -- just checking to see if anyone has taken a look at this. For reference, the Kinetic build is failing due to the same CMake warnings that make all the other current PR's fail.

FYI - the above-linked "Realsense Person Turtlebot Follower" fork has been updated using the forthcoming Realsense Person body-tracking library to stop sending Follower goal messages if the user holds their hand in the air. As this code still relies on on as-of-yet-unreleased Intel libraries to build and run, you cannot directly test it out yourself. That said, I bring it to your attention to further illustrate how this refactored Turtlebot Follower design allows outside packages to build upon and improve the simple Turtlebot Follower demo and use case, while highlighting the features they provide. The default Turtlebot Follower demo requires the user to very quickly remove themselves from the Turtlebot's field of view in order to end the demo. In our version, the user can simply hold their hand up and easily walk out of the frame.

[tfoote]

The nodelet manager name popped out at me. But overall it looks good.

This added abstraction makes some sense. I'm not sure about how best to abstract the goal. It would kind of make sense to embed some of the behaviors related to the goal into the message instead of them being parameters on the node. For example if you switch from the person follower to the centroid approach the standoff distance needs to be different. Unless your person follower can see hand gestures at knee level.

It might make sense to make a dedicated CarrotGoal message instead of just using the point and having parameters on the node that processes them.

[tfoote]

I don't think that this should have a leading slash on the value. That makes it not play well with namespaces.

[tfoote]

Also thinking about it we probably actually want to keep the nodelet manager name the same and run the nodelets together. Even if it's a low bandwidth connection running in the same process will help.

[kevincwells]

Hi @tfoote -- good catch on the leading slash on the manager name.

The reason I created an independent manager to run the follower nodelet itself, rather than running it in the camera_nodelet_manager like it was previously, is because when you abstract away the goal generation, you can no longer guarantee that the camera_nodelet_manager will still exist.

The centroid-based goal generation implemented here launches the camera in the standard way, and runs in the same nodelet manager as that camera to efficiently avoid copying the camera data stream. However, the RealSense Person goal generation nodelet linked above relies on the RealSense Person package, which is not turtlebot-specific, cannot launch the camera in the standard way (it needs to configure additional dimension and framerate options that are not passed through the standard turtlebot_bringup camera launcher), and does not call its nodelet manager camera_nodelet_manager.

Further, since any nodelet could be used to generate the goals, a totally different sensor mechanism that does not rely on cameras at all (e.g., lidar) could be used to tell the robot where to follow.

[kevincwells]

The dedicated CarrotGoal message idea is interesting. You're right that the RealSense Person goal generation nodelet does require the robot to be further away than the default value to keep the person in frame; I currently handle this by setting the goal_z parameter in the launch file when I include the turtlebot_follower launch file.