Copyright. Nicholas Arden Paine

Transcription

1 Copyright by Nicholas Arden Paine 2010

2 The Report Committee for Nicholas Arden Paine Certifies that this is the approved version of the following report: Design and Development of a Modular Robot for Research Use APPROVED BY SUPERVISING COMMITTEE: Supervisor: Sriram Vishwanath Jonathan W. Valvano

3 Design and Development of a Modular Robot for Research Use by Nicholas Arden Paine, B.S. Report Presented to the Faculty of the Graduate School of The University of Texas at Austin in Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering The University of Texas at Austin May 2010

4 Dedication I wish to dedicate this report to my family whose support and encouragement have been a constant source of inspiration.

5 Acknowledgements I would like to thank my Supervisor, Sriram Vishwanath, who saw potential in me and encouraged me to pursue a graduate degree. He has always supported my work and provided me with the opportunity to create something of value. He is an excellent Supervisor and a good friend. I would like to thank Jonathan Valvano whose expertise in embedded systems has made this work possible. His insightful feedback and enthusiasm in robotics have been a constant source of help with this project. I would like to thank Bill Bard whose continued interest in this work has provided both motivation and reassurance. This project would have not succeeded without many consultations from ENS lab tech support staff Paul Landers and Daryl Goodnight. When confronted with a roadblock, they were always able to help me overcome it. I would like to thank the many students who have worked at some point on this project. Proteus was not the product of one person s efforts. In particular I wish to thank Drew Stovall, Seth Gee, and Vidur Bhargava. 5/7/2010 v

6 Abstract Design and Development of a Modular Robot for Research Use Nicholas Arden Paine, M.S.E The University of Texas at Austin, 2010 Supervisor: Sriram Vishwanath This report summarizes the work performed for the design and development of the Proteus research robot. The Proteus design is motivated by the need for a modular, flexible, and usable autonomous robotic platform. To accomplish these goals, a modular hardware architecture coupled with low-power, high-computation processing is presented. The robot is subdivided into three layers: mobility, computation, and application. The interface between layers is characterized by well defined APIs and may be individually replaced to achieve different functionality. An efficient low-level event scheduler is described along with higher-level software algorithms for motion control and navigation. Experiments of Proteus robots are provided including field tests and collaboration with outside research institutions. vi

7 Table of Contents List of Tables... ix List of Figures...x Chapter 1: Introduction...1 Chapter 2: Technical Details...5 Design Methodology...6 Computation...6 Hardware...8 Hardware Implementation...10 Mobility Layer...11 Computation Layer...11 Circuitry...11 Software Implementation...12 Low-Level Event Scheduler...12 X86 to 9S12 Communication Interface...15 Motion Control...17 Chapter 3: Experiments...19 Field Test # Problems Encountered...20 Field Test # Problems Encountered...23 Cooperation with Auburn University...24 vii

8 Chapter 4: Conclusion...25 Appendix A: Proteus hardware as of Fall Appendix B: Microcontroller software organization...27 Appendix C: Initial version 2 computation layer design...28 Appendix D: Proteus PCBs...29 References...33 Vita...34 viii

9 List of Tables Table 1: Proteus embedded system command protocol Table 2: Sensor packet part Table 3: Sensor packet part ix

10 List of Figures Figure 1: Robot from previous group (version 0, Fall 2007) Figure 2: Robot from senior design project (version 1, Spring 2008) Figure 3: Current robot (version 2, Spring 2010) Figure 4: Separation of modular hardware... 9 Figure 5: Scheduler output Figure 6: x86 to 9S12 command protocol Figure 7: 9S12 to x86 command protocol Figure 8: Proteus robot configured for Field Test # Figure 9: Recorded position data of a Proteus robot performing autonomous GPS navigation Figure 10: Recorded position data for wireless throughput test Figure 11: Wireless throughput vs GPS latitude Figure 12: Proteus hardware as of Fall Figure 13: Microcontroller software organization Figure 14: Initial version 2 computation layer design Figure 15: 9S12 Extender PCB schematic Figure 16: 9S12 Extender PCB layout Figure 17: Battery charger PCB schematic Figure 18: Battery charger PCB layout Figure 19: Auxiliary Sense PCB schematic x

