Different robotics platforms for different teaching needs

Vicente Matellanvmo@gsyc.escet.urjc.es

tel: 916 647 472Universidad Rey Juan Carlos

Jose M. Canasjmplaza@gsyc.escet.urjc.es

tel: 916 647 468Universidad Rey Juan Carlos

Rafaela Gonzalez-Careagarafaela@gsyc.escet.urjc.es

tel: 916 647 400Universidad Rey Juan Carlos

Abstract

When facing the problem of teaching the basis of robotcontrol programming to computer science students,apart from the syllabus of the course, some other re-quirements have to be taken into account. For in-stance, which are the most appropriate robotic plat-forms, and which are the best programming toolsfor teaching it. In this paper we describe the plat-forms and programming environments chosen for dif-ferent senior and graduate robotic courses at Rey JuanCarlos University, focusing on the reasons under ourchoices. We also point out the practical assignmentsdemanded on the courses. Finally, we will present theresults along four years, the feedback from our stu-dents, and the lessons we have learned.

Keywords: Teaching, mobile robots

1 Introduction

We are currently teaching robotic courses at two differ-ent levels, undergraduated and graduated level. Themain goal of this paper is the description of the teach-ing experiences gathered along four years, includingthe choice of robotic platforms and programming en-vironments suited for the courses, and the typical as-signments we demand from our students.

We teach two different robotic courses, both namedRobotica. One to undergraduate senior students atthird year of computer engineer degree, and anotherto graduate students, at first year of PhD. program incomputer science. In both cases, the subjects are in-tegrated into computer-engineering programs, whichmeans that their orientation is more focused on theprogramming issues related to mobile robots, than inthe automation or robot construction problems. Sur-prisingly, after four years of experience, the syllabusof both courses has become very close, however therobotic platforms used are very different.

In the design of both course syllabus we decided tofollow a constructionistic approach [9], where studentsnot only have to learn the basic concepts of robot con-trol, but also to really build and control real robots.We claim that playing with robots is the best way tolearn real robotics, and to realize robotic problems andcapabilities. In addition it keeps alumni motivated, asthe number of student who choose our course shows.

Next sections describe the different platforms used.First, the platforms used by undergraduate studentsare presented, as well as the assignments that studentshave to do. Then, in section 3 the robots used in re-search activities are described. Finally, some conclu-sions are noted and the further improvements we areconsidering are introduced.

2 Undergraduate platforms:Mindstorms and EyeBots

In fact, we have to distinguish two cases among under-graduate students, the first ones are regular studentswho attend the Robotica course; the second one aresenior students who choose to works on their FinalStudies Project, FSP hereafter (Proyecto Fin de Car-rera in Spanish) in our group.

2.1 The Robotica course

The target for the regular course is to provide thevery first introduction to robotics. This includes thepresentation of sensors, actuators, and their differ-ent configurations; some useful processing algorithmsof the raw sensor data, and the basic control tech-niques. Also the principles of the intelligent controlarchitectures proposed are described (reactive, behav-iors based, symbolic, hybrid, etc.). Finally commer-cially available robots and their applications, as wellas the most relevant people in the robotics history areintroduced.

1

Figure 1: Eyebot and LEGO Mindstorms robots used for undergraduated students

The platform chosen for the practical assignments ofthe Robotica course is the LEGO Mindstorms1, thatis displayed in right side of figure 1. The main rea-sons are its flexibility and being a completely end-user product, all in a convenient price. To build arobot using the LEGO kit does not require any sol-dering, and the building blocks are intuitive and wellknown for all the students. The Mindstorms are soldas complete kits, which comprise more than 700 LEGOpieces. Each kit includes two motors, two contact sen-sors, one light sensor, and the processing brick, calledRCX, made up of an Hitachi H8/300 microprocessorwith 32Kbytes of RAM, three output ports to connectmotors, and three input ports where sensors can beattached. A graphic software environment for devel-opers, and the equipment for downloading programsinto the robot are also included in the box.

In the software side, there are different toolsavailable for programming the LEGO Mindstormsrobots [7]. The first one is the child-oriented graphiclanguage provided by the manufacturer with the kit.This is a very intuitive tool based on visual program-ming, but quite limited. The more extended alterna-tives are NQC and BrickOS. NQC [3] stands for “NotQuite C”, and it is a simple language with a C-like syn-tax that can be used to program LEGO’s RCX brick.It is the simplest option to the drag and drop icon pro-gramming tool included with the regular kit. It usesthe native operating system provided by LEGO, andadds built-on-top programming capabilities.

