Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

W ROS?W ROS?W ROS?W ROS?

Submi ed: 15th May 2013; accepted: 28th June 2013

Stefano Michiele o, Stefano Ghidoni, Enrico Pagello, Michele Moro, Emanuele Menega i

DOI: 10.14313/JAMRIS_1-2014/8

Abstract:This paper focuses on the key role played by the adop onof a framework in teaching robo cs with a computer sci-ence approach in the master in Computer Engineering.The framework adopted is the Robot Opera ng System(ROS), which is becoming a standard de facto inside therobo cs community. The educa onal ac vi es proposedin this paper are based ona construc onist approach. TheMindstorms NXT robot kit is adopted to trigger the learn-ing challenge. The ROS framework is exploited to drivethe students programming methodology during the lab-oratory ac vi es and to allow students to exercise withthe major computer programming paradigms and thebest programming prac ces. The major robo cs topicsstudents are involved with are: acquiring data from sen-sors, connec ng sensors to the robot, and navigate therobot to reach the final goal. The posi ve effects givenby this approach are highlighted in this paper by com-paring the work recently produced by students with thework produced in the previous years in which ROS wasnot yet adopted and many different so ware tools andlanguages were used. The results of a ques onnaire arereported showing that we achieved the didac cal objec-ves we expected as instructors.

Keywords: Educa onal robo cs, ROS, LEGO NXT robot,teaching robo cs.

1. Introduc onRobotics is amultidisciplinary ieldwhich involves

researchers from many different research areas, frommechanics to control theory, from electronics to com-puter science. Thus, robotic competences are taughtat different levels and from different points of viewthrough undergraduate and graduate courses. In thispaper, we focus on a course on Autonomous Roboticsoffered in the master curriculum of Computer Engi-neering at the University of Padua.

In our case this is the only course strictly related toRobotics: the lack of previous experience, apart froma general basic knowledge, makes it not easy for thestudents to tackle the complexity which is behind thebuilding of autonomous robots. As reported also by[20], incremental experiences are essential for thispurpose but, even providing a well-planned sequenceof experiences, we realized that the code developedby students suffered of one of the major plague ofrobotics: i.e. little (or almost no) code reuse. Eventhough reusing code is dif icult and possibly involvesdebugging and integration effort, it is nevertheless an

important aspect of softwaredevelopment that shouldbe learned. The absence of code reuse in the old courseimplementation, was caused by the fact that we useddifferent software tools and programming languages(and this is often the case for robotics courses, see forinstance [23], [24]). This is a situation similar to whathappens in the robotics community. However, the so-lution comes fromsoftware environments able to offerto different programs the possibility to communicateone with each other sharing a common interface: in afew words, a software framework.

The choice of exploiting a software framework of-fers several advantages in a high number of real-worldrobotics applications, and therefore in such scenar-ios it is often a compulsory choice. But when educa-tional purposes are concerned, some further motiva-tions should justify its adoption: the advantages pro-vided by a framework cannot be fully exploited in thisscenario, since time usually allocated to laboratiorialactivities is short, and the robotic platform exploitedis often quite simple. A very common robot for teach-ing activities is theMindstorms NXT: this option is rel-atively cheap and simple and for these reasons ratherfrequently adopted in university courses [12] [7] [4].Moreover, it should be noted that the NXT platformcomes with the NXC language that targets all the spe-ci ic capabilities of the robot: this means we are com-paring a small, easy to learn but hard to spend, proce-dural programming language targeted to the roboticsplatform employed for the experiments, with a large,general and complex framework with high potentialwhich is however tricky to understand, for which theNXT is just one of the many platform that can be han-dled.

The purpose of this paper is to show that inte-grating a general purpose framework into a univer-sity course has a positive didactic impact. Studentswere able to use a framework to complete the same ex-periments developed using NXC in the previous years,and the chosen framework (ROS) showedgoodperfor-mance also when used to handle a simple robotic plat-form. The success of this choice relies on exploitingthe framework for the laboratorial experiences with-out substantial overhead for the students. This waystudents develop their knowledge in robotics by usingtools that are easier to apply to real-world scenarios inwhich they will be asked to work after graduating.

Given the decision of employing a framework forteaching robotics, an important aspect is to choosewhich one is best suited, since in the last decade alot of robotics frameworks have been developed. This

60

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