11 Figure 20: Auxiliary Sense PCB layout Figure 21: IR Switch PCB schematic Figure 22: IR Switch PCB layout xi

12 Chapter 1: Introduction A common problem in many fields of research today is the lack of rigorous testing and concrete implementations. Often, a researcher will develop a novel algorithm or idea and is only able to validate their research through simulation. Simulation is a valuable first step towards understanding how an algorithm behaves, but it is by no means a thorough, or even accurate, assessment of the characteristics or feasibility of the algorithm. Ideally, these algorithms should be implemented and tested in the real world as they are intended to be used. In doing so, new problems will arise and opportunities for improvement may appear. The challenge in meeting this goal is the difficulty of a) acquiring the diverse set of skills necessary to implement algorithms on real hardware and b) acquiring the resources to do so. This paper describes the design and development of the Proteus robot that was created to alleviate some of these problems. While robots may not be able to help in all scenarios, they may be useful as a distributed mobile platform for research within electrical engineering and computer science. This report provides an overview of the work performed during the past two years from Fall 2008 to Spring Most of this work was spent developing the Proteus robot from an initial rough prototype, improving it through two major iterations and building 38 more Proteus robots. Both the software and hardware of the Proteus robot have seen major overhauls, including support for the Player API and a shift to a modular hardware design. The robot has matured from a simple class project to a useful research platform. I also helped start the Pharos lab and have been mentoring several undergraduate students in association with the lab. There have been at least five class projects based on Proteus robots and there are more preparing to use them in the future. The Pharos lab has held two major field tests of algorithms running on multiple Proteus 1

13 robots, each showing promising results. I also helped facilitate a collaborative program with Auburn University where we sent six Proteus robots to Auburn for research use. This paper will describe this work in further detail and draw comparisons with other similar projects outside of UT. This paper refers to three major revisions of the Proteus robot. Figure 1 shows the robot before work on this project began. This version of the robot will be referred to as version 0. Figure 2 shows the robot one semester was spent redesigning it (version 1). Finally, Figure 3 shows the robot in its current state (version 2). Figure 1: Robot from previous group (version 0, Fall 2007). 2

14 Figure 2: Robot from senior design project (version 1, Spring 2008). Figure 3: Current robot (version 2, Spring 2010). 3

15 Similar robots to Proteus have been developed in the past. irobot[1] sells an educational version of its Roomba but is confined to indoor operation and low speeds. Another popular robot for research has been the Pioneer robot sold by Mobile Robots [2], which is larger and heavier than Proteus. Segway offers an array of mobile robot bases [3] but are relatively high cost. [4][5] and [6] are three other sources that specialize in smaller robots with limited mobility capability for research use. [7] takes a different approach and sells a robot that is simply a mobile stand on which to put a computer laptop. Most of the hardware on each these platforms is fixed and only a few are open source. Proteus offers more control over low-level system performance, is lightweight, includes an onboard x86 computer, and can perform well outdoors and indoors. The rest of this paper is organized as follows. Chapter 2 describes the technical details of the robot, starting with a discussion of design choices made in designing the Proteus robot and finishing with implementation details of both hardware and software. Chapter 3 briefly describes some of the experiments conducted using Proteus robots. Chapter 4 discusses future work to be done with Proteus and concludes the report. 4

16 Chapter 2: Technical Details The starting point for this work was the original Proteus prototype, which was the product of my undergraduate senior design project. The senior design project was commissioned by Dr. Sriram Vishwanath with the hope of creating a useful robot for wireless networking research scenarios. The same project had been pursued previous semesters by other groups, but there seemed to be several recurring issues with these designs. a) The end product was consistently crude in construction and usability. b) The main processor was a Freescale microcontroller which requires a proprietary development environment to program. c) There were at least three different power sources on the robot. As can be seen in Figure 1, little attempt was made to produce a long-lasting, robust design. Also visible is the numerous battery chargers attached to the many onboard power sources, making routine operation tedious and difficult. Our group focused on improving these three problematic areas using several key strategies. First, we moved all of the electronic components onto an aluminum plate, which would be mounted on top of the car chassis. This mounting scheme solved many of the mechanical issues encountered by the version 0 design. With components loosely dangling on a mobile platform, bumps and vibrations from the platform moving can cause connections to come loose. These free-hanging wires create a debugging nightmare and can potentially damage or destroy components. Our second key strategy was building the robot control system around an x86-based processor. The x86 processor is a very common processor with many operating systems and programs written for it. Most users would be much more accustomed to such a system. The product of the senior design project (version 1) was a robot that contained many of the same components as the current robot (version 2). Appendix A shows a 5

