Session F4E AN AUTONOMOUS MOBILE ROBOT ... - CiteSeerX

11 downloads 43946 Views 59KB Size Report
Fi), inexpensive flash memory, and machine vision. An open and ... quantum jump to a laptop-size computing system. This is a .... A laptop development platform.
Session F4E AN AUTONOMOUS MOBILE ROBOT DEVELOPMENT PLATFORM FOR TEACHING A GRADUATE LEVEL MECHATRONICS COURSE Dan Hoopes 1 , Tyler Davis 2 , Kelly Norman3 , Richard Helps Abstract – Mechatronics is integration of mechanical systems, electronics and intelligent computer control. With advances in computing power, size, and cost, university mechatronics courses can offer more flexible, powerful and up-to-date development environments than traditionally available with pre-packaged robotics kits such as the widely used Handy Board platform. Goals and constraints of teaching graduate-level mechatronics courses to an educationally diverse class of students are discussed. Goals include identifying the purpose of a mechatronics course, educational background of the students, effects of recent technologies on course subject matter, and ideal development environment to create autonomous robots. Constraints arise because of conflicts between two major aspects of mechatronics, mechanical systems and computer systems, and the need to balance these areas in complexity and ease of use for students of diverse backgrounds. Brigham Young University’s prototype solution of a PC/104 platform with digital I/O and analog inputs running Linux and communicating via 802.11b Wi-Fi is discussed. Index Terms – Autonomous robot, Experiential education, Interdisciplinary integration, Mechatronics, PC/104.

INTRODUCTION Mechatronics “brings together areas of technology involving sensors and measurement systems, drive and actuation systems, analysis of the behavior of systems, control systems, and microprocessor systems” [2]. It is a field where practitioners of many engineering disciplines combine their skills to work on a system. In universities, mechatronics usually involves team-oriented projects [8] often aimed at competitions between autonomous robots [7]. Brigham Young University (BYU) offers a class in mechatronics that requires students to implement mechatronics principles by designing and building smallscale autonomous robots. The students work on the project in interdisciplinary teams and the robots complete a variety of tasks in a final competition.

GOALS The purpose of this research is to improve the teaching of mechatronics by creating a hardware and software

4

development environment that is powerful and flexible enough to allow students to complete significant projects but simple enough to use to allow them to focus on mechatronics principles. In order to reach this goal, four items must be taken into account: • The purpose of a graduate-level mechatronics course • The background of the students • The current state of relevant fields and how that affects course objectives • A suitable development environment (hardware and software) for a mechatronics robot It should be noted that the purpose of this research is not to bring forth groundbreaking developments in technology. Indeed, few items described were created purely in our laboratory. Our development work focused on defining the needs for a graduate level mechatronics course for students of diverse backgrounds and then designing, selecting and implementing a suitable system based on existing technology. The authors have created a prototype robot to meet the identified requirements of a suitable development platform for mechatronics students. The robot development environment may also be called the working environment, or development platform. However, the main purpose of this paper is not to provide a blueprint for other programs to build a robot, but rather to show how the prototype created fulfills the stated goals for a flexible mechatronics robot development environment and enables the teaching of this discipline. Just as the authors have benefited from studying other mechatronics courses, it is intended that other educators in mechatronics can use our design, our reasoning, and our implementation to strengthen their own courses. Details of our system are openly accessible (see Appendix). The Course The goal of the BYU course is to teach students from various educational backgrounds about mechatronics principles by creating an autonomous robot in an experiential learning environment. Students from backgrounds in electronics, mechanical engineering, IT, computer science, and others work together on the project. This requires the working environment to be friendly to

1