is the case of URBI [1], OROCOS [3], YARP [6], Mi-crosoft Robotics Studio [8] and Piaget [9]; however,no one has obtained the proper consensus to becomea standard de facto. Recently, the scene has changedthanks to the introduction of the Robot Operating Sys-tem (ROS) [13]. ROS is a framework for robotics withthe addition of some operating system functionalities.A great variety of tools are integrated in order to al-low easy debug operations and analyze the commu-nication between processes. One of the main advan-tages that ROS offers among other similar products isthe large community that supports, uses and extendsthe software.

The choice of employing ROS for teaching roboticsis important to let the students have experienceof a complete and modern software framework forrobotics. Moreover, since ROS is likely to become themost popular choice in the future, supporting an in-creasing number of robotic platforms, its knowledgewill enable students to easily handle other robotsin the future. Many universities are adopting ROSto teach robotics, including South Carolina, Washing-ton, Brown, Stanford, KU Leuven, Sherbrooke, Tokyo,Sapienza and Leibniz University.

The paper is organized as follows: in section 2the robotic course organization will be described, to-gether with the expertise that students should gainwith it; in section 3 the experience with laboratoryactivities will be summarized, and a comparison be-tween before and after the introduction of ROS will beprovided. In section 4 the didactic impact of the lab ex-periences will be evaluated, based on the analysis ofthe homeworks produced by students, as well as ontheir answers to a questionnaire. Finally, in section 5some inal remarks on the choice of employing ROS forteaching robotics will be drawn.

2. Robo cs Course forMaster in Computer En-gineeringThe robotics course is based on a mixed approach

merging theoretical lectures in class and practical ex-periences in the laboratory. Lectures aim at building astrong background on robotics fundamentals, percep-tion systems, computer vision, and navigation, whilelaboratory sessions are meant to let students get ac-quaintedwith software tools and algorithms exploitedin robotics.

The platformwe chose is the Mindstorms NXT 2.0.Several robot kits are available for educational pur-poses [25], but we believe the NXT offers the right bal-ance of complexity versusmodularity [17] (in Italian).NXT is composed by a microcomputer, three motors,and a suite of sensors, including touch sensors, sonars,light sensors, microphones, compass and accelerom-eters. A set of LEGO parts also comes in the box, let-ting the user build structures for holding sensors inthe preferred position, as shown in igure 1: in (a), asketchof themodel employed in the laboratory experi-ence is shown, equippedwith a light sensor (blue bub-ble) and a sonar (red bubble); in (b), a robot holdingan omnidirectional camera.

(a) (b)

Fig. 1. The NXT in the Tribot configura on (a) with thelight sensor (blue) and the ultrasonic sensor (red).In (b), a robot holding an omnidirec onal cameraplaced on a green carpet is shown.

The strong point of this package is that the LEGOkit provides high lexibility, so that it is possible tobuild robots with a wide variety of shapes, and chooseamong a number of different sensor placements. Thebasic con iguration shown in igure 1 (a) (usuallycalled “Tribot”) is one of the simplest to control, andhas therefore been selected for irst laboratory expe-riences; it is a differential drive robot platform withtwo driven wheels in the front and a castor wheel onthe back. Motion control is rather simple in this case,but some complexity is added by the fact that motorsthemselves are not very precise, and the way they arecontrolled (e.g. acceleration curves) has an impact onthe trajectories the robot can follow.

3. Robo c ExperiencesIn this chapter the teaching experience before and

after the introduction of a software framework will beoutlined.3.1. Past experiences

In theprevious years,we taught students the open-source C-like programming languageNXC (Not eXactlyC) and we used the IDE called BricxCC. With this ap-proach, programs are composed of one or more tasks,and the syntax is easy to read and understand for peo-ple with little programming background.

However, it should be noted that the NXC is ded-icated to program the NXT platform and even if it isvery popular, its knowledge is not exploitable outsidethis context. Moreover, the NXC language is limitedto the sensors included in the NXT package, and it ishard to deal with additional sensors, like a webcamattached to the robot. In such cases some additionalsoftware and libraries should be run outside NXC tomanage the new sensors.

Robotic frameworks are going towards module-based architectures, often supporting distributed pro-cessing, and capable of exploiting network resourcesfor sharing data. Of course, exploitation of such as-pects is beyond the scope of the robotics course, how-ever, by employing such new frameworks even for de-veloping the irst laboratory experiences with simple

61

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