BrickOS is the alternative chosen for our course.BrickOS is the current name of the better knownLegOS, an open-source embedded operating systemdesigned for the Mindstorms brick, mainly designedby Markus Noga [10]. This means that the originaloperating system has to be removed. Compared tothe original LEGO operating system, BrickOS offersvastly superior performance and flexibility. It offers anAPI that supports dynamic loading of programs and

1http://www.legomindstorms.com

modules, full infrared packet networking, preemptivemultitasking, dynamic memory management, driversfor all RCX subsystems, 16 MHz native mode speed,access to the 32k RAM, etc. The development envi-ronment we offer to the students comprises a BrickOSrunning in the Lego robot and a personal computer un-der GNU/Linux. The robot programs are written in Clanguage using any editor, compiled and debugged inthe computer. Actually we use a cross-compiler avail-able for GNU/Linux machines, which fully supports allC capabilities like pointers, data structures etc. Oncethe executable programs are generated they are down-loaded to the Mindstorms, where the BrickOS makesthem run.

The students of the Robotica undergraduate coursewere grouped into couples which received a completeMindstorms kit, and each group received an additionallight sensor, and a rotation sensor in order to allowthem to develop more sophisticated behaviors (to im-plement odometry calculi, for instance). Currently,the robotic teaching lab contains 25 Mindstorms kitswhich allow 50 students in the course. The practicalassignments include building the robots and program-ming them. Actually the mechanical design of therobot has to be decided by the students accordinglyto the behaviors they have to program.

Two different tasks have to be solved by the stu-dents, although they can be seen as a single one, be-cause the first one is just a subset of the second one.In the former the robot has to travel from an startingpoint to a destination goal inside a maze, and comeback again to the initial location. The maze, shownin figure 2, is given in advance, so they can implementsome kind of path-following in the robot program. Inthe second task the robot has to collect two differentcans placed inside the previous maze. The exact loca-tion of one can is given in advance, but the locationof the second one is completely unknown, forcing therobot to search for it and detect it. The idea herewas to motivate students to use general architectures,instead of local solutions.

2 / 7

Figure 2: Practical assignments: maze and can collector

For instance, the ones who tried to pre-compile thetrajectory in the maze for the known can, were in gen-eral less efficient searching the second one. Addition-ally, the cans can be white or black ones at random.In the case of black ones, the robot has to carry themto a destination location A. For white ones, it has tomove them to another location B. So the robot hasto distinguish between black and white cans, carryingeach type to a different point in the maze. The guid-ing idea for these assingments was to make studentsface the sensor noise problems, and make them use theconcepts presented in the theory classes like reactivelocal navigation, map building and use, etc.

The textbook that we currently recommend in the-ory part of the course is the Ronald C. Arkin one [2].For practical assignments the construction of a LEGO-based robot requires basic notions of mechanics, butgiving the students small manuals, as the official Con-structopedia included in the kits, or the one by FredMartin2, has proved to be enough.

2.2 The Final Studies Projects

Students working on their FSP usually affront morecomplicate problems, which require more perceptivecapabilities and more processing power than the onesLEGO brick offers. Mindstorms main drawback is itspoor sensorization: available sensors, like infrared orencoders, provide few and noisy data. We decided tocenter most of the FSP works around a single topic:building a robotic soccer team according to the F-180of the RoboCup [6]. Our idea is to promote collabora-tion among students by giving them a common prob-lem, a higher objective where their works are inte-grated. So, a student working, for instance, in an ad-hoc networking protocol to communicate robots mayfeel herself part of the same group than the studentsworking in image analysis, or the ones working in thecontrol of a single robot, or with the ones working inthe cooperative architecture.

We explored several platforms for this purpose, like

2http://constructopedia.media.mit.edu/