17 block diagram of Proteus version 1. Version 1 is built around the same x86 motherboard, and uses the same M3-ATX power supply as version 2. The major difference shown in the block diagram is the PIC Microcontroller, which was simply used to control the steering servo on the R/C car. Version 2 of the robot uses a programmable Freescale microcontroller to perform this operation along with much more functionality. For additional details on technical information pertaining to Proteus refer to the subversion repository [8] with credentials anon/anon. DESIGN METHODOLOGY The design of Proteus differs from many other robots due to its goal of flexibility and usability as compared to specialization at all costs. Much of the design comes in the form of improvements on features found previous revisions of the robot. This section focuses on design choices made in three areas of the robot. Computation The motivation for the some of the design choices made for the Proteus robot stemmed from a desire to ease the time overhead and learning curve required for a simple robotic platform. Many robotic platforms we had worked with required an archaic, proprietary interface for interacting with the robot. The reason for this is that small mobile robots are primarily constrained by power limitations. A robot has many parts that require power. Devices used for movement and sensing take up most of the power budget. For example, consider a remote controlled car. This is a machine with only movement, yet most commercially available remote controlled cars have a relatively short battery life. Adding sensors and a computer only reduces this time further. Without this small power envelope, designers are constricted in terms of sensing and computation power consumption. For this reason, sophisticated sensors and 6

18 computers are primarily found on large robots that can afford to carry a substantial power supply. On the other hand, small autonomous robots usually settle for low power computers. The lowest power computers available are microcontrollers. Microcontrollers require a good deal of engineering background to write software for, and use archaic, proprietary interfaces to program. Creating a small robot with long battery life and a common development environment seems like a difficult proposition. The solution to this problem lies in intelligent hardware design. An easy to use computer had to be something that would run a familiar operating system, such as Windows or Linux. Such operating systems are most commonly found on computers with an x86 processor. By using a low-power x86-based computer running Ubuntu Linux, many of the usability issues found on the version 0 design of the robot were avoided. One difficulty associated with using x86-based computers on a small platform is that commonly rely on the ATX form factor for power delivery. The ATX form factor uses a complex power interface that is usually achieved through the use of a large ATX power supply. Clearly a typical ATX power supply would not fit on a small robot. Also, ATX power supplies are powered from A/C power from the wall, which would also not be present on a small robot. To remedy this problem a vendor was found that offered small ATX power supplies that operated using D/C power as an input. This power supply allowed the delivery of power to the x86 board while retaining a compact design. A purely x86-based robot design does have drawbacks. Most x86 motherboards rely on standardized input/output (I/O) to communicate with peripherals. While it bolsters the robot's ease of use, this standardized I/O is difficult to interface to at a lower level. You cannot directly control a motor through USB. To do so, one would either have to design a separate system that converted USB packets into motor control signals. 7

