Increasing Accessibility To A First Year Engineering Course In Mobile Autonomous Robotics

Introductory classes in the design and programming of mobile autonomous robots offer both potential and matriculated engineering students entertaining and engaging educational experiences that give them early experience with the kinds of open ended design problems they will face in their professional careers. By their nature, however, these classes often require some prior computer programming experience – which raises the threshold of entry to the very early career students who might most benefit from the extra motivation and depth provided by dealing with open-ended problems. In previous work we discussed minimizing dollar cost and maximizing physical access to a robot by creating a WWW/web cam based infrastructure and supporting open sourced robot simulation software. In this work, we will focus on additional work that addresses more fundamental pedagogical issues including ease of collaboration among geographically dispersed students and the design of educational materials more suitable for maintaining low threshold, high ceiling educational experiences for the students. 1. Previous Work –WWW Autonomous Robotics Formal knowledge based classroom instruction is necessary for the education of engineers. However, it also requires practicum components in which students can experience both the joys and frustrations of actual design, implementation, and testing in an environment rich with possibilities and with the guidance of experienced mentors. Generally, design practica occur toward the end of a student’s undergraduate career. This is for good reason – many interesting problems require mastery of a significant body of knowledge to be approachable. On the other hand, many students receive enormous benefit from engaging in these design practica early in their undergraduate years. Not only do they get an early look at what real engineers do early on, they also are shown quite clearly why all the knowledge presented in the other courses is so valuable in practice. Many students who might otherwise drop out of, or never enter, P ge 10749.1 Proceedings of the 2005 American Society for Engineering Education Annual Conference and Exposition Copyright © 2005, American Society for Engineering Education engineering programs can thus be motivated to not just stay – but seriously apply themselves – in their traditional classes. In previous work [1 3], we addressed issues related to offering an autonomous robotics course over the World Wide Web (WWW). By constructing a centralized environment containing a web connected mobile robot and providing 24/7 access to it via the Internet, we were able to leverage a single, expensive, robot to serve the needs of geographically dispersed students. By providing an open sourced Java based robot simulation environment, we were able to relieve potential bottlenecks caused by many students testing early versions of their robot controllers on a single robot. Also, we were able to provide these simulators, which run on nearly any modern microcomputer, free of charge. This further relaxed financial burdens in running the course and increased access to many under represented demographics. Most of our past work has focused on the technical nuts and bolts of getting the system running reliably and in maintaining sufficient fidelity between the simulation code and the actual robot. The point then was to increase physical access to facilities to many demographics that otherwise not be able to participate. In this paper, we will focus more on subsequent efforts to tune the pedagogy of the course material to lower the knowledge threshold of entry into the course and to increase access to early program undergraduates and advanced high school students. The paper will begin with a brief description of the course, the attendant infrastructure as it existed, and a few items that were less than well handled. It will then discuss specific changes that have been made to that infrastructure to deal with those issues and better support our proposed pedagogy. Following will be a discussion of specific educational materials developed to lower the knowledge threshold for participation. The paper will conclude with a brief discussion of future plans and open issues. 2. Previous Work – Access Issues In our original class, students developed robot controllers to solve a series of increasingly difficult problems on a mobile robot simulator that we designed and implemented using Java. When finished, they upload their controllers to a real robot in our lab and observed the results via a WWW web cam. Students kept an engineering journal and were graded on the quality of their design/implement/test processes. Except for the remote and geographically distributed nature of the course, it was not in principle much different from more traditional robotics practica offered in person [4 7]. Though careful study of the differences between the two methods of offering the material is still underway, two issues with the online environment quickly became apparent. The first was that the activation energy just for a student to get his/her personal environment set up was so high that actual interesting work was delayed far too long. In traditional offerings, a TA or instructor can pre-configure machines and infrastructure so that a student can get to the meat of the study problems immediately. In a distributed and/or online environment – such support is not generally available as students are generally far removed from the instructor. Though our software was fairly easy to install for the experienced student, many in demographics of interest had difficulty. This can not be ignored. The second issue had to do with quality of Internet mediated student-to-student and mentor-to-student interactions. Generally, students and/or mentors would discuss solutions and tests with one another via standard text chat tools. Most students, perhaps already comfortable with such communication due to the growing ubiquity of cell phone based text messaging, were quite satisfied with that P ge 10749.2 Proceedings of the 2005 American Society for Engineering Education Annual Conference and Exposition Copyright © 2005, American Society for Engineering Education mode of communication. However, students experienced difficulties in textually describing to other parties what their robots were doing in the world. It was possible to upload code to the real robot and have multiple people simultaneously watch its operation. However, this created an undesireabile resource bottleneck. Extensions that allowed collaborative viewing of the robot simulation environment across the Internet were sorely needed. The first issue limited access via a high knowledge barrier. The second issue limited access to collaborative debugging because of a hardware bottleneck. Before considering how these issues were solved, we will briefly describe the basic components of the simulation and remote control robot environment. 3. The Physical Robot and Its Environment The environment we created in our lab consists of a single robot that operates within a 4x4 foot enclosure. The robotic hardware consists of a standard Khepera robot [8, 9] equipped with an auxiliary gripper arm module. Communication with the robot is facilitated through a wire tethered between the robot and a host machine’s serial port. The robot is manipulated using software that writes/reads data to/from the robot via interpreted commands from the user. Within its enclosure, the robot may be confronted with a simple set of obstacles: reconfigurable walls (typically in the form of mazes and/or rooms), lights, and plastic soda pop bottle caps. Wall sections and lights are fastened to the floor of the enclosure, and therefore cannot be moved by the robot. Caps are used specifically as objects to be manipulated by the robot via its gripper attachment. It is this particular environment that is simulated by our software. Due to the environment’s simplicity, the task of developing sensor and actuator models was significantly reduced. The color and reflective properties of the obstacles were specifically chosen so that sensor response would be similar at given distances from an obstacle regardless of its type. These properties along with the constant lighting in our lab provided the basis for the accurate yet efficient models eventually used within the simulator. The software architecture used to interface the hardware with student written controller is described more completely in [3]. Here it is sufficient to note that the students actually program a “virtual robot object” that is tightly Figure 1: An Internet Connected Khepera Robot This snapshot was taken from a WWW browser using the student accessible webcam. Users can pan, zoom, and tilt the camera remotely to get more detailed views as needed.