robots, it is possible to introduce concepts that will bereused by students when they will face more complexscenarios. Adopting ROS instead of relying on sim-pler languages, as NXC, presents of course an over-head [10] and a steeper learning curve, but from ourexperience it was clear that the overhead was limited:the number of hours dedicated to laboratory sessionswas the same in the course adopting ROS as in the onein which NXC was employed.3.2. Recent experience

Updating the Autonomous Robotics MSc course, asingle framework has been adopted in order to makestudents familiar with programming practices whichcould be useful in a future job.

As previously discussed, a number of frameworksfor robotics exist, some of which are speci icallytailored for didactic purposes, as it is the case ofTekkotsu [18], that cares about real-time aspects ofrobot programming, and Pyro (Python Robotics) [19].Almost all of such frameworks are able to support thebasic experiences that areproposedduring the course,so the main aspects considered choosing the frame-work to be adopted were: i) the possibility to exploitthe same framework also outside the context of thecourse, i.e., the generality of the framework; ii) thenumber of supported robots suited for lab experiences(in particular the NXT); iii) the community and thedocumentation, that represent a valuable help for stu-dents. So for example, by adopting Tekkotsu there is astrong constraint on the types of robots that are sup-ported, probably caused by the fact that it is a veryrecent project. The ROS framework is instead verystrong on this point, and has recently become evenstronger thanks to the ROS industrial project [5], thatis meant to improve the support for industrial robots,making it a proper working tool for professional engi-neers in the robotics ield.

The effectiveness of ROS in teaching is demon-strated by the rather large number of robotics coursethat have adopted it, including Brown University(USA), Cornell University (USA), University of Birm-ingham (UK) and obviously StanfordUniversity (USA).The panorama is quite wide, since the robots em-ployed among the courses are quite different, and thetasks assigned to students depend on this: for exam-ple, experienceswith inverse kinematics are proposedwith the PR2 robotic platform. Anyway, a commonbase about motion planning and basic computer vi-sion can be found in the majority of the courses.

The introduction of ROS did not require to changethe laboratory experiences objectives developed inprevious years. Such experiences focus on the quan-titative aspects typical of engineering and to cre-ate a constructivism/constructionismandeducationalrobotics architecture [11]. All didactical goals of thecourse were kept. In addition, we could add otherobjectives to the course related to the computer sci-ence curriculum: students have the opportunity towrite code in a widely used programming language(preferably C++, commonly used in the robotics ield)supporting Object-Oriented Programming (OOP) con-

Fig. 2. Robot behavior for the first experience

cepts. Among all available frameworks, ROS has beenchosen since it supports OOP, and also because itscommunity is very active, and represents a valuablehelp. A large variety of tutorials are available fromwhich students can easily learn.

In the following, the set of laboratory experiencesproposed in the coursewill be described. They involvethe classic challenges of robotics: robot control, navi-gation, and perception through sensory information.This way students can gain experience on different as-pects, and build a robot that has a certain degree ofintelligence. Multiple sensors have been employed: ul-trasonic proximity sensor, color sensor, and an omni-directional camera: this way it is possible to increasethe complexity of the sensing tasks in the different lab-oratory experiences.

Experience 1: Obstacle avoidance

In the irst experience, students have to plan arobot path in order to avoid two obstacles, repre-sented by cones. The robot has to go around the irstcone and stop 3 cm behind the second one for 10 sec-onds, and inally come back, as shown in Figure 2.

Robotics objectives: The irst objective is tomakestudents familiar with robots, and their motion andsensors. They have to deal with noisy sonar sensor,motor inaccuracy and odometry imprecision. Duringthis experience, students work with basic ROS mod-ules: they start practicing with ROS master (roscoreor .launch iles), then they explore nodes and top-ics functionalities (rostopic and rxgraph). Once stu-dents are familiar with these basic concepts, theycan evaluate robot characteristics by teleoperatingit using the keyboard. A simple visualizer (rviz) isalso available, which eases the result visualization.In order to do this we developed a basic packageto provide students the NXT model, the robot con-troller to translate velocity command into joint rota-tions and the teleoperation program. Finally, studentscreate a new package and develop their own mod-ule, which communicate with the others following thepublisher/subscriber mechanism, which is exploitedalso for reading sensors, e.g. acquiring range data, andfor controlling robot movements. The experience in-volves robotics topics like interpreting uncertain sen-sor data, navigation and control, andmotion planning.