19 Such a system would accomplish this through the use of a microcontroller. As we stated earlier, microcontrollers are generally less user-friendly than x86 computers. However, microcontrollers are essential for use in controlling low level signals, such as those used to control a robot. Because of this necessity, we included a programmable Freescale microcontroller in our design. The University of Texas Electrical Engineering department teaches students about embedded systems concepts on one system in particular, Freescale s 9S12. This microcontroller was selected primarily because it would be familiar to students at the University and would allow them to work in a familiar environment. It is fully capable of performing the tasks needed by the robot. Hardware The Proteus version 1 design aimed to simplify mechanical design by mounting all electronic components on a horizontal plate. Such a design occupied little vertical space and was application-specific. For example, sensors could be mounted for obstacle avoidance but if obstacle avoidance is not needed the space where the sensors mounted would go unused. For a robot that needs to be flexible, it did not make sense to continue using this hardware mounting scheme. For version 2, a modular design was implemented that would allow the user to configure the robot for a wide and potentially unknown array of applications. To do this, a design based on horizontal layers was chosen that provided stackable, packaged functionality (Figure 4). For example, the computation layer houses all core computing facilities but does not contain sensing or actuation elements. The computation layer provides minimum functionality needed for basic use, and can be built upon for more demanding applications. 8

20 Figure 4: Separation of modular hardware All mobile robots can be logically partitioned into subsections similar to those depicted in Figure 4. However, on other robots they are typically not physically separated as they are on Proteus. Conventionally mobile robots are designed for a single task or purpose. Once robotic components are assembled in a satisfactory manor such that they accomplish this task, there is no need to realize where these logical divisions lie. Because we are not designing a robot for one application, it is useful to maintain these boundaries. Achieving a modular design does present some challenges. First, modularity comes at the cost of spatial efficiency. A compact design is important, especially when mobility outdoors over rough terrain desired. A high center of gravity will cause a platform to become unstable and possibly flip over. We have addressed this constraint by making each layer as thin as reasonably possible. Secondly, a non-modular design simplifies the power distribution architecture. One solution to this issue is separate power supplies. The computation layer includes a battery so that its power is not dependant on what mobility base is currently being used. This feature also allows functionality without a mobility base, further simplifying the system if no mobility is 9

21 required. Additional advantages come in the form of system stability and repeatability. With complete decoupling from the electrically noisy power used by motors, delicate computer electronics are less likely to behave erratically. Because of limited fabrication capabilities, the design also needed to be easy to build. As a side effect, a design that is simple to fabricate can easily reduce the overall cost of the robot by decreasing both material usage and labor costs. Proteus version 2 reflects the ease-of-fabrication constraint very clearly. Layers are constructed from a single sheet of aluminum with an array of circular holes used for mounting components. Such a design is simple enough to enable replication of the robot by anyone with a hardware background. HARDWARE IMPLEMENTATION In addition to creating a robot that would work well for common use scenarios, it was important to retain fine-grain access to lower level functionality on the robot. As will be discussed in the Software Implementation section, Player[9] is used to simplify programming for the Proteus robot. Player is the most widely used robotic interface framework. It provides both software Application Programming Interfaces (APIs) and a network-socket-based communication framework. These two features alone make Player extremely useful to use. A Player-controlled robot primarily appeals to those working with high-level robot concepts such as algorithms. The user wants something that is simple and easy to use. There is another class of users who are interested in understanding how lower level tasks are accomplished, how circuits are built, and how the robot is controlled. It is a challenge to create one robot that works well for both class of users. 10

22 Mobility Layer To address the usability and transparency problem, and to allow reconfigurability, Proteus can use three different mobility platforms: a Segway, a Roomba, and a Traxxas car. Each of the three excels in particular mobility scenarios. The Roomba is a small, light-weight differentially-driven robot. It works well for slow speed indoor mobility. Both the Segway and the Traxxas car may be operated indoors or outdoors. The Segway is differentially-driven and heavy while the Traxxas uses Ackerman-steering and is relatively light-weight. The Roomba and Segway are directly supported by Player and work without the need for an externally programmable microcontroller. The Traxxas base, however, is a modified R/C car and is a completely custom platform. If the Traxxas base is to be used, a custom Player driver must be used. This Player driver communicates with the onboard microcontroller to control the Traxxas base. All three mobility platforms may be used with Player, but the Traxxas base provides the user the ability to directly change the low level software interfaces and controls. Computation Layer The computation layer is the central hub of the Proteus design and therefore has been the focus of much of the mechanical design. Version 1 used an oversized and crude aluminum sheet to house all of the components. One goal for version 2 was to minimize the area this plate used while retaining usability. Usability in this case can be defined to be a function of I/O accessibility, wire routing, and overall complexity. The initial design for the computation layer on version 2 can be found in Appendix C. Circuitry Not all of the components on the Proteus robot are commercial off-the-shelf (COTS) components that can be purchased and connected together easily. To create a 11

