Teaching Autonomous Robotics over the World Wide Web: an Online Computer
John C. Gallagher, Wright State University
Steven Perretta, Wright State University
Richard F. Drushel, Case Western Reserve University
About the authors...
Back to the article
Education and research in the area of mobile autonomous robotics have become very popular. New developments and improvements in hardware technology have made mobile robots pertinent to a growing number of problem domains. Following this trend, education in robotics related disciplines has found its way into many engineering, computer science and cognitive science curriculums. From an educational standpoint, the ability to offer students access to mobile autonomous robotics related courses and materials enables the student to participate in a number of practical areas, including engineering, computer programming, artificial intelligence, project management and technical writing. Besides presenting these experiences in an entertaining fashion that may motivate students in their studies, courses in mobile robotics may function as a "gateway" to further studies of specific fields in engineering and computer science. However, these classes are very resource intensive, and typically limit access to a small number of students when offered in a traditional classroom setting. Offering classes of this nature "online" may serve to eliminate this problem, as well as open the door to a broader range of students in terms of educational background and geographic location.
This paper describes efforts to date in providing a World Wide Web (WWW) based course in autonomous robotics. We will begin with a discussion of how the unique benefits of autonomous robotics courses are enhanced by offering them via the web. We will then discuss our WWW course and some special challenges we encountered during its development. Finally, we provide some conclusions drawn from our experience teaching this class.
Engineering is about solving problems of practical import, and traditional classroom instruction alone may not be sufficient to educate a practicing computer engineer. Typical classroom exercises are usually designed to illustrate a point or demonstrate a technique rather than to approximate problems one will really face. Real world problems often lack a clear statement of what is needed, and rarely possess any single "correct" solution.
In recent years, engineering practica employing autonomous robots as a pedagogical tool have become popular [2,3,6,7,12]. These experiences often employ the "low threshold no ceiling philosophy" , which states that participation should have few prerequisites -- but should allow for unlimited sophistication and complete flexibility in selecting solutions. In these courses, the idea of the practicum, defined by Schon as "a setting designed for the task of learning a practice"  is well realized. Students are afforded an opportunity to develop engineering skills that complement the analytical methods being learned in other courses. Many autonomous robotics problems can be solved reasonably well using techniques accessible to the novice yet being sophisticated enough to require advanced techniques to arrive at excellent solutions. Among other benefits, the above mentioned robotics based practica provide the following advantages to students:
WWW based distance education has also become somewhat fashionable. We are currently offering an autonomous robotics practicum entirely over the Internet. Students are provided with robot simulation software to run at home, access to on-line software that provides remote interaction with a real Khepera robot in our lab, WWW streaming video access to this Khepera robot, and a series of control problems of increasing difficulty. Students are also provided with background readings that suggest, but do not dictate, how they might solve each problem. Students are also required to engage in class discussions via a class message board and are graded on the quality of individually maintained engineering journals that document their efforts. Offering our class via the web, in addition to providing students with convenient access to resources, actually enhances our ability to provide four of the five benefits previously mentioned (i.e., points a, b, c, and d).
2. Our Course
Our WWW Autonomous Robotics course was offered for the first time to a small, select group of students resident at Wright State University. During that time, the format of the course was finalized, trial student problem sets were formulated and tested, and software tools were developed and evaluated. Subsequently, an official offering of the class was made available to students in the winter quarter of 2002. This class made use of final versions of the software we developed, and followed the finalized course format. Full course information is archived at: http://gozer.cs.wright.edu/classes/ceg499/ceg499.html
An external link to the authors' full course information.
In this section, we will present a very brief summary of the course and focus on our solutions to specific problems we encountered along the way. The reader is referred to the class WWW page for further details.
WWW Autonomous Robotics is an online, asynchronous computer engineering practicum. There are no formal exams. Rather, students are given a series of problems of increasing complexity. For each problem, they are provided with reading assignments that summarize both what is expected as well as some ideas on how to formulate a solution. After a period of guided instruction, students engage in problem solving. They are encouraged to collaborate using tools we provide (details on tools follows). Students are first expected to develop Java code to operate a simulated robot on their home computer (Figure 1). When they feel ready, they may upload their code to our robot server and view the results when executed on a real robot (Figure 2). Upon completion of a unit, students are required to submit both their solutions and their engineering journals for formal evaluation and grading. The above course plan is relatively standard among engineering project classes. Our choice of delivery medium, however, introduced some additional difficulties.
Figure 1. A screenshot of the Robot Simulator.
A full-size Figure 1 (66 KB).
An interactive simulated demo (~40 KB) of the Robot Simulator.
Requires Shockwave plugin.
An external link to the authors' class web page where you can download the full Java version of the Robot Simulator.
Figure 2. A picture of the real robot on which the code can be executed.
We strongly desire that our course be accessible to a diverse audience. Because we don't want to burden students with excessive expense and complexity, any client software we require must be freely available on all major platforms and be forgiving of poor connectivity and/or low network bandwidth. File transfer for turning in student journals, online chat functionality, and message board support are provided via a Hotline Server , which is available free of charge for all major computing platforms.
We maintain a RealVideo  server that provides a live bird's eye view of the real robot. RealClients are available free of charge for most platforms and are fairly tolerant of slow network feeds. We also use a NuSpectra Web cam  that can be remotely controlled to provide close-up views and snapshots. This resource functions with any Java enabled WWW browser.
2.2 Journal Preparation Tools
Because our class is entirely online -- journals must be prepared and submitted via the Internet. GSView and Ghostscript  can be used to convert the output of nearly any word processor or document preparation software into standard PDF files that can be efficiently uploaded for evaluation. Both are available free of charge. Students are welcome to use any document preparation software with which they are comfortable.
2.3 Robot / Environment
We provide 24-hour access to our robot. We do not, however, have a full time attendant in the lab to fix the robot or arrange the robot's environment into special configurations. We had to exert special effort to design an environment in which it is difficult to damage or strand the robot. The size and shape of the maze wall sections were carefully selected to be tall enough to prevent the robot from escaping and low enough not to interfere with the robot arm. Cylinders and other moveable objects in the environment are weighted to help insure they right themselves when dropped by the robot. Further, all student problems are designed in such a way that there are no special start or end configurations. That way, there is no need for a human operator to reset the environment every time a new student wants to test code.
2.4 Java Based
We have recently developed a set of portable software tools that function to simulate and remotely operate the Khepera robot. Because both programs offer an identical API and programming environment, controller code developed under simulation can be ported seamlessly to the remote control program, and vice versa. The API's were designed to be both intuitive and simple, representing a subset of the Khepera's built in commands. The programming environment is defined as a single Java thread class that is executed and managed by the main program. Together these features serve to divorce the student from the complexities associated with the main programs, and minimize the students' need to understand many of the details associated with the Java programming language in general.
Upon completion of our first official offering of the class during the winter 2002 quarter, we found that most (if not all) of our students had no difficulty learning how to use these programs when developing their first controllers. Students with little or no familiarity with Java were able to write effective control code without having to spend an inordinate amount of time learning how to use the software or the Java language.
The culmination of our first two years of work was the creation of a stable set of enabling tools and methods, necessary experience in delivering content, a trial run of the course with a small group of selected students, and an official offering of the class as a computer engineering elective. This latter class can be considered a scaled-up version of the course design obtained from the results of the first trial run of the class. The following subsections deal with some of the issues we were concerned with as a result of having a greater number of students in the class with potentially diverse levels of experience. Areas of interest included: the learning curve associated with the use of course related software, the effectiveness of network based communication between staff and students, and the quality of electronic journal submissions.
Unlike the trial version, our last offering of the course involved students who had varying levels of programming experience. Although having some programming experience was a prerequisite for enrollment in the class, we encountered a wide range of competencies among the students enrolled. With the assistance of a set of both online and offline manuals, and control code examples, most students were able to begin writing robot controllers within the first week of class. Those students who were unfamiliar with Java had only minor difficulties; these centered around learning the syntax for writing Java methods. Due to the nature of the our API's and programming environment, little to no knowledge of object oriented programming or the Java class libraries were required. As we had hoped, the main challenge that confronted students dealt with solving the specific control problem at hand.
3.2 Network Based Communication
The authors and their colleagues have considerable experience in offering autonomous robotics practica. We have observed that face-to-face interactions among students engender a collegial atmosphere that provides support and motivation to achieve. In this subsection we outline the results of interaction mediated by simple Internet collaboration tools. Within this context we pose two questions: were students able to sufficiently articulate questions and comments using this medium, and was there adequate accessibility to faculty and staff via this medium.
Given that text based correspondence typically requires the use of clear and concise expressions of meaning, students with poor communication skills may find themselves at a disadvantage using these collaboration tools. To further complicate matters, meaningful discussions regarding class related programming problems can be relatively complex, and require familiarity with the vernacular of computer science and engineering. In our recent experience, we found that students who had difficulties relating their questions and comments required slightly more attention than others, and we often had to second-guess the intended meaning behind certain pieces of correspondence. As the course progressed, however, these students improved in their ability to articulate problems. It is assumed that this improvement resulted from the extensive number of formal and informal online meetings held.
The second question can be addressed based on the chat logs saved throughout the ten-week quarter. At least one member of the faculty/staff was online -- ready to address any questions that arose, between 9:00am and 5:00pm Mon. through Fri.. For the most part this simply entailed having a Hotline client open throughout the day and responding to periodic notifications from students. Because student schedules were meant to be flexible given the framework of the course, preset online "office hours" would not afford adequate correspondence, hence a virtual open door policy was adopted. Because the chat clients used could maintain a history of conversations over an extended time period, students could benefit from other class members' previous interactions with staff members.
3.3 Journal Quality
The authors and their colleagues have observed in other, traditional project courses that student journals kept in paper notebooks are usually superior to those kept using word processors or other document preparation software. We attribute this to the fact that when completing projects that require stretches of time away from the computer, use of paper journals is more spontaneous as it is easier to add entries to a carried notebook than it is to return to a computer (we are presuming that most students do not have personal digital assistants). Since, by its very nature, WWW Autonomous Robotics requires that most work be completed at a computer -- we originally hoped that students might not suffer the same loss of spontaneity.
We compared journals produced in this class with those produced by comparable students in another, similarly structured but traditionally delivered project course. We found that the electronic journals, on average, lacked the level of detail found in their paper notebook counterparts. Most students had no problems describing what they had accomplished and their final results of a given assignment. What was lacking, however, was content that dealt with why they had committed to a particular solution and what analytical processes took place during the evolution of their solution. The reasons for this disparity between the two sets of journals were multifold, and ranged from the different motivation levels of individual students to the added overhead (in terms of time) associated with editing documents using a word processor and graphics software. Students who displayed a motivation to learn the subject (as expressed through frequent contact with staff and greater involvement in chat sessions) typically created higher quality journals -- as would be expected. Also, a significant number of students initially had problems converting documents to PDF. This was remedied over time as students gained experience using the software.
Many of the content specific issues regarding the electronic journals could potentially be addressed by giving students examples of "good" and "bad" journal submissions. In our class, students were not exposed to each other's work. This policy was put in place to discourage plagiarism, and to encourage independent forms of expression. Making generic journal templates available that serve to demonstrate some of the key elements of a "good" journal may help guide those students who have limited experience in technical writing. Making certain sections of each class member's journal available to the entire class may also prove to be a valuable feedback mechanism. In this way students can exchange ideas and benefit from others who may possess expertise in other areas.
In an attempt to make our work available to all interested parties and encourage community participation in computer engineering and robotics related subject matter, we have packaged and made available all course materials and software as well as additional information on building maze environments and configuring video and robot servers. This package is available from the class WWW page (http://gozer.cs.wright.edu/classes/ceg499/sim/sim.html) and allows our work to be duplicated at other institutions with minimal outlay of funds and material resources.
An external link to the authors' class web page where you can download the package.
To date our efforts to involve young people from outside the academic environment at Wright State University included an open house for a Boy Scout troupe from the Cincinnati area. During this session, we introduced youngsters to some of the issues involved with autonomous robotics and let them experiment with the software in our lab. Under minimum guidance, groups designed and implemented a simple controller -- the results of which were very encouraging. To further disseminate the results of this work, we plan to partner with local high schools to determine what value our course, or one derived from it, might have in attracting talented students to computer science and engineering disciplines.
To our knowledge, this project represents the first attempt to offer an autonomous robotics practicum entirely over the Internet. We believe that this effort can bring these valuable educational experiences to a wider audience while maintaining, and in some cases augmenting, the benefits of a more traditional on-campus offering. To date, we have developed a significant amount of infrastructure. We now stand ready to fully evaluate the utility of our approach.
This work is supported by NSF Grant 0096311 to JCG. Additional support provided by the Ohio Board of Regents and Wright State University. We would like to thank Greg Kramer for organizing and conducting the open house held in the lab.
 AFPL Ghostscript Home Page. Online Internet Available.
 Beer, R.D., Chiel, H.J., and Drushel, R.F. Using Autonomous Robotics to Teach Science and Engineering. Communications of the ACM (June 1999). ACM Press
 CWRU Autonomous Robotics
Course. Online. Internet Available.
 Hotline Communications
Ltd. Online. Internet Available.
 K-Team (Khepera Info). Online. Internet Avaliable WWW: http://www.k-team.com/
 Martin, F.M., A Toolkit for Learning: Technology of the MIT LEGO Robot Design Competition.
 MIT 6.270 Autonomous
Robot Design Competition. Online. Internet Available.
 Mondada, F., Franzi , E. and Ienne, P. Mobile Robot Miniaturization: a Tool for Investigation in Control Algorithms, ISER'93, Kyoto, Japan, October (1993).
 NuSpectra Multimedia Inc. Online Internet Available WWW: http://www.nuspectra.com/
 Real.Com. Online. Internet Available WWW: http://www.real.com/
********** End of Document **********
|IMEJ multimedia team member assigned to this paper||Yue-Ling Wong|