Kephera3, Tritt4 and EyeBot5. Prices were very dif-ferent and finally we chose the EyeBot robot [4], due toits processing power and because it was the only oneproviding a camera, which bursts possibilities. Thisrobot, shown in left side of figure 1, is equipped withthree infrared sensors, two shaft encoders and a 82x62pixels color camera, giving 4 fps. It also has two DCmotors, two servomotors and it is equipped with aMotorola 68332 microprocessor, and 1Mb. of RAMmemory. In addition, EyeBots are supplied with aradio communication module. All those devices aremanaged by the RoBios operating system, providedby the manufacturer, which offers a programming APIto the robot devices.

FSPs are carried out in the robotic research lab.Currently we have 6 EyeBot robots especially config-ured for the RoboCup. They have a kicker, and appearin one of two configurations: with a servo for panningthe camera, or that servo for tilting the camera. Allthe robots are used by all the students, that is, robotsare not assigned to any particular student. This waythey have to ensure that their programs are not over-fitted to the characteristics of a singular platform.

Some of the FSP recently finished develop a followwall and follow ball behaviors, an adhoc communi-cations protocol, and a teleoperator for the EyeBotrobot. FSPs currently in progress are the following:

• Soccer behaviors based on vision, like go-to-point.

• Self localization from local vision.

• Reliable communications library.

3 Graduate platforms: The Pi-oneer and the Aibo

With graduate students the aim of the course is moreresearch oriented, as expected for PhD candidates.The course contents lie around autonomous naviga-tion and robot behavior generation. Besides demand-ing the read lot of papers on the field, we offer two

3http://www.k-team.com/4http://www.microbotica.es5http://www.ee.uwa.edu.au/ braunl/eyebot

3 / 7

current state-of-the-art hardware platforms for experi-ments: a pioneer robot from ActivMedia, and an Aibo,the Sony robotic dog.

The idea of choosing these robots was to use themost standard platforms available. This way our re-search works can be validated by other groups own-ing the same robot, because they can check the re-sults we would claimed, and vice versa. Several topicswere considered when deciding which were the mostappropriate platforms. First, we had to choose thesize of the robot, then we had to decide its sensorequipment. In the 90’s, the successors of the famousXavier [11] populated most research robotic centers.The most widely used platforms were the B21 robotfrom Real World Interface (now the research divisionof iRobot Inc.), and the Nomad, from Nomadic tech-nologies. However, these robots’ sizes are consideredtoo large today. The same functionality can be gotin smaller robots, with the advantage of being easierto carry and handle. This is the case of the Pioneerrobot manufactured by ActivMedia that we chose.

The sensorization is another major issue when se-lecting a robot. For instance, the cheapest technologyare the infrared sensors. However, these sensors arethe least accurate, because they are very sensitive tolightening conditions. Another alternative is the useof sonar sensors, which are less sensitive to lighteningconditions and provide more information. Neverthe-less they are very noisy and uncertain at corners, re-flecting surfaces, holes, etc. Another option are thelaser sensors, which are very accurate, and less depen-dent on environmental conditions. Their high price istheir main drawback. The last sensor usually consid-ered in mobile robots are cameras, they may providemuch more information than others, but they also de-mand lot of processing power and good algorithms toextract it.

Our Pioneer robot, displayed in left part of figure3, is equipped with a ring of sixteen sonars, eightfrontal and another eight rear, it carries a laptop un-der GNU/Linux where the control programs run. Theplatform also carries a small webcam which is attachedto the laptop through USB port. The processing of theimages got by the camera is done in the laptop. Theplatform itself contains also a microprocessor, devotedto the low level calculi like collecting encoder and sonardata, and closing PIDs feedback control loops.

The software environment available for program-ming the Pioneer robot are the Saphira[8] and ARIA[1]suites. Both provide a client server approach to accessrobot devices from C and C++ programs. They alsooffer multitasking and networking interfaces. We havechosen ARIA because is licensed as free software underGNU GPL license.

Works currently in progress using the Pioneer robotare:

• Development of a generic architecture to build

robot controllers. This architecture is inspired inbiological ideas and based in the dynamic con-struction of hierarchies of schemas [5].

• Implementation of various reactive behaviors forrobot navigation.

• Development of localization and navigation algo-rithms using information from wireless communi-cation network.