Computer science objectives: The experience ismeant to make students review the concepts of datastructure and class. They can understand how dataare handled in the framework by looking at prebuiltROS messages, and they are also asked to analyze thepackage structure in order to know how they dependone from each other; this way they will be able to de-

62

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

velop their own packages in a similar way. Studentswill also analyze the callback construct which is cov-ered through the publisher/subscriber communica-tion method. In this irst experience a simple problemis proposed, so that students can try to solve it in afast procedural way as they usually do. Nevertheless,an object oriented approach is promoted to build in-dependent entities to control the robot.

Experience 2: Path planning

The goal of the second experience is robot naviga-tion into a map composed of NxM cells, that are rep-resented using a green carpet with a white grid, overwhich the robot moves. Students have to extend thealgorithm created in the irst experience to make therobot go from a Start cell to a Goal cell while avoid-ing obstacles, and understanding its own motion in-side the map. To guide the robot motion a color sen-sor is exploited in order to identify the squares bor-ders: as long as the robot moves, the sensor indicateswhether it is going over the green carpet or a whitestripe. The representation of the robot movements issimpli ied, since it can only go to the north, south, east,west squares, that is, it cannot move diagonally; thismeans the activities for navigating across the map arebasically forward translations by one cell and rota-tions. Since employed motors are not extremely pre-cise, the orientation of the robot is affected by inaccu-racies that students need to deal with: once the robotcrosses a white stripe, it performs left and right rota-tions in order to understand its direction with respectto the map grid.

The experience is divided into two scenarios: inthe irst one, obstacles in the map are ixed and stu-dents knowwhere they are,whereas in the second onethey can be moved, hence the correct route cannot beknown in advance. Figure 3 shows an example of mapand a possible path to reach the goal.

Once the robot has reached the goal, it is asked topush a touch sensor, which is in turn connected withROS. This tells the system the experimentwas success-ful.

Robotics objectives: In this experience studentshave to develop a path planning algorithm choosingamong those presented in the course. They deal withthe intensity sensor data and exploit communicationthrough ROSmodules. Understandingmodules is veryimportant working with ROS. Students are pushed tosplit their code into a reasonable set of modules thatshould communicate among each other. Using sen-sory information the robot has to recognize the mo-tion from one cell to another, navigate in the map andavoid obstacles in order to reach the Goal. Since themap is not known in the second scenario, an internalrepresentation of the checked cells and robot positionshould be developed. The purpose of the last part ofthe experience is to learn how to exploit communi-cation between two different devices (the robot andthe touch sensor) using ROS. The main robotics topicsfaced by students in this experience are localizing andmapping, and multiple-robot coordination.

Fig. 3. Map example

Computer science objectives: A more com-plex experience highlights the importance of a well-structured code. Students need tomodel the robot andthe map as two different entities, and to generate amessage low that starts from the former and goes intothe latter. The change from a static map to a dynamicone also helps students to reconsider their choices insoftware design in order to better identify which databelongs to which structure. Finally, the communica-tion between the robotmoving on themapand the onehandling the touch sensor promote the abstraction ofthe robot class. The irst one should implement a verysmart behavior in order to move and manage severalsensors, while the second one has to take care of thetouch sensor only. Both elements are the same entity(a robot), so they comes from the same generic class,but each one is a different speci ic class.

Experience 3: Percep on using computer vision

In this lab experience a new sensor, based on com-puter vision, is introduced. The robot is given the sametask of Experience 2, that is, reaching a goal on a mapwith moving obstacles, but this time the sensory suiteis different: in place of the infrared sensor, an omnidi-rectional camera is exploited.

As a irst step, students are asked to build theirown omnidirectional sensor and calibrate it with the

63

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

(a) Lego NXT starting con iguration.

(b) Lego NXT omnidirectional con iguration.

Fig. 4. Result of the line detec on algorithms when alabyrinth is analyzed. (a), and a bird’s eye viewreconstructed from such image (b).

Ocam Calib tool [14]. They should then ind the opti-mal placing on the robot, which involves twomain pa-rameters: the height from the ground, and the orienta-tion of the axis of the mirror, which can be vertical orslightly tilted. At this point the real laboratory experi-ence, divided into two parts, starts.

As a irst task, students are asked to implementa vision-based module that behaves like the infraredsensor of the previous experience, thus providing thesame output. This can be achieved by selecting a smallRegion Of Interest (ROI) in the image, in which objectsat a certain distancewill appear, and observing its con-tent.

