Playing with the Player Project
Now that we have dealt with the vocabulary, we can get down to business. Let's say you've just acquired a CoroWare CoroBot robot (Figure 2). You've installed Player, and you want to make the robot do something interesting. You can type player corobot.cfg to run the Player drivers on the robot. This loads a configuration file that describes all the drivers Player must load to make your robot work. Here's an excerpt of a configuration file for the CoroBot:
driver ( name "corobot" plugin "libcorobotdriver" provides ["position2d:0" "power:0" "ir:0" "limb:0" "gripper:0" "ptz:0"] requires ["aio:0"] ssc32port "/dev/ttyS1" ptzport "/dev/video0" )
We start off by telling Player that we are constructing a driver. The first two lines in the driver description tell Player where it can find the relevant code: the name line indicates the name of the driver in the code (a single library can supply multiple drivers), and the plugin line indicates the name of the shared object library that contains the code for this driver. In this case, it is stored in libcorobotdriver.so, in the same directory as the configuration file. The provides line specifies the devices that this driver makes available—in this case, the CoroBot driver exposes six devices. The requires line specifies the devices that this driver will consume. If any devices here are not present on the system when Player tries to instantiate the driver, Player will abort.
The last two lines in the driver description are not standard. Any driver is free to parse its driver description and make use of special identifiers. The CoroBot driver uses two of these: ssc32port specifies the Linux device (a serial port) through which it will communicate with its servo controller and a video device that controls its pan-tilt camera.
Player provides a number of tools to make working with Player easier. For example, you can use the playercam program to view the image provided by a Webcam. Let's say you have Player installed on your computer and a simple configuration file that brings up a camera driver:
driver ( name "camerauvc" provides ["camera:0"] port "/dev/video0" size [640 480] )
You can run Player with this configuration file with player camera.cfg, and then run playercam to see the camera image in real time (Figure 3). If your Webcam is on another computer—for example, on a PC-based robot—and connected by a network, you can just as easily see the Webcam output by running:
playercam -h hostname -p port
playerprint is a tool that works much like playercam, displaying the output of a device to the user. But, playerprint does this textually and can support a large number of interfaces, while playercam can support only the camera and blob-finder interfaces. For example, if we have a CoroBot running its Player drivers, we can display its infrared sensor readings with:
playerprint ir -h hostname -p port
Listing 1. Player's playerprint Tool Inspecting a GPS Device
#GPS (13:0) #lat|long|alt|utm_e| utm_n|err_horz|err_vert|num_sats|quality 47.6470103 -122.1414822 112.3 564477 5277425.1 0 0 6 1 #GPS (13:0) #lat|long|alt|utm_e| utm_n|err_horz|err_vert|num_sats|quality 47.6470107 -122.1414812 112.28 564477.07 5277425.14 0 0 6 1 #GPS (13:0) #lat|long|alt|utm_e| utm_n|err_horz|err_vert|num_sats|quality 47.6470113 -122.1414807 112.28 564477.11 5277425.21 0 0 6 1
Player also lets you control your robot, not just inspect it. playerv is a utility that also knows how to interact with many interfaces. Once you have started the Player server on your robot, you can run it with playerv (if you are on the same machine) or playerv -h hostname -p port (if you are on another computer). playerv will show a graphical display of the world around your robot, but it does not automatically connect with any devices. You will have to go to the Devices menu, and subscribe to the devices that you are interested in playerv plotting. In order to drive your robot around, you'll want to subscribe to the position2d device and select the option to “command” the interface. Then, you will be able to drag a small targeting reticle around the window to drive the robot (Figure 4).
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- A Topic for Discussion - Open Source Feature-Richness?
- Dart: a New Web Programming Experience
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- The Secret Password Is...
1 hour 54 min ago
- Keeping track of IP address
3 hours 45 min ago
- Roll your own dynamic dns
8 hours 58 min ago
- Please correct the URL for Salt Stack's web site
12 hours 9 min ago
- Android is Linux -- why no better inter-operation
14 hours 25 min ago
- Connecting Android device to desktop Linux via USB
14 hours 53 min ago
- Find new cell phone and tablet pc
15 hours 51 min ago
17 hours 20 min ago
- Automatically updating Guest Additions
18 hours 29 min ago
- I like your topic on android
19 hours 15 min ago