23 small and efficient design several circuits were implemented using custom printed circuit boards (PCBs). PCBs are necessary for reliability, repeatability, and fabrication reasons. PCBs are robust and tolerate vibration well. They can also be produced in large quantities relatively, easily which was crucial in the construction of a large number of robots. The PCBs have typically been simple two layer boards used for hardware interfacing. Schematics along with board layout can be found in Appendix D. Figures 15 and 16 show the 9S12 extender board, which puts minimal functionality for Traxxas base use onto the pins of the 9S12. Figures 17 and 18 show the battery charger board which provides battery charging without disconnecting the system load from the onboard battery. Figures 19 and 20 show the auxiliary sense board, which interfaces an array of different sensors to the 9S12 extender board. Figures 21 and 22 shows the IR switch board, which combines analog inputs from two infrared sensors, providing one analog output to the microcontroller. SOFTWARE IMPLEMENTATION Proteus robots allow access to many levels of software for development. Programming of Proteus robots has been conducted from the bottom up, first solidifying low level control and then building abstraction on top of these drivers. This section follows the same bottom-up structure, summarizing each level s contributions and touching on key software elements. Low-Level Event Scheduler The microcontroller is responsible for a) performing the real-time tasks associated with controlling the robot and b) providing an interface for control from the x86 board. Since the 9S12 has a single processor, it may only perform one action at a time. There is an inherent delay associated with performing multiple tasks and switching between them. 12

24 Therefore, it was important to carefully architect a scheduling system that would effectively manage switching between tasks. Appendix B shows six concurrent tasks that must run on the microcontroller, all of which are very sensitive to timing. Jitter on any of the tasks may cause data corruption or potentially data loss. The 9S12 is a processor with non-hierarchical interrupts. That is, interrupts may supersede foreground tasks, but another interrupt may not supersede an active interrupt. This means that the more time spent running background tasks, the higher the chance for jitter on high priority interrupts such as serial data latching, pulse width measurement, and control loops. There are many scheduling mechanisms for operating systems that handle multiple tasks that constantly compete for computing resources. These mechanisms would not work well for the Proteus embedded system however. The Proteus embedded system is characterized by multiple periodic events with relatively low computation needs and high timing sensitivity. A simple round robin scheduler would not be sufficient because of the high timing delay possible between events needing to be serviced and when they are serviced. The expected delay is one half of a full round robin period. A preemptive scheduler is much better in terms of timing delay, but is bulky and works best with a hierarchical priority system. A simple scheduler was created that was built for periodic events on the 9S12 architecture. With the scheduler the programmer may specify a number of periodic events, and the scheduler will map the periodic events into a time-continuous space. These events are then executed with minimum possible overhead. The scheduler is equivalent to using functions called from periodic hardware output compare interrupts except that the scheduler only uses one output compare interrupt. Additionally, since the 9S12 is a 16-bit processor, if a programmer wanted to achieve 32-bit resolution for periodic tasks they would typically rely on the timer overflow interrupt handler to 13

25 achieve this. The scheduler is built for 32-bit resolution and does this efficiently in software. The scheduler therefore increases code modularity and reduces hardware utilization. Example output of the scheduler can be seen in Figure 5. In this example, three periodic events are added to the scheduler. These events can be added in any order and at any point in time (i.e, they do not have to be added during initialization). The scheduler then schedules an output compare interrupt for the event that occurs next in time. Upon execution, the interrupt executes the specified task and schedules another interrupt for the next event in time. Figure 5: Scheduler output The described scheduling scheme has advantages and drawbacks. The main drawback is that scheduled functions are executed in the background so that the system is essentially stalled while this is happening. This means that the programmer has the important responsibility of ensuring that scheduled tasks execute as quickly as possible. 14