The second task is more focused on robotic vision,since students are asked to develop a ROS module ca-pable of analyzing all white stripes visible on the car-pet. In particular, the lines which are closer should bedetected to evaluate their distances to the robot, in or-der to gather its position inside the cell and its orien-tation with respect to the grid; in igure 4 it is possibleto see the result when the white stripes composing alabyrinth are analyzed. The resulting module is ableto overcome the data provided by the infrared sen-sor: thanks to the vision sensor, it is possible to detectstripes at a rather highdistance, and to recover the ori-entation of the robot with respect to the grid by look-ing at a single image, instead of performing rotationswhile passing over a line.

Robotics objectives: In previous experiences stu-dents have already developed some hands-on robotsknowledge, therefore guidelines do not specify detailson how to place the vision sensor, nor how to develop

vision algorithms. Students are asked to explore dif-ferent solutions, and ind the best-suited ones: for ex-ample, by properly tilting the omnidirectional cam-era it is possible to extend the detection range, butthis leads to a slightly more complex processing. Fac-ing the trade-off between complexity and accuracy isan important aspect at this stage. Another importantobjective is to face computer vision with omnidirec-tional images, which is widely used in robotics. Stu-dents will learn how to build an omnidirectional sen-sor, calibrate it, and exploit the huge amount of infor-mation included in each single image. Finally, experi-ence with ROS modules and how to manage commu-nication among them will be developed: students willcreate a module for acquiring images, and use its out-put to feed another module implementing image pro-cessing algorithms. This experience combines the im-age acquisition andprocessing topics togetherwith lo-calizing and mapping topics inherited from the pre-ceding experience.

Computer science objectives: One of main goalsof this experience is the creation of a module that canreplace an existing sensormodule and then improve itwith new features. This implies code modularity, andalso encourage the use of inheritance and design pat-terns in order to make the work easier when classesare well-designed. Using an environment similar tothe one introduced in the second experience helps stu-dents to focus on the computer vision activity; how-ever, students that chose a good software design in theprevious experience will be able to easily reuse it inthis third one.

4. Evalua on of didac c impactIn order to obtain a feedback on the effectiveness

of the adoption of ROS, we compared the results ofthe group of students that attended the AutonomousRobotics course two years ago before we introducedROS and the group of last year, that exploited theROS framework. The comparison exploits on one handsome objective considerations about problem-solvingmethods and code developing and on the other handthe subjective students’ opinions about laboratory ex-periences, satisfaction about the course, and future ex-pectations.

4.1. Comparison with the past

The use of ROS as a common framework pushesstudents to develop algorithms in a structured envi-ronment. This was not the case in the previous years,since NXC is still a procedural programming language.Developing code in NXC limits students to work in aprocedural paradigm. NXC provides functions or datastructures, but students do not actually use them, be-cause they feel they can code faster if they write theiralgorithms in a single ile. The analysis of the codeof last year reveled students favored cut-and-paste tothink to a general structure for the code; for the samereason, they preferred to use global variables to pass-ing parameters, and created ad-hoc solutions to prob-lem generalization. While using ROS, this year’s stu-

64

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

Tab. 1. Data from course students a er theintroduc on of a common framework.

1st exp. 2nd exp. 3rd exp.Code reuse 75% 100% 100%Structured data 38% 88% 100%Classes 63% 88% 88%

dents are pushed to organize their software into mod-ules, reuse their data structures and classes, exploitclass inheritance. They will also experience the powerofmessage sharingmechanism, which is an importantservice offered by robotics frameworks.

The proposed experiences are designed so thatstudents can have an advantage if they are able to cor-rectly formalize the problemand choose a proper soft-ware design for implementing solutions, since in thisway each experience can be built on top of the previ-ous ones. In Table 1 the results of the analysis of thesoftware produced by this year’s students is reported.The source code (about 1000 lines for each experi-ence) of sixteen students (grouped by two) has beenanalyzed looking for the following OOP concepts:- features coded in functions ormethods to be appliedin different situations (code reuse);

- similar characteristics and values related to eachother in order to build a single structure (struc-tured data);

- modeling of real entities into objects that representsthem and their features (classes).

Data reported in Table 1 represent the percentageof students groups implementing each OOP conceptat least once in their source code. As it can be seen,code reuse and adoption of structured data stronglyincreased after the irst experience.4.2. Students sa sfac on

