roomba pac-man: teaching autonomous robotics through ... roomba pac-man: teaching autonomous...

Roomba Pac-Man: Teaching Autonomous Robotics through ... Roomba Pac-Man: Teaching Autonomous Robotics
Roomba Pac-Man: Teaching Autonomous Robotics through ... Roomba Pac-Man: Teaching Autonomous Robotics
Roomba Pac-Man: Teaching Autonomous Robotics through ... Roomba Pac-Man: Teaching Autonomous Robotics
Roomba Pac-Man: Teaching Autonomous Robotics through ... Roomba Pac-Man: Teaching Autonomous Robotics
Roomba Pac-Man: Teaching Autonomous Robotics through ... Roomba Pac-Man: Teaching Autonomous Robotics
Download Roomba Pac-Man: Teaching Autonomous Robotics through ... Roomba Pac-Man: Teaching Autonomous Robotics

Post on 29-Nov-2018




0 download

Embed Size (px)


  • Roomba Pac-Man: Teaching Autonomous Robotics through Embodied GamingBrendan Dickenson Odest Chadwicke Jenkins Mark Moseley

    David Bloom Daniel HartmannDepartment of Computer Science

    Brown University115 Waterman St.

    Providence, RI, 02912-1910{bcd | cjenkins | mmoseley | dbloom | dhartman }


    We present an approach to teaching autonomousrobotics to upper-level undergraduates through themedium of embodied games. As part of a develop-ing course at Brown University, we have created theRoomba Pac-Man task to introduce students to differ-ent approaches to autonomous robot control in the con-text of a specific task. Roomba Pac-Man has been de-veloped using commodity hardware from which stu-dents explore standard methods in robotics, namely sub-sumption, localization, and path planning. Our devel-opment of Roomba Pac-Man is founded upon ground-ing robotics in an compelling and accessible applicationin a noncontrived real-world environment in a mannerthan can be reproduced, giving students a sense of own-ership.

    IntroductionAs the field of robotics advances, robotics education mustadapt to incorporate both technical developments that be-come core topics and compelling new challenges of societal-level interest. Undergraduate autonomous robotics curriculahave been adept at exposing students to relatively moderntopics, such as behavior-based control and Monte Carlo Lo-calization. However, the impact of such coursework canbe difficult to conceptually translate beyond the academicsetting. Tangible artifacts produced in robotics courses areoften overly structured (e.g., simulations, toy-level robots),difficult to reproduce (e.g, expensive equipment), or are dis-tant from deployment in society. Our approach is to exploredifferent approaches to autonomous control with focus ona specific task that is compelling, reproduceable with inex-pensive off-the-shelf hardware, and deployable in many en-vironments.

    To this end, we have developed the Roomba Pac-Man task(RPM) as a central theme in Brown course CS148 (Build-ing Intelligent Robots) for exploring topics in reactive anddeliberative robot control. Working from the appeal of videogames, RPM is an embodied version of classic 1980s arcadegame Pac-Man, where the player-controlled agent must nav-igate a maze to consume dots while avoiding ghosts. In

    Copyright c 2006, American Association for Artificial Intelli-gence ( All rights reserved.

    RPM, a virtual Pac-Man is replaced with a physically em-bodied iRobot Roomba vacuum equipped with a webcamand onboard computing. Students perform three introduc-tory projects that cover subsumption (Arkin 1998), localiza-tion (Thrun, Burgard, & Fox 2005), and path planning in thecontext of RPM, allowing for normalized comparison andappreciation for the relative strengths of both approaches.RPM leverages Roombas as a cost-effective and deployablesolution for teaching Robotics on real robots. Followingthe desire for reproduceability, students use the Player robotserver and Gazebo simulation platform (collectively referredto as PSG) to develop control clients. RPM is placed in typ-ical human environments containing fiducialized versions offood pellets, ghosts, and power ups. Students con-trol clients score points by vacuuming pellets and visitingpower-ups within a fixed amount of time.

    Roombas are used as the platform for the course becausethey offer the student a chance to interact with a robot thatis actually used in the world. The Roombas provide aplatform that is easy to interact with (no proprietary soft-ware/hardware). Via the PSG open-source project a widevariety tools may be used to acquire sensory information,and if something is not currently supported it can be reason-ably added. This allows the student to attach virtually anyreal world sensor to the Roomba. In short, the Roombas arereal robots, used in the real world, not some striped downeducational robot, and certainly not a toy.

    In the following sections we present our ongoing work de-veloping robotics curriculum around Roomba Pac-Man. Wedescribe our extensions to PSG to support RPM and the pro-gression of lab exercises and projects throughout the course.

    Course StructureThe structure of Brown CS148 consists of 3 introductorylabs and 3 control projects to reinforce material presentedin lecture. Labs are simple projects that are designed togive students an introduction to using PSG and the Roombahardware. The labs progress through basic reactive ob-stacle avoidance, blobfinding, object/fiducial seeking , andcolor calibration with physically simulated robot. These labsare designed to be straightforward exercises (implementablewithin a given lab period) that give the students a chance tofamiliarize themselves with robotics. These labs build onone another to yield a robot client that is the foundation for

  • the first project of RPM.The course projects are designed to explore reactive and

    deliberative approaches to robot control in the context ofRPM. The first project, implementing a reactive subsump-tion controller, integrates all the topics covered previouslyin the labs. The final two projects focus on localization andits use for deliberative path planning. For the second project,students implement Monte-Carlo Localization (MCL) for asimulated Pioneer 2AT in PSG. The third project involveswriting a path planner to play RPM in the real world, us-ing the estimates from their MCL system from the sec-ond project. For final projects, undergrads develop robotclients of their own design to compete in a final competition.Students are encouraged to either strengthen their existingcode or blend their creativity with concepts from the course,such as learning policies from demonstration or performingSLAM.

    Our approach offers a logical transition through the ma-terial. Starting with three straightforward lab assignments(two of which are in simulation) allows the students to gaina mastery of the platforms as well as a basic understand-ing of fundamentals of robotics (odometry for instance), be-fore dealing with more complex ideas or issues with realworld implementations. The third lab provides a transitionfrom simulation to real world implementation. The secondproject gives the students the chance to successfully imple-ment MCL in simulation where debugging and lighting con-ditions are much easier before being forced to make it workin the real world.

    RPM PlatformWe aimed for RPM to be cheap, reproduceable, and us-able in normal environments. For this purpose, the iRobotRoomba was a logical choice, being a cost effective solu-tion with brand familiarity. Because of its popularity insociety, students immediately see it not as a toy, but a de-vice with real-world applicability. Each Roomba costs $150.We use standard Dell Dimension laptops which cost $500each to control an individual Roomba. The Roombas areconnected to the laptops via a Robo-Dynamics Roo-Stick,which can be purchased for $25 each. PSG has basic sup-port for the Roomba Serial Command Interface, which wehave extended to incorporate more of the Roombas features(e.g., IR, vacuum, etc.). Finally, we mounted Logitech Com-municate STX webcams on the Roombas, costing about $30dollars each. Thus, for under $700 a robot, we have a veryfunctional, real world robot with the ability to manipulateobjects (i.e., vacuum). An early version of RPM is shown inFigure 1.

    While cheap, our infrastructure is far from optimal due totheir size and weight of the laptop and the sketchy nature ofwebcams. Other efforts have explored better options suchas Gumstix embedded boards and MacMinis. The primarystrength of these approach follows from the philosophy ofPSG itself in that it is portable and flexible to the specificof the robot hardware. If one needs better computation, onecan buy a more powerful computer. If better or differentsensors are needed, attach a suitable device and use or writethe Player interface.

    Figure 1: An early version of Roomba Pac-Man.

    PSG and its ModificationsMuch of our framework relies on the PSG platform (Gerkeyet al. 2001). Player is a network server for robot control.Player runs onboard a single robot and provides a clean in-terface to the robots sensors and actuators over an IP net-work. Gazebo is a 3D physics-based robot simulator suit-able for smaller numbers of robots simulated at high fidelity.The physics for Gazebo is provided by the Open DynamicsEngine (ODE), which integrates physical dynamics for arbi-trary kinematic structures through optimization.

    PSG provides an infrastructure for developing robot con-trollers. Students write controllers as client programs thatsend control commands to and request information from arobot through its Player server. Stage and Gazebo can sim-ulate various types of robot platforms (i.e., hardware) andpopulations. The same interface, provided by the Playerrobot server, is used to control a robot in the real world or itsequivalent in a Stage/Gazebo simulation. Robot platformsthat are not currently supported in PSG can be developedthrough implementing appropriate Player server interfacesand devices in Stage or Gazebo.

    Devices (e.g., a laser, a camera, or a complete robot) areactual hardware in the real world or simulated hardwarethat exists in a virtual environment maintained by Stage orGazebo. A robot server (e.g., Player) is the information in-terface between the robot and any program that requests in-formation from or sends commands to the robot. Regardlessof whether a device is real or simulated, the robot serverprovides the same interface to the robot for client programs.Thus, controllers developed on a simulated device will im-mediately run the equivalent real robot device given PSG

  • Figure 2: Simulated world in Gazebo for Labs 1 and 2

    support for the device.

    Another advantage of Player as a robot s


View more >