Dan Hoopes, Brigham Young University, Information Technology Master’s Degree Candidate, BYU, Provo, UT 84602, [email protected] Tyler Davis, Brigham Young University, Mechanical Engineering Master’s Degree Candidate, BYU, Provo, UT 84602, [email protected] 3 Kelly Norman, Brigham Young University, Information Technology Master’s Degree Candidate, BYU, Provo, UT 84602, [email protected] 4 Richard Helps, Brigham Young University, Information Technology Department Chair, BYU, 265D CTB, Provo, UT 84602, [email protected] 2

0-7803-7961-6/03/$17.00 © 2003 IEEE November 5-8, 2003, Boulder, CO 33 rd ASEE/IEEE Frontiers in Education Conference F4E-17

Session F4E those initially only familiar with his or her own discipline. At the same time, the environment should provide ample opportunity for students to learn enough about any of the other disciplines that the project can be completed and be successful. The integration of various engineering fields is a key problem in the technical workplace today. Classes such as mechatronics can help to bridge gaps between disciplines and foster the cooperation and teamwork that are so needed. In addition to integrating many disciplines, mechatronics provides an opportunity for students to gain critical problem-solving skills. Class work teaches the students cross-disciplinary integrative principles and during lab time, students take part in the learning by hands-on exploration. A goal or competition format is given to the students to complete before the end of the semester. Then, with few restrictions as to how that goal must be accomplished, the students are provided with hardware and software tools to complete the task. Since the project is open-ended, the students can exercise creativity, critical thinking and goal/progress analysis. That the students do these things is a major criterion for a successful mechatronics course at BYU.

there have been many advances in computing power, size and cost that have made it feasible to introduce more computing power and flexibility to the course. The reason the authors began this research was to realize this introduction of greater computing power to a mechatronics course in a way that would still allow for the ease of use and robustness of prior years. New technologies have become standards and are shaping the technology world. A mechatronics teaching environment that implicitly includes some of these technologies while leaving ample flexibility to include still others provides students with an unique opportunity to explore the capabilities of the latest technology in a working system. Some of these new technologies include operating systems such as Linux, 802.11x wireless networking (WiFi), inexpensive flash memory, and machine vision. An open and flexible development platform will ensure that students can include still other technologies yet unidentified. The Development Environment

This class is targeted at students in mechanical, electronic and IT majors. This diversity between mechanically and computer-oriented students is both a challenge and one of the strengths of the course. Because the backgrounds of students will vary a great deal, care must be taken in the material and skills expected to be learned. The most effective learning environment will foster teamwork and a free flow of ideas and knowledge between team members. Because the team members must all work on the same physical project, there must be interaction and integration of disciplines. The degree to which this integration is successful and the degree to which it leads to a successful completion of the task or goal depends largely on the tools and working environment provided to the students.

Since this graduate course is limited to a single semester, students need to be able to reasonably design and build the autonomous robot in the allotted time. This creates the necessity for a substantial groundwork to be laid before the semester even starts. Indeed, if there are to be multiple robots competing against each other, there must be a standard, at some level, upon which they are all based. This creates equality among competing teams and also lays groundwork so that students can progress at a realistic pace throughout the semester without the struggles of overcoming many of the hurdles that beset creators of prototypes (such as writing drivers, purchasing important components, and making over-arching development decisions). Additionally, the authors chose to base the project on autonomous robots rather than remote control. The authors determined this would help students focus on mechanical and computational tradeoffs without the luxury of unlimited (desktop) computing power and storage capacity.

Current Mechatronics Technology

CONSTRAINTS

Students’ Educational Background

Since mechatronics seeks to integrate several fields of study, it by nature prepares students for the workplace. In addition to teamwork, mechatronics projects provide a good opportunity for students to learn how to apply the latest technologies in a useful way. According to Moore’s Law, we have seen and will continue to see a dramatic increase in the speed of computers and a correlating decrease in the size and cost of the computers. Therefore, hardware and software used in previous years may not provide the optimal environment for mechatronics robot development. Such is the case in the mechatronics course offered at Brigham Young University. In prior years, an 8-bit all-in one control platform was used called the “Handy Board” [7]. For several years, this represented the cutting edge of technology, was widely used [1] and met the requirements of an effective mechatronics course. However, in recent years