Students were asked to ill an anonymous ques-tionnaire summarized in Table 2. The answer to eachquestion is represented by a choice among four states:Very much (green), Enough (blue), A little (red), Not atall (yellow). Some of the statements are quite similar,in order to emphasize small differences that could behidden by a multiple choice answer.

Tab. 2. Results of the ques onnaire.

Leg.: Not at all A little Enough Very muchQ1. During the experiences of the

robotics course I exploitedknowledge acquired in othercourses that I had not put intopractice.

Q2. Programming skills I developedin previous courses were suf-icient for working on the ROSframework.

Q3. I gained new programming ex-perience because I had to workwith a complex framework asROS is.

Q4. In order to ef icientlyworkwithROS, I have been forced to di-vide my software into modules,which in turn made it easier toreuse it.

Q5. In my future job I will be askedto work with modular softwarestructures similar to ROS.

Q6. By working with ROS I have gotin touch with a well structuredsoftware, that has been a sourceof inspiration for new ideas onhow to develop my software.

Q7. By working in groups I im-proved my ability to split tasksamong people.

Q8. By working in groups we wereable to reach results Iwould nothave reached alone.

Q9. By working with real robots weneeded to deal with practicalproblems that would have notshown up in a simulated envi-ronment.

Q10. Thanks to the lab experiencesI developed expertise I will ex-ploit in my future job.

Q11. Lab experiences require a lot oftime to be completed, but arethe only way I can develop ex-pertise that are useful formy fu-ture job.

65

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

Q12. Lab experiences required an ex-cessive work load, and shouldcorrespond to a higher numberof credits.

Q13. I would like that a larger num-ber of courses would be basedon a mixed approach includingboth theory and laboratory ex-periences, in order to put intopractice what we learn duringlectures.

Q14. The complexity of lab experi-ences increases gradually.

Q15. What I learnt in each experi-ence has been useful for the fol-lowing ones.

Q16. In my future job, I will be askedto work on topics that are simi-lar to the ones faced in the lab-oratory.

The questionnaire was meant to test several as-pects of the laboratory activity, like:- exploitation of students’ background in terms ofprogramming skills and software engineering;

- effort spent in developing the experiences;- closeness with future job activities.

Answers to the questionnaire highlight that pro-gramming capabilities students were suf icient, eventhough they would like to had more programming ex-perience (Q2); moreover, such capabilities improvedduring the practical experience in the laboratory (Q3).From the software engineering point of view, it turnedout that the ROS framework forced students to adopta modular approach for their software, which easedits reuse (Q4). Students appreciated team work, andare convinced that it is very dif icult to achieve im-portant results by working alone (Q7-Q8). Studentsshowed a moderate con idence on the fact that exper-tise coming from lab experiences could be reused ina future job (Q10,Q16): answers to these questionswere based on the current working experience that acertain number of students already had, while the oth-ers answered based on what already graduated col-leagues told them. Students seemed to greatly appre-ciate the hands-on approach of the course, and wouldagree on increasing the number of courses adoptingthis approach (Q9,Q13), even though thismeans an in-crease in work load (Q11-Q12). Finally, students alsoappreciated theway experiences gradually increase incomplexity (Q14-Q15).

Overall, the questionnaire demonstrates thatchoices made while designing the course had agood impact over several aspects, including codeproduction, putting into practice theoretical con-cepts studied during lectures, and working with astructured framework like ROS.

5. ConclusionThis paper presented a series of experiences tar-

geted to MSc students attending the AutonomousRobotics course. Experiences already de ined for thecourse in the previous years, based on the construc-tivist approach, are now developed inside a roboticframework, that forces students to get in touch withadvanced software structure, and take advantage ofthe services it offers. The introduction of ROS asa framework pushes students to use OOP conceptsthanks to the highly structured environment they haveto work with. The overhead given by understandingand learning how to use a new framework, besides itsintrinsic added value, is compensated by the later easeto develop code for the subsequent laboratory experi-ences, to integrate new sensors, and to interact withdifferent devices. Finally, being able to handle com-plex softwares likeROS is a strong reward for students,which realize they have learnt how to deal with real(and complex) robotic frameworks.

