Clearpath is always playing with new ways to control our robots. Recently, I bought a Galaxy S3, in part because of the ROS Teleop example application available on the Android Market.
This app was originally put together very quickly by Willow Garage to control the TurtleBot v1.0 and PR2, and it has a few issues, but it’s quite functional for controlling other robots. It’s based on the concept of robots advertising specific “apps” that their hardware supports, and users selecting apps to run via remote interface software such as the Application Chooser.
Unfortunately, full documentation for how you add “app” support to a new robot is still lacking on the ROS wiki, and we have robots that need driving. It’s also personally of interest to me to be able to drive everyone’s robot from my phone, not just the ones Clearpath builds. Most people would use a smaller robot for this kind of example. I won’t.
There are three important parts of this: the App Manager nodes, the App List, and the set of installed apps. The App Manager nodes do the actual work – they determine what apps are available on the robot, launch supporting code as required, and bridge the topics between the ROS core running on the robot and the Android devices. The App List is a basic text file which provides the App Manager system with a list of apps and their corresponding ROS packages. Finally, each installed app has a dedicated package which contains at a minimum three specific files (a .launch, a .interface, and a .app file). The purpose of each of these files is described in more detail here.
First, we’ll start with the common requirements: the App Manager and the App List. I’ll use the Husky code as a starting point. Honestly, most of this is a find-and-replace operation to get basic functionality going. First, you need a launchfile which can take care of starting the App Manager nodes. Since this is the sort of launchfile which can be started with the robot whenever it’s turned on, we put it in the husky_bringup directory. All I needed to do is move it to the corresponding directory for the new robot and change the names. In the file itself, notice the argument after the “–applist” flag. This is the location of the App List. It too can go in the *_bringup directory.
Since the robot I’m using is called the Grizzly, we’ll have the following files.
For grizzly_bringup/launch/app_manager.launch:
Here, replace GRIZZLY_IP with whatever the value of ROS_MASTER_URI is. This could be static, or it could be passed into the launchfile via environment variables. It’s very important that your phone is able to reach this IP address. The best way to check this out for most networks is to join the same Wi-Fi network as your robot, find the IP of your phone, and ping it from the robot. If you get a reply, you’re probably OK.
Next, we have the App List, in grizzly_bringup/apps/grizzly_apps.installed. We’ll only create one app.
apps: - display: Android Teleop app: grizzly_android_teleop/android_teleop
This declares that a app exists in the grizzly_android_teleop package, and the relevant files will start with android_teleop. Your environment should be set up so you can roscd to grizzly_android_teleop.
Now, for the app-specific files. Create a standard blank ROS package (with manifest.xml, CMakeLists, etc) called grizzly_android_teleop with an app/ directory inside.
app/android_teleop.interface can be left blank:
published_topics: {}
subscribed_topics: {}
app/android_teleop.launch is only slightly more complex. This file provides special topics whenever an Android device connects. For example, the below subscribes to a stereo camera feed and provides a throttled version to reduce the bandwidth requirements between the robot and the phone.
Finally, the meat of the configuration is in the app/android_teleop.app file:
display: Android Teleop description: Drive a Grizzly from Android with a touch joystick and video feed. platform: grizzly launch: grizzly_android_teleop/android_teleop.launch interface: grizzly_android_teleop/android_teleop.interface icon: grizzly_android_teleop/android-lightning-turtlebot.png clients: - type: android manager: api-level: 9 intent-action: ros.android.teleop.Teleop app: gravityMode: 0 base_control_topic: /cmd_vel camera_topic: /camera/left/image_raw/compressed_throttle
Make sure the “launch” and “interface” filenames and packages match. Note that they’re formatted as <package>/<filename> , not as the full path. Most importantly, the topics defined at the bottom need to match those published by ROS (either natively or by android_teleop.launch.)
That’s all! Run roslaunch grizzly_bringup app_manager.launch. Now, launch the Application Chooser on your phone and add a new robot. The only mandatory field is the master URI: http://GRIZZLY_IP:11311/, with GRIZZLY_IP being the same value as what the App Manager nodes were launched with. If you put in the SSID and password information for your robot’s network, it will automatically join it when the robot is selected in the Application Chooser.
You’ll see messages appear on your terminal to indicate a successful connection, and you’ll now be able to launch the teleop app.
There will likely be some hiccups with this app, but it’s under active development and we like the concept. Likewise, if you’re running robots likeGrizzly, please keep safety in mind. It’s not every day that app development needs an emergency stop on hand.