The cooperation of team members from two basic fields is needed to complete a mechatronics project. First, there is the mechanics of the working robot. This determines what moves and manipulates. Second, there is the intelligence or computation behind the movement. This interprets inputs from sensors etc. and makes decisions for outputs to actuators. The intelligence and computation side includes the electronics and sensors. Thus, the constraints can be summarized as the conflict between the: • Goals of mechanical systems development • Goals of computer systems development Mechanical Versus Computer System Development While the goals within each of the two sides of mechatronics development conflict with each other, so also do the overall

0-7803-7961-6/03/$17.00 © 2003 IEEE November 5-8, 2003, Boulder, CO 33 rd ASEE/IEEE Frontiers in Education Conference F4E-18

Session F4E goals of mechanical and computer system development. The reason is that some things that are easy to accomplish mechanically are relatively difficult to interpret and process computationally. Similarly, some things that may be easy to interpret and process computationally are inherently difficult to actuate mechanically. This is a key part of mechatronics education. These conflicts make the selection and configuration of hardware and software more difficult than if the project were only mechanical or computational. The authors address this problem by planning on giving students a pre-packaged development kit, enabling them to focus on integration rather than fundamental development details.

development platform should be powerful and capable enough to perform the required tasks. The last consideration is that the mechanical paradigms and ideas should be accessible to non-mechanical engineering students. The goal here is that open communication and discussion can take place between mechanical engineers and nonmechanical engineers about the mechanical decisions. As in any production, the fulfilling of all of the above goals to the highest degree is impossible. Necessarily, the goals of power, being up to date with the latest technologies, flexibility, size, ease of use and low cost will conflict with each other to some extent. However, a solution is possible without excessive compromise.

Mechanical Development Environment

Computer System Development Environment

Within the mechanical area, there is the desire to provide a flexible platform to handle diverse and numerous actuators. Actuators might include motors, servos, object manipulation implements, and drive systems. Mechanical system designers should also be provided with the ability to include current and emerging mechanical technologies. The platform should be flexible enough to allow for creativity in solving the problems associated with the given task or game. The platform should be on a size scale appropriate for the chosen workspace or playing space for the robots. If the space is outdoors, there is little need to specify size requirements to a high degree. If the robots will be used indoors and allow for the simultaneous participation of multiple robots (as in a competition format), then the robot size in necessarily decided by the workspace or playing space provided. For a graduate level course, the size of the space may be an open part of a typical university laboratory. This brings the scale of the playing space to something on the order of about 10 by 10 feet. At the same time, this constricts the size of the robots to something on the order of about 1 foot by 1 foot by .5 foot. These numbers are approximations only, but are helpful in determining the scale for the robots being discussed and in making critical initial development environment decisions. Primarily, these approximations led the authors to use some kind of small, embedded system, rather than make the quantum jump to a laptop-size computing system. This is a quantum jump of considerable proportions because mechanically, the robot begins to make requirements on battery power to move the robot that bring its physical dimension far above those mentioned above. We estimated that such a “laptop-powered” robot would be about 2 feet by 2 feet by 1 foot or more. This size and the accompanying weight specified by the battery power and motors needed to move such a robot would preclude the ability of multiple robots participating simultaneously in a space not filling the majority of a typical university laboratory. In addition, the mechanical systems should not be too costly for a university seeking to implement a mechatronics course and offer a class of students materials to build 5 or perhaps even 10 robots in a semester. Next, the mechanical