The course includes a set of laboratory experi-ences that represent an important feedback for stu-dents’ achievements. Experiences test the capabilityof controlling a robot (experience 1), sensing the en-vironment with simple sensors and modifying therobot’s behavior accordingly (experience 2) and han-dling more complex sensors that need high-level pro-cessing (experience 3). This can be seen as a smallbut complete set of abilities students should gain todeal with robots, and the positive outcome of such ex-periences is the ultimate proof of their achievements.For this reason, the way experiences cover a numberof subjects, and their increasing complexity level hasbeen stressed in the paper.

The analysis of a report for each laboratory ex-perience and of the developed code made it possi-ble to verify students’ comprehension of robotics ba-sics, their use of complex syntactic constructs andtheir problem-solving capabilities. Finally, students’satisfaction was tested by means of a questionnaire.The results highlight a good response both regardinghow students’ expectations were met, as well as im-provements in robotics and programming skills. Thishas also been assessed by testing the robots movingon the map, and observing how they deal with a dy-namic environment. Since all students were able tocorrectly complete all the experiences, even thoughgoing through a number of dif iculties, it is possible toconclude that the proposed set of experiments is cor-rectly planned.

The laboratory experiences are currently limitedby both the robots used (more advanced ones wouldrequire stronger investments) and by the time thatcan be dedicated to experiences. If such limitations

66

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

could be overcome, an interesting extension would beto face challenges posed by humanoid robots, start-ing from the gait. More advanced tasks, like grasping,are too complex to be practically solved in the con-text of this course. The introduction of the approachpresented in this paper into other courses than Au-tonomous Robotics is also planned.

AUTHORSStefano Michieletto∗ – Intelligent Autonomous Sys-tems Lab (IAS-Lab), Department of Information En-gineering (DEI), Faculty of Engineering, The Univer-sity of Padua, Via Ognissanti 72, I-35129 Padua, Italy,e-mail: stefano.michieletto@dei.unipd.it.Stefano Ghidoni – Intelligent Autonomous SystemsLab (IAS-Lab), Department of Information Engineer-ing (DEI), Faculty of Engineering, The University ofPadua, Via Ognissanti 72, I-35129 Padua, Italy, e-mail:stefano.ghidoni@dei.unipd.it.Enrico Pagello – Intelligent Autonomous SystemsLab (IAS-Lab), Department of Information Engineer-ing (DEI), Faculty of Engineering, The University ofPadua, Via Ognissanti 72, I-35129 Padua, Italy, e-mail:enrico.pagello@dei.unipd.it.Michele Moro – Intelligent Autonomous SystemsLab (IAS-Lab), Department of Information Engineer-ing (DEI), Faculty of Engineering, The University ofPadua, Via Ognissanti 72, I-35129 Padua, Italy, e-mail:michele.moro@dei.unipd.it.Emanuele Menegatti – Intelligent Autonomous Sys-tems Lab (IAS-Lab), Department of Information En-gineering (DEI), Faculty of Engineering, The Univer-sity of Padua, Via Ognissanti 72, I-35129 Padua, Italy,e-mail: emanuele.menegatti@dei.unipd.it.∗Corresponding author

REFERENCES[1] J. Baillie. URBI: Towards a Universal Robotic

Low-Level Programming Language. In 2005IEEE/RSJ International Conference on IntelligentRobots and Systems, pages 3219–3224. IEEE,2005.

[2] J. C. Baillie. Urbi 2: Introduction to concurrentreal-time programming. In Proceedings of theThird International Workshop on Software Devel-opment and Integration in Robotics. IEEE ICRA,May 2008.

[3] H. Bruyninckx, P. Soetens, and B. Koninckx.The real-time motion control core of the Oro-cos project. In IEEE International Conferenceon Robotics and Automation, pages 2766–2771,2003.

[4] A. Cruz-Martin. J.A. Fernandez-Madrigal, C.Galindo, J. Gonzalez-Jimenez, C. Stockmans-Daou, and J.L. Blanco-Claraco. A LEGO Mind-storms NXT approach for teaching at Data Ac-quisition, Control SystemsEngineering andReal-Time Systems undergraduate courses. Comput-ers & Education, 59(3):974–988, Nov. 2012.

[5] S. Edwards, and C. Lewis. Ros-industrial:applying the robot operating system(ros) to industrial applications. IEEE Interna-tional Conference on Robotics and Automation,ECHORD Workshop, St Paul, Minnesota, May2012.

[6] P. Fitzpatrick, G. Metta, and L. Natale. To-wards long-lived robot genes. Robot. Auton. Syst.,56(1):29–45, Jan. 2008.

