segbot_bringup: add stop controller node

[jack-oquin]

Design sketch:

• Subscribes to cmd_vel topic.
• Republishes on safe_cmd_vel, to which segway_rmp driver will subscribe.
• Accepts state transition requests from multiple, self-named sources, probably via a ROS service call.

Maintains a state machine with at least these states:

• Running: passes cmd_vel through to safe_cmd_vel.
• Paused: passes zeroes to ``safe_cmd_vel.
• Stopped: terminal state, otherwise behaves like Paused.

This is similar to the E-Stop controller we had on the driverless car, except that all requesters must select the Running state before that transition occurs. I think we should provide multiple methods of pausing or shutting down robot motion, including smart phones and maybe a game controller. The arm controller can use the Paused state to prevent motion when the arm is in an unsafe position.

It seems like a good idea to ramp down the velocity when changing to Paused or Stop state for a controlled stop (unless the segway_rmp driver handles that adequately).

Initial implementation in Python, can be converted to C++ if performance becomes a problem. I plan to do this soon.

Comments?: @piyushk, @jsinapov, @shiqizhang6, @maxsvetlik, @mleonetti

[jack-oquin]

I am thinking of moving this new node to bwi_common, as a separate package. The message and service declarations need to go in bwi_msgs, anyway, and it is not particularly segbot-specific.

[jack-oquin]

With this design, it is possible for a requester to set PAUSED status and then crash, leaving the robot unable to move. The failing node could be respawned by roslaunch and clear the stoppage, itself.

We could also provide a RESET command that clears all PAUSED or STOPPED requests, regardless of requester.

[maxsvetlik]

Does this mean that raw velocity commands will now be collision minded? The idea being that the 'running' state is dependent on various safety checks (eg not in obstacle, arm in footprint) as well as movement being invoked?

[jack-oquin]

Max: It could be done that way, but I don't think it advisable. The move_base navigation stack already handles obstacles adequately, and there can be problems when multiple collision avoidance algorithms operate independently.

The immediate requesters of this service that I anticipate are:

• the arm safety controller
• user-requested pause or stop

[maxsvetlik]

@jack-oquin I've written a preliminary navigation safety manager for the arm. It's currently written as a service than can be called to put the arm into a safe (inside the robot's footprint) configuration. I assume (correct me if I'm wrong) that this should interface with your node by simply publishing whether or not the arm is in a navigation-safe state.

[jack-oquin]

No, the stop_base_controller node provides a /stop_base service call.

When the arm is not in a safe position, set the bwi_msgs/StopBaseStatus component to PAUSED. When the robot is safe to move, set it to RUNNING. Use your own node name for the requester field.

That code was still in the separate branch where I developed it, but I just merged it into master. In a few days the API documents will automatically be added to the ROS documentation.

[jack-oquin]

Note that the new code is actually in the bwi_common repository.

I intend to use this issue to update the segbot launch scripts, so that node runs automatically and handles the cmd_vel topic (instead of the segway base).

[jack-oquin]

ROS interfaces for the stop_base_controller node are documented in the README.rst. The message links should resolve once the ROS build farm picks up the recent merge.

[jack-oquin]

This change has been merged into the master robot launch files.