26 For example, the scheduler may be used to set a flag that a foreground loop constantly checks. A loose hierarchy can be achieved by the order the various flags are checked in the foreground. One might try to achieve a similar scheduling behavior by creating a static schedule and explicitly indicating when tasks should be run. The drawback to this approach is that you can never anticipate when sporadic events trigger input captures. For example, the robot uses a rotary encoder to measure wheel speed and to measure car velocity. This encoder produces non-periodic input capture interrupts that cannot be scheduled in advance and could interfere with a static schedule. Also, upon addition of a new event a consistent static schedule becomes harder to find and must be manually recalculated. For these reasons, the proposed scheduler operates dynamically. X86 to 9S12 Communication Interface With the low level control handled by the microcontroller, the x86 board is responsible for performing high level direction and relaying commands to the microcontroller. Initially, a high level control architecture was attempted from scratch. This involved too much effort and would likely not be simple to use by programmers in the future. It was then decided to incorporate Player into the design of the robot. A Player driver to interface with on-board microcontroller was created. The Player frontend provides the Player API, and the Proteus Player driver (back-end) translates these API commands, such as move forward, turn left, into commands that the microcontroller can use. These commands are then transmitted to the microcontroller over a serial cable. All communication between the x86 and the microcontroller is initiated by the software on the x86 side. If a response is necessary from the microcontroller, the x86 software waits for a response after its transmission. The move to a Player driven system has been 15

27 extremely useful in terms of simplifying outside development and encouraging code reuse. This project would likely be unsuccessful without this feature. The protocol used to transmit data from the x86 to the 9S12 is shown in Figure 6. The data is encapsulated by start and end bytes, which act as synchronization sentinels. These sentinels are detected by the incoming data interrupt service routine (ISR) on the 9S12 and allow it to efficiently buffer the inner command data. Once the end byte is received then a flag is set and the command is processed in the foreground. The protocol used to transmit data from the 9S12 to the x86 is shown in Figure 7. This protocol is simpler since the x86 code waits for a response from the 9S12 before continuing. This method of handling serial I/O could be an area of improvement in the future. 16

28 Table 1 through Table 3 show more detail on the communication protocol. Figure 6: x86 to 9S12 command protocol Figure 7: 9S12 to x86 command protocol 17

29 Table 1: Proteus embedded system command protocol OpCode Data Byte 1 Data Byte 2 PROTEUS_OPCODE_START PROTEUS_OPCODE_BAUD PROTEUS_OPCODE_CONTROL PROTEUS_OPCODE_SAFE PROTEUS_OPCODE_FULL PROTEUS_OPCODE_STOP PROTEUS_OPCODE_DRIVE VEL_MSB VEL_LSB PROTEUS_OPCODE_LEDS PROTEUS_OPCODE_SENSORS Sensor Pkt Num Data Byte 1 Data Byte 2 Table 2: Sensor packet part 1 Sensor Packet Number Data Byte 2 Data Byte 3 PROTEUS_ODOMETRY_PACKET DIST_MSB DIST_LSB Data Byte 4 Data Byte 5 Data Byte 6 PROTEUS_IR_PACKET IR1_MSB IR1_LSB IR2_MSB IR2_LSB IR3_MSB PROTEUS_SONAR_PACKET SN1_MSB SN1_LSB SN2_MSB SN2_LSB SN3_MSB PROTEUS_COMPASS_PACKET HEAD_MSB HEAD_LSB Table 3: Sensor packet part 2 Data Byte 7 Data Byte 8 Data Byte 9 Data Byte 10 Data Byte 11 Data Byte 12 Data Byte 13 IR3_LSB IR4_MSB IR4_LSB IR5_MSB IR5_LSB IR6_MSB IR6_LSB SN3_LSB SN4_MSB SN4_LSB SN5_MSB SN5_LSB SN6_MSB SN6_LSB Motion Control To maximize the flexibility of the robot s behavior, a powerful and flexible toplevel control architecture must be used. It is always possible to create optimized algorithms for particular situations, but a better design would allow for adaptation through modularity for a range of situations. Tests of Proteus robots in various scenarios 18