[7] J.M. Gomez-de-Gabriel, A. Mandow, J.Fernandez-Lozano, and A.J. Garcia-Cerezo.Using LEGO NXT Mobile Robots With LabVIEWfor Undergraduate Courses on Mechatronics.IEEE Trans. on Education, 54(1):41–47, Feb.2011.

[8] J. Jackson. Microsoft robotics studio: A technicalintroduction. IEEE Robotics & Automation Maga-zine, 14(4):82–87, Dec. 2007.

[9] J.D. Dessimoz, P.F. Gauthey, and H. Omori, Pi-aget Environment for the Development and In-telligent Control of Mobile, Cooperative Agentsand Industrial Robots. International Symposiumfor Robotics (ISR), Aug. 2012.

[10] T. Koletschka, and A. Hofmann. TechnikumWien’s entry in the Robotour’11 competition.In Proceedings of the 2nd International Confer-ence on Robotics in Education (Rie2011), pages151–156, Wien, Austria, September 2011.

[11] E. Menegatti, and M. Moro. Educational roboticsfromhigh-school tomaster of science. In SIMPARWorkshop on Teaching Robotics, Teaching withRobotics, pages 484–493, Darmstadt, Germany,November 2010.

[12] P. Ranganathan, R. Schultz, and M. Mardani. UseOf Lego NXT Mindstorms Brick In EngineeringEducation. InProceedings of the 2008ASEENorthMidwest Section Conference Educating the Engi-neer of 2020, Platteville,Wisconsin, USA, October2008.

[13] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. B.Foote, J. Leibs, R. Wheeler, and A. Y. Ng. ROS:an open-source robot operating system. In ICRAWorkshop on Open Source Software, 2009.

[14] D. Scaramuzza, A. Martinelli, and R. Siegwart.A toolbox for easy calibrating omnidirectionalcameras. In Proc. of The IEEE International Con-ference on Intelligent Robots and Systems (IROS),2006.

[15] S. Thrun, D. Fox, W. Burgard, and F. Dellaert. Ro-bust monte carlo localization for mobile robots,2001. In Arti icial Intelligence, Volume 128, Is-sues 1?2, May 2001, Pages 99-141.

[16] J. Arlegui, E. Menegatti, M. Moro, A. Pina.Robotics, Computer Science curricula and In-terdisciplinary activities In Proceedings ofthe TERECoP Workshop ”Teaching with robotics:didactic approaches and experiences pp.10-21November 3-4, 2008 Venice (Italy).

67

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 8, N◦ 1 2014

[17] M. Moro, E. Menegatti, F. Sella, M. Perona. Im-parare con la Robotica - Applicazioni di problemsolving. Edizioni Erickson Trento (Italy), pp.1-196, 2011.

[18] E. Tira-Thompson, D.S. Touretzky. The Tekkotsurobotics development environment. In Proc.IEEE ICRA 2011 pp. 6084-6089 May, 2011.

[19] D. Blank, D. Kumar, L. Meeden, H. Yanco. Pyro:A python-based versatile programming environ-ment for teaching robotics. In Journal on Educa-tional Resources in Computing (JERIC), Volume 4,Number 3, p.3, 2004.

[20] A. Nourdine. Teaching fundamentals of roboticsto computer scientists. In Computer Applica-tions in Engineering Education Volume 19, Issue3, pages 615–620, September 2011.

[21] Robot Operating System. www.ros.org

[22] Terecop project: Teacher Education on Robotics-Enhanced Constructivist Pedagogical Methods.www.terecop.eu

[23] G. Cielniak, N. Bellotto, T. Duckett IntegratingVision and Robotics into the Computer ScienceCurriculum In Workshop on Teaching Robotics,Teaching with Robotics, pages 484–493, Riva delGarda, Italy, April 2012.

[24] A. Albers, M. Frietsch, V. Bartenbach, G. Robens,N. Burkhardt. A New Robotics Laboratory for In-terdisciplinary Mechatronic Education In SIM-PAR Workshop on Teaching Robotics, Teachingwith Robotics, pages 456–464, Darmstadt, Ger-many, November 2010.

[25] M. Ruzzenente, M. Koo, K. Nielsen, L. Grespan,and P. Fiorini, A review of robotics kits fortertiary education In Workshop on TeachingRobotics, Teaching with Robotics, pages 44–50,Riva del Garda, Italy, April 2012.

68