The constraints presented by the intelligence or computational side of the development are nearly analogous to the constraints discussed above with respect to the mechanical aspects of the robot development. As with the mechanical side, flexibility is important so that students can have the freedom to include any software components they might find. In addition to the ability to add components, the students should also be able to reconfigure the softwareworking environment (the operating system). This allows a level of customization that allows greater creativity in problem solving. Next, the software development environment should allow the use of current technologies and the latest operating system versions. In addition, the computer system should have the ability to interface peripherals based on currently accepted industry standards. Examples include the ability to connect peripherals with USB, PCMCIA, or the ability to connect to a network wirelessly, as with 802.11x (Wi-Fi). Because data storage is a function of cost, capacity and size, the amount of data the robot is required to hold is an important issue. If the robot will need to hold large amounts of data, such as a full installation of an operating system (about 500 MB or more) then flash memory cannot reasonably be used and some kind of spinning media is required, such as a small hard drive. However, if the robot computer requires considerably less storage space (as with typical embedded systems) then the capacity requirements would be less (usually 100 MB or less). At these sizes, solid-state storage media is economically feasible because of its current low price (about $.25 per MB) and pervasive use in industry. Power is a key issue in computing in that the processor should have the ability to keep up with any software or hardware requirements listed above. If students seek to run software easily obtainable in the public domain (initially written for desktop systems) then the embedded system on the robot should have a CPU of the same basic architecture as that available to desktop users. This is not to say that the robot needs to have the latest speed rated in GHz found in stores currently, but rather that the development, compiling and execution procedures are the same as with

0-7803-7961-6/03/$17.00 © 2003 IEEE November 5-8, 2003, Boulder, CO 33 rd ASEE/IEEE Frontiers in Education Conference F4E-19

Session F4E Servo controller board H-bridges

PC/104 power supply board

Computer Hardware

802.11b card

CMUcam 8 sub-c cell battery pack (under main board)

Main board

Flash disk

These applications typically include DC motors, servos, gears, wheels, cantilever beams, and belt drives for example.

Plexiglas chassis