30 have been a necessity. Typically the required action to be performed is either remote control or some variation of autonomous navigation. Using Player, remote control is relatively trivial. Autonomous navigation encompasses many varieties of guided motion. The specific navigation Proteus pursues includes anything from simple odometry navigation to more complex feedback navigation using sensor fusion. David Anderson's JBot[10] is a simple yet effective robot used for long range outdoor navigation. The JBot is able to successfully navigate to a far-off waypoint and avoid obstacles while doing so. The software architecture JBot uses to accomplish this is called Subsumption [11]. Subsumption is a simple reactive architecture that separates different types of behaviors into various hierarchical levels which operate in parallel. On Proteus a multithreaded Subsumption data structure was created in C++ to facilitate a wide range of navigation tasks. This architecture enables the creation of several different behaviors that are able to combine to achieve various useful tasks. For example, an obstacle avoidance behavior is solely used to turn away from obstacles. By itself, the behavior is very simple and if implemented on a robot would create a robot that would tend to "run away" from any obstacles it encountered. Another behavior is a navigate behavior that may be configured in several different ways, depending on what sensors are available. This behavior, by itself, would make a robot drive towards a series of waypoints. It, again, is relatively simple and can be tested independently. When these two behaviors are combined using Subsumption, they create a more intelligent behavior similar to that of the JBot. Work has been done to maintain flexibility in the Subsumption implementation so that it may be used with any robot base and a wide range of sensors. 19

31 Chapter 3: Experiments FIELD TEST #1 The first field test of multiple Proteus robots was conducted at the Tony Burger Center in Austin, TX on October 5 th The goal for this test was to practice mobilizing multiple robots and test the feasibility of conducting large scale experiments. Ten robots equipped with GPS and compass sensors were used. The mobility software used a predetermined list to navigate to GPS waypoints autonomously. The end goal for this type of test was to collect wireless channel data while performing a certain mobility pattern. Autonomous navigation was required so that all network activity could be dedicated for the wireless networking experiment. Figure 8 shows a Proteus robot configured for Field Test #1. Figure 8: Proteus robot configured for Field Test #1 20

32 Problems Encountered There were a number of problems encountered during the first field test. The first problem was a hardware issue that prevented any of the robots from charging. A generator had been brought to provide electricity throughout the test. This generator had a ground fault circuit interrupt (GFCI) outlet that would trigger when charging the robots. This was the most critical issue because once the robots batteries were depleted we could no longer perform tests. A second problem was the lack of proper hardware testing before conducting the test. Before the test, both hardware and software had been validated on a single robot. During the test day, many of the robots were not fully constructed and certainly not tested. We experienced a few faulty sensors and cable connection issues that should have been easily detected before we arrived at the test site. The final large problem encountered was that of wide-scale test deployment and data collection. Each robot had to use a separate waypoint data file and the results had to be logged and ultimately recorded somehow. A robust system was not in place for performing this function. Many of the problems encountered were expected and uncovering them early one was an intentional goal of the first field test. Many of these issues were address for the second field test. FIELD TEST #2 The types of experiments targeted for the second field test were very similar to those intended for the first field test. Again, ten robots were taken to a large parking lot with GPS and compass sensors. In addition to simple mobility, the wireless throughput of mobile nodes was an experiment of interest. In order to mitigate the difficulties associated with large scale deployment, a sophisticated script system was developed that used a distributed version control system to deploy and record data across multiple robots. This proved to be much more effective than previous methods. 21

33 Promising results were obtained from two experiments conducted. The first experiment was a validation of the navigation capabilities of the robots. Figure 9 shows the latitude/longitude data as recorded by a robot following a series of GPS waypoints. The straight lines in the figure represent the ideal path prescribed to the robot as defined by successive GPS waypoints. The irregular path represents the actual sampled path the robot followed. Figure 9: Recorded position data of a Proteus robot performing autonomous GPS navigation Another experiment was run to record wireless throughput rates between mobile nodes. For this test one robot was placed on the ground and remained stationary throughout the test. A second robot was given a repeating sequence of two waypoints to follow. In doing so, the second robot would oscillate between two points, allowing 22

