 Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags. |
The Turtlebot App Manager
Description: Getting to know the new app manager - pairing and concert modes.Keywords: turtlebot
Tutorial Level: INTERMEDIATE
Next Tutorial: Turtlebot-Android Pairing
Contents
Overview
Hydro depracates the old app manager in favour of the rocon_app_platform with the goal of enabling a usable public interface for both interaction with your turtlebot. This interface is still under heavy development, but will eventually enable the following features on turtlebot:
1-1 Pairing : hook up with your turtlebot via an android phone/tablet.
Concert Mode : a compatible multi-robot mode that allows use of the robot as a retaskable agent.
Capabilities to provide a portable, easy to use dependency layer underneath the robot applications.
Right now, the hydro release supports pairing mode which lets you hook up your android tablet in almost exactly the same fashion as you've been used to doing with your tablet. The others will slot in when they are ready/stable or await a future release.
Differences between this and the old app manager interface:
- Can run standalone, but pairing/concert modes make use of two masters - private and public
The new android application is now called the Robot Remocon and has undergone several bugfix improvements.
App Manager Bringup
Launchers
# Launch standalone (not usable for pairing/concert modes) > roslaunch turtlebot_bringup minimal_with_appmanager.launch # Launch with dual masters > rocon_launch turtlebot_bringup bringup.concert
Note: rocon_launch is a multi-roslauncher.
Ports
Standalone and public masters start on port 11311. The private master starts on 11312. You may wish to keep this in mind when ssh'ing to the robot.
Private and Public Master
The original turtlebot software runs with just one master. Actually, it had the intention of this dual master in the design, and old turtlebot code actually fires up two masters - it just never got to the stage where it could use the public master.
Why Two Masters?
- Firewalls the private master from external connections - e.g. don't give everyone access to /cmd_vel or /self_destruct. Users can only access what's in the public master and the robot controls what goes into the public master.
- The public master is a nice, non-confusing sandbox for users - the robot developer can decide what their app will throw into this sandbox and users of the robot can more effectively introspect without being swamped by the private connections.
Managing Apps
# Starting an app > rosservice call /turtlebot/start_app turtlebot_core_apps/chirp [] # Stopping any app > rosservice call /turtlebot/stop_app
If you are rocon_launch'ing the app manager across private and public masters, you will also see alot of extra action going on - robot app connections get flipped across from the private to the public master. You can find out more about what is going on in the documentation for rocon_multimaster.
There are a few other topics and services provided by your app manager, feel free to explore!
Visualization Launchers
The app manager namespaces started applications so that conflicts won't arise later when running with multiple robots. This means that visualisation launchers are different for old style launchers (e.g. turtlebot_navigation launcher vs android make_a_map or navigation apps. Where there is launchers available, we have added the _app suffix to them, e.g.:
# For non-app managed launchers > roslaunch turtlebot_rviz_launchers view_navigation.launch # For app managed launchers > roslaunch turtlebot_rviz_launchers view_navigation_app.launch