(on cameracontrolled servo

FIGURE 1 BYU PROTOTYPE ROBOT DEVELOPMENT P LATFORM WITH CHASSIS.

desktop systems. This means the computer architecture must be on the same bit-level (currently 32-bit as opposed to the 8-bit Handy Board). Paralleling the mechanical aspects, computational paradigms and methods should be accessible to the noncomputer specialist team-members. This is necessary so that mechanically feasible ideas are kept in line with the ability to interpret, process and control the information obtained from devices. Analogously, while the goals within the mechanical aspects of development conflict with each other, so to do the goals within the computer system development. That is, it is impossible to obtain a computer system that fulfills all of the requirements of low cost, small size, high power, high flexibility, most current, and high accessibility to noncomputer specialists at once. Therefore, the tradeoffs between the fulfilling of these goals must be considered a constraint on the research.

BYU’S SOLUTION After establishing the above goals and constraints, the authors set out to create a prototype robot development platform (Figure 1) that would fulfill the goals to highest degree while remaining within the stated constraints. Greater attention is given here to the computational side of development. The reason for this is that if appropriate attention is given to the computational side so that it is both powerful and flexible, then the mechanical constraints are greatly lessened. Since the mechanical applications typically employed by students in mechatronics courses are relatively simple when compared to the state of the art in mechanical systems, an effective computational system will be able to handle most mechanical requirements students will attempt to use.

The computer hardware chosen will be discussed first because it affects many of the software decisions to be made later. This is because the constraints of size, power and cost limit the abilities of computation. Since software is typically written to make full use of the available computing power, the computing power is a limiter. The traditional Handy Board was not used because it necessarily constrains users to proprietary hardware and software in an effort to create an easy to use platform for rapid project completion. A laptop development platform was not chosen for size issues stated above. Because size, weight, cost, interchangeability, and consistency are major factors in hardware choice, the PC/104 platform was chosen. The PC/104 standard, a commonly -used robotic development platform [9,12], specifies a main board of approximately 4 by 4 inches that houses a processor, memory and the basic chipset needed to function as a standalone embedded computer capable of functioning with only a separate power supply and whatever outside input or output devices the application calls for. The PC/104 standard fulfills the requirements sought after in the above goals section. The makers of PC/104 systems consistently produce new versions of hardware that use current technologies, including a constant increase in processor speed (currently lagging the cutting edge of the PC market by about a year), and connectivity including USB, CAT 5 networking, PCMCIA and 802.11x wireless. Since the PC/104 standard includes a bus made so that expandability is as simple as adding a board to the PC/104 stack, it is flexible. PC/104 units are relatively low cost with prices for main boards in the hundreds of dollars (most around $300 to $500). The 4 by 4 by 1 inch size falls within the 1 by 1 foot by 6 inch size described above, leaving ample space for mechanical components. Our current prototype [3, 13], however, deviates slightly from the dimensions of a typical PC/104 board. The authors are using a board that incorporates a PCMCIA interface as part of the main board (802.11x wireless cards are supported). In addition, the main board houses a compact flash disk, digital I/O and analog inputs. These additions increase the dimensions of the board slightly to 5.0” by 6.7”, which is still within our recommended size. While the dimensions are slightly larger, the mounting holes and PC/104 bus remain standard. The reason for this choice is that the first PC/104 board [5] the authors attempted to use required numerous additional boards and components in the PC/104 stack to complete the system. Although the previous main board maintains the PC/104 standard size, an additional card was needed to accept a PCMCIA 802.11b wireless card. In addition, since this board did not have sufficient on-board memory, a separate laptop hard drive was used to store the

0-7803-7961-6/03/$17.00 © 2003 IEEE November 5-8, 2003, Boulder, CO 33 rd ASEE/IEEE Frontiers in Education Conference F4E-20

Session F4E operating system and data. Further, a VGA card [5] was required in the operating system installation stage because of lack of human interface options. All of these items added to the size, cost, and power consumption of the system and made the resulting stack unsuitable for further development and was therefore abandoned. The authors placed particular importance on achieving a wireless development link between the robot and the desktop development system. This maximizes convenience and flexibility for the students. Wireless allows the developers to write and edit code off-robot and transmit and run the code on-robot easily. In addition, the developer can see realtime debugging information on the desktop development station while the robot is attempting a task. As noted above, the PC/104 board chosen comes with on-board digital I/O and analog inputs. This allows sensors, transducers and actuators to be connected directly to the main board. The other option of attaching a PC/104 daughter board with the necessary digital and analog ports was not pursued because of the added size and weight. Both analog and digital I/O were desired for the prototype because of different strengths. First, analog input is used for variable voltage-level inputs where an on-board analog to digital converter creates information interpretable by the software. Numerous digital ports were desired because they can function in both the input and output modes. In addition, there are separate components designed to work with digital I/O to facilitate robot functionality. One such component is the H-bridge. The digital H-bridge allows a digital pulse width modulation (PWM) signal to control DC motors driven with a separate power supply. The PC/104 board chosen also includes three serial communication ports. Because the serial port is easily and cheaply interfaced, robot-specific peripherals are common enough to make their use economically feasible. For example, for about $20, a chip using one serial port was obtained to control up to 5 servos simultaneously. [6] In addition to these transducers and actuators, the prototype includes the ability to use machine vision. Traditional mechatronics robot projects, including the Handy Board use line following as a navigational technique. Since the new prototype has increased processing power and connectivity, machine vision can be used. Line following as the sole method of navigation was not used because it is less applicable to real-world applications where contrasting, reflective lines are not always available to an autonomous robot. Carnegie -Mellon University (CMU) created a serialinterface camera (see Appendix) made especially for robotic applications. This camera provides a command line and Ccode accessible color-tracking system. The prototype uses this camera, which is available for around $100 with software available for most common operating systems.

custom functionality, Linux was chosen. Linux is a common choice for robot development and has already been used in competitions such as robot soccer [10] and others [4]. While DOS is another easily configurable operating system, there is less software available to interface with it than with Linux in robotics applications. In addition, a Windows environment was not chosen because of the strain placed on available memory and processing power and the relative difficulty, compared to Linux, in “hacking” the operating system for custom functionality. As a programming language, C/C++ were chosen because of their widespread use in Linux and their accessibility to students. Java and other object-oriented languages were not chosen in order to keep the programming as easily understood as possible so that those with noncomputer backgrounds can understand and participate in the software development as much as possible. Since C/C++ code is a commonly used language, students will often be able to find solutions to coding problems by searching the Web for public domain software. In order to simplify further the tasks of students, the authors have created a standard code library to interface the most commonly used and most basic functions needed to operate a mechatronics robot. Source code and API’s for functions such as servo control, PWM DC motor control, CMU’s color camera input and simple analog input and digital I/O were written and provided for incoming students (see Appendix). Certain development cycle decisions were made to allow for the simplest and quickest method of writing, compiling, running and debugging code. The prototype uses the standard Telnet communication for command-line control & monitoring and FTP for file transfer between desktop and robot. SSH (Secure SHell) and SCP (Secure CoPy) were not used because the PC/104 board used came pre-configured with the ability to use the other command line and file transfer protocols listed above. A complete listing of hardware and software components used in the prototype is found in the Appendix.

Computer Software

BYU’s solution to the problem of creating an effective mechatronics teaching platform has met all of the identified goals while maintaining within the stated constraints. Students will be able to develop powerful autonomous

Because mechatronics projects require “hacking” into the functionality of the operating system and software to create

FUTURE WORK The prototype can complete actions needed to demonstrate the flexibility needed. However, in order to lay as much groundwork as possible against which future students can leverage, the authors will make the software components easier to interface. Simplicity in the interface is the most important aspect because it allows students to focus on creative applications of the basic functionality and allows time to focus on mechanical solutions to various problems.

CONCLUSION

0-7803-7961-6/03/$17.00 © 2003 IEEE November 5-8, 2003, Boulder, CO 33 rd ASEE/IEEE Frontiers in Education Conference F4E-21

Session F4E robots from building blocks provided by the authors unless additional goals or constraints are discovered. The development environment should provide accessibility to students of various technical backgrounds to come together to complete a project, thereby increasing their skills and learning to work effectively in a cross-disciplinary environment.

• • •

APPENDIX Complete documentation including pictures, source code, specifications, and component drawings can be found on the BYU Mechatronics web page. [3] The following hardware components make up the prototype (current prices listed at time of submission as a reference only): • Technologic Systems [13] model TS-5500 Single Board Computer (SBC), specs: AMD Elan SC520 SBC, 32MB RAM, PCMCIA Type II, 2MB Flash, 10/100 Ethernet, with the following options: (1) purchased as the “Kit” to include cables, wall power supply, 32 MB flash card, and a USB flash card reader for the host PC: $459. (2) Linux supported 802.11b wireless card approved for use in TS-5500: $69. (3) Configuration for Linux: $6. (4) 64 MB on board RAM: $35. (5) 8 channel 12-bit A/D converter on board: $35. • New Micros (newmicros.com) model NMIH-0010 Hbridge, contains 4 half-bridges: $20. • Ferret Tronics [6] model FT 639 servo controller package, controls up to 5 RC-type servos: $19.75. • Diamond Systems model Jupiter-MM -LP 25 Watt LowCost DC/DC Power Supply, input between 7 and 30 VDC and uses PC/104 bus to supply power: $115. • Carnegie Mellon University model CMUcam Vision Sensor, includes camera, software and cable, available from Acroname.com: $109. see also www2.cs.cmu.edu/~cmucam/ for specifications. • LCD screen for debugging connects to LCD interface on TS-5500 SBC: $8. • 8 sub-c cell hobby rechargeable battery pack, made from NiMH cells: $40 • MRC model “Super Brain” sub-c cell battery charger, moderately priced hobby charger with 8-cell capacity whereas most inexpensive chargers handle only up to 7 cells: $45. • BYU custom machined add-on board to neatly contain servo controller board, H-bridges, power and ground screw terminal strips and a momentary switch button: Gerber file available from BYU Mechatronics web page [3]. Total cost of base unit hardware: $ 960.75 ($920.75 per robot excluding charger) The following major software components run the prototype:

• •

TS-5500 single board computer comes with an installation of Mandrake Linux that fits on the 32 MB flash disk (price above). LCDproc, a freeware Linux LCD interface. Mandrake Linux 9.0 or Red Hat 7.3 on desktop system (free downloads). Versions 9.1 of Mandrake or all later versions of Red Hat are not used because they use newer libraries than the TS-5500 and compiled executables are not viable for use without special commands during compiling. BYU custom pulse width modulation code made to interface the digital ports on the TS-5500 with the NMIH-0010 H-bridges [3]. Minicom, freeware program to interface the CMUcam.

REFERENCES [1]

Avanzato, R., J. Chan, M. DeMeglio, “Penn State Abington firefighting mobile robot” ASEE Annual Conference Proceedings, 1998, 4pp

[2]

Bolton, W. Mechatronics: Electronic control systems in mechanical and electrical engineering, New York: Addison Wesley Longman, 1999.

[3]

BYU Mechatronics Reference Material – IT 548. 2003. Brigham Young University. 14 May 2003. http://class.et.byu.edu/it548/source_ref.htm

[4]

Collins, T.R., T.R. Balch, “Teaming up : Georgia Tech's multi- robot competition teams” Proceedings of the National Conference on Artificial Intelligence, 1997, p 785-786.

[5]

Diamond Systems PC/104 VGA board. 2003. Diamond Systems. 24 March 2003. http://www.diamondsystems.com/products/promdevkit

[6]

FerretTronics Servo controller chip. 2003. FerretTronics. 28 Feb. 2003. http://www.ferrettronics.com/product639.shtml

[7]

Flint, J., S. Cheney, B. Hale, C.R.G. Helps, “Analysis of Competitions for Mechatronics Design Using Autonomous Mobile Robots”, Proceedings of the 2003 American Society for Engineering Education Annual Conference & Exposition, 2003, Session 1476.

[8]

Handy Board, The. 2003. Handy Board. 20 Jan. 2003. http://www.handyboard.com/

[9]

Krishnan, M., S. Das, and S.A. Yost, “Team-oriented, project-based instruction in a new mechatronics course”, Proceedings of IEEE Computer Society Conference on Frontiers in Education, Champaign, IL, USA, 1999, Stripes Publishing L.L.C., p. 13D4/1-6 vol.3.

[10] Miller, C.E. “Modular robotic vehicle control system using the DeviceNet Controller Area Network”, Proceedings of the ASCE Specialty Conference on Robotics for Challenging Environments, 1998, p 154-160. [11] Nakamura, T., J. Morimoto, K. Terada, H. Adachi, A. Shibata, H. Takeda, “Development of a cheap on-board vision mobile robot for robotic soccer research”, IEEE International Conference on Intelligent Robots and Systems, v 1, Innovations in Theory, Practice and Applications, 1998, p 431-436. [12] Sukhatme, G.S., J.F. Montgomery, M.J. Mataric, “Design and implementation of a mechanically heterogeneous robot group”, Proceedings of SPIE - The International Society for Optical Engineering, v 3839, 1999, p 122-133. [13] TS-5500 Specifications. 2003. Technologic Systems. 18 March 2003. http://embeddedx86.com/epc/ts5500-spec.php

0-7803-7961-6/03/$17.00 © 2003 IEEE November 5-8, 2003, Boulder, CO 33 rd ASEE/IEEE Frontiers in Education Conference F4E-22