Real Robots: Player Project

The Player Project, or simply Player, is a free software project (GNU General Public License) designed to provide a robot server framework. It is designed to run on real robots in addition to the Stage and Gazebo simulation systems. We’ll take a look at these environments, including running Player on the Whitebox Robotics PC-Bot (Fig. 1). Player is available on a wide range of platforms and is used throughout the world. It was an international group of robotics researchers that developed the platform and continues to make improvements to it. It is funded in part by NSF grants and the SRI AI Center. Player runs on Linux, Solaris, BSD and Mac OSX. Some users have worked with Player using Cygwin, a Linux environment running under Windows. The official language interfaces include C, C++ and Python, while third parties support Java, Ada, Ruby, Octave, and others. Player defines the robot device interface. It operates at the network level allowing robot remote control over a sockets interface, and is designed to work with a variety of robot and sensor hardware. Player uses a client/server model so each side can be written in any programming language. The system supports multiple, concurrent client connections. Stage is a multiple robot 2D simulator. It supports 2D sensing with various sensor models including sonar, scanning laser rangefinder, and pan-tilt-zoom cameras with color blob detection. Gazebo is a 3D multiple robot simulator. It can simulate rugged, outdoor environments as well as realistic sensor feedback and physically plausible interactions between objects. This includes an accurate simulation of rigid-body physics. Both Stage and Gazebo support simulated robots that utilize the Player framework. A number of higher-level frameworks and interfaces have been built on top of Player. These tend to be open source research projects as well. For example, the University of Auckland Robotics Group has an Eclipse plug-in. There is a Gazebo interface to Matlab. There is also an artificial evolution and a multi-agent framework called SFERES that works with. Links to these and other frameworks can be found on the Player site. The Player The original Player platform was created for the ActivMedia Pioneer 2 robots family but has since grown and addresses a range of mobile robotic platforms. It requires a POSIX threads (pthreads) environment, a TCP stack, and C/C++. Configuration scripts require bash (such as found on Linux). Player is a low-level interface. It provides a standard interface but makes no assumptions about the robot control program. It supports multiple devices over a single link and can support any number of clients. Application programs are linked to Player client libraries that provide a connection to a Player server. The Player server normally resides on the target robot and is linked to Player device drivers. The device drivers map to logical, abstract drivers that a client normally sees. The advantage of this approach is that is effectively the same as any client/server architecture making it easy to understand and test. There are sufficient simulated devices and robots for use with Stage and Gazebo so a user can easily experiment with Player. Writing device drivers for a new robot and its peripherals is relatively straightforward. As with many OS device drivers, a single driver can handle any number of physical devices. For example, a standard driver is available for the SICK LMS200 laser range finder that matches the abstract "laser" interface. An actual connection might be specified as localhost:6665:laser:0 for port 6665, logical laser interface device 0. I’ll be taking a look at a laser range system for the PC-Bot and Player in a subsequent article. In addition to the Player server and interface standards, the Player Project includes a number of modules. For example, Playerv is a general-purpose sensor visualization and device control GUI. Playernav is a multi-robot localization, navigation, and path-planning GUI. Other modules address issues such as mapping and GPS correction. Taking The Stage The Stage plug-in provides a 2D simulation environment (Fig. 2). While not necessarily as splashy as the 3D Gazebo it is actually quite a useful environment for experimentation because it is simpler. It has visual tracking capabilities that can be handy when viewing the simulation. The implementation is relatively simplistic but very useful. The initial environment is setup via a text-based World file with details such as: position
(
name "robot1" port 6665 pose \[1 1 0\]
player ()
laser ()
) The entity definition describes the properties of the entity. This includes the interfaces that will be supported. Control is in the client that you supply or you can use one of the standard Player user interfaces. Robots can also be free running as well. The Stage interface is relatively simple. You can pan, zoom and examine entities. It is possible to view almost all data related to the system. Wandering Around The Gazebo Gazebo is 3D simulation environment (Fig. 3) like Stage. In fact, it uses the same kind of World configuration file. That’s handy for moving between the two environments. Gazebo requires two third-party packages: the SWIG (Simplified Wrapper and Interface Generator) and wxPython (a cross platform GUI library). The user interface is somewhat primitive but it can capture movies and there is some camera control. Interaction with entities is the same as with Stage, via a remote client. Gazebo is no more difficult to use than stage although it is definitely more function visually. Player on the PC-Bot Installing the Player software on the PC-Bot is relatively easy. Ubuntu is the Linux operating of choice for the PC-Bot and this matches Player nicely. Still, Player 2.0.3 does not contain the latest WBR914 driver so it must be patched. The Whitebox Robotics installation guide walks you through this. I actually had more problems getting the WiFi to work than Player. Of course, patching means you need to rebuild from source code but that is not really hard and it is explained in the manual as well. It only needs to be done once and the whole process took less time than with Microsoft Robotics Studio. The configuration file (below) is relatively simple but it shows the various interfaces for the PC-Bot. driver
(
name "wbr914"
provides \[ "position2d:0""ir:0""aio:0""dio:0"\]
port "/dev/ttyUSB0"
) It is just a matter of starting up the Player server and then Playerv to control the system. Player runs on the PC-Bot but Playerv uses port 6665 and can be on a networked PC. It is then a matter of selecting the interfaces that will be controlled just as when using Stage or Gazebo. That’s it. I drove the PC-Bot around. A joystick helps but the keyboard works well too. I won’t go into my minimal programming experimentation but it is safe to say I spent more time programming than trying to figure out the architecture compared to the Microsoft Robotics Studio. This is because the Player framework is very simple. The client side consists of a collection of about 20 C++ class definitions that essentially match all the standard interfaces provided by Player. This includes things like LaserProxy, GripperProxy and SpeechProxy. Movement is done using the PositionProxy that has methods such as SetSpeed and SetMotorSpeed. The Player Project provides the basics needed for multiple robot control and simulation. It is easy to incorporate new devices and, hence, new robots, but this is because the system just deals with the basics. It is definitely not as ambitious as Microsoft Robotics Studio although the two are comparable. Microsoft Robotics Studio has a much more sophisticated underpinning though and the might of Microsoft behind it. Still, there is much to be said for open source and simplicity. The Player Project may be just what you need for robotic control. Related Links Player Project SFERES SRI AI Center University of Auckland Robotics Group Whitebox Robotics