34 wireless throughput tests to be performed. Figure 10 shows the logged GPS data from the second robot for this test. Figure 11 shows the recorded wireless throughput as a function of GPS latitude. GPS latitude is representative of position and one can observe that the data throughput peaks at a particular latitude. Figure 10: Recorded position data for wireless throughput test 23

35 Figure 11: Wireless throughput vs GPS latitude Problems Encountered While the second test day was much more eventful than the first, there still were problems with robot reliability. By the end of the day there were only a fraction of the robots that would continue to perform consistently. The suspected cause of much of this instability was inefficient 9S12 code, along with poor battery life on the robots and on the separately powered handheld GPSs. Since the second test, the 9S12 code has been restructured, larger batteries have been installed on the robots, and a GPS sensor has been designed specifically for the Proteus robot. Further tests will decide whether these efforts have been successful. 24

36 COOPERATION WITH AUBURN UNIVERSITY Auburn University expressed interest in using Proteus robots for wireless networking research early in Over the next Summer, Fall, and Spring students working on the Proteus robots at UT built six robots to ship to Auburn. One of the six robots was equipped with a computer webcam to demonstrate remote video streaming from the robot. During March 2010, the six robots were shipped and two students from UT traveled to Auburn to supervise their arrival and subsequent use. The researchers at Auburn intend to use these robots to build a network test bed that also includes the use of aerial vehicles. 25

37 Chapter 4: Conclusion The main challenges that lie ahead involve creating applications for Proteus robots and continuing to build on the software infrastructure that has been established. Plans are in place to exhibit not only obstacle avoidance using Proteus robots but robotto-robot avoidance. Moving obstacles are more difficult because the time-to-collision is no longer a function of one robot s velocity. Also, other robots do not always present a surface that range finding sensors can detect reliably. Other forms of localization and navigation have become priorities. Vision-based navigation, for example, can be used to generate navigation algorithms. Line following gives researchers a simple way of creating a path for a robot to follow. These and other improvements should increase the number of useful experiments Proteus robots are able to perform. The Proteus robot has been presented as a tool to be used in validating research and for educational purposes. It has been designed to accommodate many different applications through the use of flexibility and modularity. Such modularity is achieved through clean hardware layout, a physically layered design, the robust Player software architecture, and decoupled motion control algorithm. Several successful tests of Proteus robots have been conducted and other research institutions have found the robot useful. The Proteus platform is well positioned to positively influence research at the University of Texas in the future. 26

38 Appendix A: Proteus hardware as of Fall 2008 Figure 12: Proteus hardware as of Fall

39 Appendix B: Microcontroller software organization Figure 13: Microcontroller software organization 28

40 Appendix C: Initial version 2 computation layer design Figure 14: Initial version 2 computation layer design 29

41 Appendix D: Proteus PCBs Note: See [8] for more detail. Figure 15: 9S12 Extender PCB schematic Figure 16: 9S12 Extender PCB layout 30

42 Figure 17: Battery charger PCB schematic Figure 18: Battery charger PCB layout 31

43 Figure 19: Auxiliary Sense PCB schematic Figure 20: Auxiliary Sense PCB layout 32

44 Figure 21: IR Switch PCB schematic Figure 22: IR Switch PCB layout 33

45 References [1] IRobot Create. [Online]. Available: [2] Mobile Robots Inc. [Online]. Available: [3] Segway Mobility Platforms. [Online]. Available: [4] Nomadic Robots. [Online]. Available: [5] K-Team. [Online]. Available: [6] Botrics. [Online]. Available: [7] ER1 Personal Robot System. [Online]. Available: [8] Proteus Subversion Repository. [Online]. Available: [9] The Player Project. [Online]. Available: [10] The Journey Robot. [Online]. Available: [11] R. A. Brooks, How to build complete creatures rather than isolated cognitive simulators, in Architectures for Intelligence. Erlbaum, 1991, pp

46 Vita Nicholas Paine is a graduate student and the University of Texas. He received his B.S. in Electrical Engineering in He intends to continue working in the field of robotics with a focus on agile robotic mobility. n.a.paine@gmail.com This report was typed by Nicholas Paine. 35