The second robot that is available to graduate stu-dents in their research works is the Aibo robot shownin right side of figure 3. This is the newest memberof our robotic family. The reasons for starting to usethis robot is that, as in the Pioneer case, this robot hasbecome a major commercial success. Actually it is abestseller, and it can be considered the first robot re-ally sold at large scale. Its programming environmentwas opened last summer, which helped us to make ourmind about acquiring a unit in order to evaluate itsfeasibility as a research tool. The major goals with itare to start working on legged robots, and to studythe robot-human interaction problems. Besides, weare considering its possible use in the RoboCup envi-ronment, where Aibo robots have their own category.

The robot itself is controlled by a 384Mhz. RISCprocessor, has 64Mb of memory, temperature, in-frared, acceleration sensors, a color camera, and 20degrees of freedom. The programming environment isbased on the OPEN-R operating system6 whose APIwas opened for public domain last summer.

4 Conclusions and future lines

This paper has presented the environments we havechosen to teach robotics at the Universidad Rey JuanCarlos. We have briefly shown the methodology thatwe employed in teaching this subject to computer sci-ence students at different levels, describing the tools,both hardware and software, that we use. Additionalinformation about the courses, such as the detailedcontents, slides, etc. can be found in the web pages ofthe course7.

We are really proud of the results of the polls madeboth by the university itself and by ourselves. Thenumerical results shown by the official poll place thiscourse among the top ones from the point of view ofthe students. Another clear indicator of the quality ofthe course is the fact that this is an elective course, andthe last two years (only has been offered three times)the number of students applications has been higherthan the available seats. The only objection made bythe students is the high amount of time employed totest and debug the practical assignments due to poorperformance of the LEGO sensors.

6http://www.aibo.com/openr7http://gsyc.escet.urjc.es/docencia/asignaturas/robotica

4 / 7

Figure 3: Pioneer and Aibo robots at the Rey Juan Carlos University

Concerning future plans, at the undergraduate levelwe are considering to use another free operating sys-tem available for the LEGO platform. This one is aJava(TM) based operating system. The main reason isthe major activity in this project, as well as the addedvalue of using Java as programming language by thestudents. For the FSP students, we are thinking inworking with the same robots that are currently usedby the PhD candidates.

References

[1] ActivMedia. Aria reference manual. Technical report,ActivMedia Robotics, 2002.

[2] Ronald C. Arkin. Behavior based robotics. MIT Press,1998.

[3] Dave Baum. Dave Baum’s Definitive Guide to LEGOMindstorms. Apress, USA, 1999.

[4] Thomas Braunl and Birgit Graf. Autonomous mobilerobots with onboard vision and local intelligence. InProceedings of Second IEEE Workshop on Perceptionfor Mobile Agents, 1999.

[5] Jose M. Canas and Vicente Matellan. Dynamicschema hierarchies for an autonomous robot. InMiguel Toro Francisco J. Garijo, Jose C. Riquelme,editor, Advances in Artificial Intelligence, Iberamia2002, volume LNAI-2527, pages 903–912. SpringerVerlag, 2002.

[6] Hiroaki Kitano, Minoru Asada, Yasuo Kuniyoshi, It-suki Noda, and Eiichi Osawa. Robocup: The robotworld cup initiative. In Proceedings of the IJCAI-95Workshop on Entertainment and AI/Life, pages 19–24, 1995.

[7] Jonathan B. Knudsend. The Unofficial Guide toLEGO MINDSTORMS Robots. O’Reilly & AssociatesUSA, 1999.

[8] Kurt Konolige and Karen L. Myers. The Saphira ar-chitecture for autonomous mobile robots. In DavidKortenkamp, R. Peter Bonasso, and Robin Murphy,editors, Artificial Intelligence and Mobile Robots: casestudies of successful robot systems, pages 211–242.

MIT Press, AAAI Press, 1998. ISBN: 0-262-61137-6.

[9] F. Martin. Ideal and real systems: A study of no-tions of control in undergraduates who design robots.In Y. Kafi and M. Resnick, editors, Constructionismin Practice: Rethinking the Roles of Technology inLearning. MIT Press, 1994.

[10] Markus L. Noga. Legos: Open-source embed-ded operating system for the lego mindstorms.http://www.noga.de/legOS/.

[11] R. Simmons, J. Fernandez, R. Goodwin, S. Koenig,and J. O’Sullivan. Lessons learned from Xavier. IEEERobotics and Automation Magazine, 7(2):33–39, June2000.

5 / 7