ViperRoos: Developing a Low Cost Local Vision Team for the Small Size League

Transcription

1 ViperRoos: Developing a Low Cost Local Vision Team for the Small Size League Mark Chang 1, Brett Browning 2, and Gordon Wyeth 1 1 Department of Computer Science and Electrical Engineering, University of Queensland, St Lucia, QLD 4072, Australia. {chang, wyeth}@csee.uq.edu.au 2 The Robotics Institute, Carnegie Mellon University, 5000 Forbes Avenue Pittsburgh, PA 15213, USA. brettb@cs.cmu.edu Abstract. The development of cheap robot platforms with on-board vision remains one of the key challenges that robot builders have yet to surmount. This paper presents the prototype development of a low cost (<US$1000), on-board vision based, robot platform that participated in the small-size league in RoboCup The robot platform, named the VIPER robot, represents an integration of state of the art embedded technology to produce a robot that has reasonable computational abilities without compromising its size, cost or versatility. In this paper, we describe the hardware architecture of the system, its motivation through to its implementation. In addition, we reflect upon their performance at the competition as a measure of the robustness and versatility of the robot platform. Based on these reflections, we describe what remaining developments are required to evolve the system into a truly capable and versatile research platform. 1 INTRODUCTION Robot soccer is an exciting new research domain aimed at driving forward robotics and multi-agent research through friendly competition. In this paper, we describe the development of the Viper robot (see figure 1), a prototype robot platform with onboard vision developed for the RoboCup'2000 competition. Although primarily intended for robot soccer competition, the Viper robot platform provides a versatile research base for investigating autonomous robot intelligence issues at low cost. We describe the robot architecture and reflect upon its performance at RoboCup'2000, and as a general research vehicle, as a means for determining what remaining work is required to develop a truly useful platform. Building a small, versatile mobile robot with on-board vision capabilities at low cost is a challenging problem and one that has yet to be reliably overcome in the field of robotics. Building a robot for RoboCup competition is even more difficult as the system must be both robust to the strenuous RoboCup environment and provide highperformance characteristics while fitting inside a small volume. Although there have been numerous attempts at building cheap robots with on-board vision capabilities, few approaches are suitable for small size RoboCup competition either because of size, cost or some other constraints.

2 We believe that a fully custom design, utilizing the wide range of embedded processors that are currently available, provides the best approach to satisfying the many constraints required for a successful RoboCup robot platform. The Viper robot platform takes a novel approach to developing a low cost robot system with reliable hardware and on-board vision capabilities. In contrast to most other robot hardware (e.g. [2, 7]), the Viper robot divides the problem by using different embedded processors handle the contrasting needs of vision and motion control processing. As most high end embedded processors are not suited to motion control and vice versa, this approach enables one to choose from a much wider range of processors thus producing a better overall product. Fig. 1. The Viper robot with a golf ball. In this paper we describe the Viper robot platform and the specifics of the prototype Viper system developed for RoboCup'2000. Section IV describes the performance of the system, from a user's perspective, at the RoboCup competition and also as a general research vehicle. Section V discusses the performance of the robot and determines what remaining work is required. Finally, section VI concludes the paper and lists the future direction of the Viper project. 2 The VIPER System The Viper system consists of the mechanical chassis and motors, the electronics and associated batteries, the software environment on the robot and the development support facilities that run on an off-board PC. The robot is fully autonomous, in the sense that all sensing, computation and actuation are performed on-board. In this section, we describe the physical hardware of the robot, its computational arrangement and capabilities, and the software environment that was developed for the RoboCup competition. 2.1 Mechanical Structure Mechanically, we desired a robot that would be robust to the RoboCup conditions while offering high-speed maneuverability. As a nominal figure based on our prior RoboCup experiences, we desired a robot that could reach velocities in excess of 2m.s -1 with an acceleration of greater than 2m.s -2. To fulfil these requirements the Viper robot was built upon the same mechanical base of the RoboRoos robots, a global vision robot soccer team used successfully in previous RoboCup competitions.

3 To conserve space we will not discuss the mechanical details here but instead refer the reader to [12] for further details. Figure 2 shows the Viper robot with its primary mechanical components labeled. The Viper robot is 180mm wide by 100mm long and stands around 120mm high (not including antenna). The camera is mounted on a separate Printed Circuit Board (PCB) that can be tilted along the horizontal axis. The prototype robot uses a 2.8mm, manual iris, CS-mount lens providing a horizontal field of view of just under 100 at full image resolution. Fully assembled, the robot weighs about 850g and exceeds the speed and acceleration requirements specified above. Camera RF Board EPP Cable Processors Boards IR Sensors Batteries Antenna DC Motors Wheel & Encoder Wheel & Encoder Fig. 2. The major components of the VIPER robot. 2.2 Computational Structure Vision and motor control have very different requirements in terms of electronic hardware. Vision, a processor intensive task, requires a fast processor that has hardware to enable interfacing with the digital output of the CMOS image sensor. Motor control requires a processor with peripheral set that is capable of performing timer-related operations without CPU intervention. Due to these contrasting hardware requirements, the Viper's computational architecture is divided into two parts. A vision board, with an embedded RISC microprocessor, performs all operations related to vision and communication to other robots. Meanwhile, a second processor board performs all motor control operations and also all remaining computation required. The two, distinctly different processor systems interact over a 60kbs asynchronous serial link. Figure 3 shows the conceptual arrangement of the two processor boards. The following sections describe each component of the system.

4 PC PB-300 Colour CMOS Camera Motor Drivers EPP Cable Link Vision Board SH7709 Processor Motor Board Processor Encoders Half Duplex Radio Link async. Serial link PC/Other Robots 6x1.2V 700mAH NiMH Fig. 3. The processor architecture on the Viper robot Camera Selection The camera chosen for the Viper robot was a Photobit PB-300 CMOS image sensor. A CMOS image sensor was chosen over a CCD sensor for its lower power consumption and fully digital interface. The camera chip situates on a customdesigned PCB with aluminum mounting for a CS-mount lens. The camera provides color images of 640x480 pixels arranged in a Bayer 2G format through a digital interface utilizing 8 data lines and three hardware handshaking signals. Due to the SH-3's limited bus bandwidth the full data rate from the PB-300 of 30fps was limited to around 10 fps on the Viper implementation. The camera supports electronic panning and windowing but not zooming. Additionally, the chip allows full control over exposure time, color gains, color offsets, horizontal and vertical blanking. All these options are controlled through parameters stored in registers that can be accessed through a standard synchronous serial (I 2 C) interface. Although the camera has on-board auto-exposure routines these were typically disabled and the camera parameters fixed by the programmer at the competition Vision Board To perform the necessary vision capture and processing requires an embedded processor that has both a capable CPU core and a wide ranging peripheral suite. Specifically, the peripherals must support glueless interfacing to high density memories, Direct Memory Access (DMA) for image capture and other large scale memory transfers, and serial communications. There are a number of embedded processors currently on the market that fulfil these requirements at a low cost. Prime examples include the Texas Instruments TMS320C6xx series, the Hitachi SH-4 and the up-coming SH-5 series processors. Due to processor availability in Australia during the early design phase (early 1999), we chose the Hitachi SH-3 processor as a stepping stone to the SH-4 and SH-5 processors. The SH-3 is fully code compatible to the SH-4/5 and has the same peripheral suite.

5 The Hitachi SH-7709, the most versatile of the SH-3 processors, is a 32-bit RISC processor that can perform at up to 80MIPs (40MHz bus clock). The processor has a peripheral suite that facilitates glueless connection of numerous memory types, three serial connections, and a four-channel DMA controller. The resulting vision board has 16MB of 32-bit wide, 100MHz SDRAM for main program memory and 512KB of 8- bit wide 15ns SRAM for image storage. Boot code is stored in 512KB, 8-bit wide 5V Flash or EPROM. All memory interfaces are glueless, meaning there is no extraneous interface logic, through the SH-3 Bus controller peripheral. Color image data from the PB-300 CMOS image sensor is transferred, one byte at a time, to the SRAM via DMA. Here, SRAM is used for image transfers rather than SDRAM as it has no overheads for the single byte transfer. There are three main communication channels on the vision board. An asynchronous serial link running at 60kbs using one channel of the Serial Communications Interface (SCI) peripheral connects the vision and motor boards. To operate as efficiently as possible, the serial link uses DMA to transfer data to and from the motor board, leaving the CPU free to perform other processing. Communication to the PC and other robots in the robot soccer environment occurs through a wireless, half-duplex FM asynchronous serial link operating at a nominal 19.2kbs. Finally, an EPP (Extended Parallel Port) interface to the PC enables realtime video debugging with the use of a standard 25-way parallel cable and custom software. The half-duplex, 8-bit EPP channel operates using DMA and hardware interrupts Motor Board There are a number of embedded micro-controllers designed specifically for motor control primarily for use in the automotive industry. We chose the Motorola MC68332 for the motor controller board given its wide range of peripherals, reliable development system and low cost. The MC68332, hereafter the 68332, is a 32-bit CISC processor that operates at 20MHz giving around 5MIPs. The peripheral set supports glueless connection to SRAM and Flash memories, synchronous serial communications (QSPI), asynchronous serial (SCI) communications, timer utilities (TPU), and Background Debugging (BDM). The motor board has a modest 256KBx16 SRAM and 512KBx16 Flash where the Flash is in-system programmable through the use of the Background Debugging Mode (BDM) connection. BDM enables access to the registers and memory space without CPU control through a dongle connected to the PC parallel port. The controls the motors through its Timer Processor Unit (TPU) peripheral, a powerful timer utility that requires no CPU intervention to perform a wide variety of timer functions with 16 independent output channels. The TPU drives the two motors through MOSFET H-Bridges with Pulse-Width-Modulation (PWM) signals and keeps track of the encoders with Quadrature Decode (QDEC) operations using 2 channels per motor and 2 per encoder. Each encoder provides 500 clicks per revolution, which with QDEC becomes 2000 clicks per revolution giving a fine grained resolution of 47µm and a velocity resolution of 47mm.s -1 when sampled at 1kHz. The has two serial peripherals: a Queued Serial Peripheral Interface (QSPI) for synchronous serial operations and a Serial Communications Interface (SCI) for asynchronous serial operations. The QSPI operates a set of 8 IR proximity sensors

6 used to detect obstacles in front of the robot that are too close for vision to sense (trigger distance is typically set to mm). The SCI communicates, with hardware interrupts, to the vision board at the rate of 60kbs. The bandwidth limitation on this communications channel is related to the interrupt latency and processing time on the rather than hardware limitations. 2.3 Software Development Environment This section will briefly describe the low-level software and the development environment created for the Viper robots. For a more detailed description of the Viper software used at RoboCup'2000 please refer to [4]. All robot software is written in C with some of the boot and time critical code written in assembler. Currently, the robot is programmed in a two stage process corresponding to the secondary memories on each processor board. Typically program development is focussed on either vision or motor control and so this does not prove a hindrance, however, future work aims to migrate to a program once only system. Both processors have a library of device drivers that provide a single layer of hardware abstraction without significantly hindering computational efficiency. These device drivers hide most of the hardware details but do provide facilities to configure many of the peripheral features during initialization. All high usage paths, for example resetting DMA transfers, are structured to enable maximum throughput with minimum overheads. In short, a simple but fast approach has been utilized to obtain maximum efficiency. In addition to the device driver library, the vision processor has a library of vision related function optimized for the SH-3 processor. Similarly, the motor board software includes a PID servo-loop routine that operates at 1kHz for velocity control of the robot. The motor board also includes a developmental multithreaded, pre-emptive OS although this was not used at the competition. As an aid for debugging both at the competition and during development, we have written custom PC software operating under the Microsoft Windows 9x environment. The PCDebug program allows real-time video debugging via the EPP connection and interaction with the robots via the RF-link where it forms part of the communication network with the robots. Overall the robot costs less than US$1,000 to build on an individual basis making it a cheap autonomous robot platform for its capabilities. The price would significantly decrease for larger productions. Using cheaper components for the motors and chassis could produce a robot under US$500 but would of course detract from its mechanical performance. 3 System Performance In general the robot hardware performs at or beyond our initial expectations. Once built, the hardware proved robust and reliable. In all its operation over 18 months as a research test bed and competition vehicle, we have had to fix only two problems: a broken battery connector and a broken encoder. Given their high use both problems can be attributed to wear and tear and are to be expected. In all other cases, the robots

7 have remained stable and operational with no real maintenance required to keep the status quo. In terms of general performance, the robot is able to travel at the speeds and accelerations specified above. Actually navigating at such speeds is limited due to the lack of satisfactory control by the navigation system, a common situation for local vision teams in robot soccer. As a demonstration of the Viper system's capabilities, and as its primary design aim, a team of Viper robots was entered in the RoboCup 2000 competition with the team name ViperRoos. The ViperRoos RoboCup team consists of three Viper robots: two field robots and a goalkeeper. In any performance metric the ViperRoos were clearly amongst the best of the small size local vision teams at RoboCup'2000. The robots even proved somewhat competitive against the weaker global vision teams. The robot software consisted of three main components: vision processing, localization and the soccer behaviors (see [4] for details). For the sake of brevity, this discussion will focus on the ViperRoos as a demonstration of what the Viper robots are capable of and also where the limitations in the system lie. The allocation of processing resources on the Viper robots was quite straightforward. The vision board performed all vision processing and communication with other robots. The vision board also performed a majority of the localization routines required to keep the robot's estimate of its position in the world accurate. The motor board performed all motion control routines, including a PID servo loop controlling the robot's forward and rotational velocity components, and the behavior architecture that produces the actual soccer game play of the robot. For vision processing, the ViperRoos utilized a series of standard vision algorithms common to robot soccer (e.g. [10]) to recognize objects in the image based on their color in YUV space at the frame rate of 10Hz. Briefly, the vision system sub-samples and converts the raw 512x128 Bayers 2G input to 128x32 YUV and segments it based on a pregenerated YUV lookup table. Blobs are found in the segmented image using a standard region growing algorithm and categorized into objects based on their dominant color. Valid objects include the walls, goals, robots, or the ball. No distinction was made between fellow teammates or opponents. The resulting visual information is fed to the localization system and the behavior system. The localization system used for RoboCup 2000 was quite simple and much work remains in improving its performance. In short, the system relied predominantly on deadreckoning developed from the 1kHz PID servo routines running on the motor board. Resets to the dead-reckoned localization were performed when landmarks (walls and goals) were reliably observed. While this system has some obvious deficiencies, it worked reasonably well considering its development time was minimal. To actually play soccer, the ViperRoos used a behavior-based approach modified from the behavior architecture used on the RoboRoos robots, the precursors to the ViperRoos (see [12] for more details). On the Viper implementation, the motor board performed the computations required for navigation and kicking the ball. The navigation system, which was essentially reactive, was operated at a nominal rate of 30Hz and used encoder feedback to exceed the raw sensing rate. The current ViperRoos does not utilize on-board RF transceivers for inter-robot communication, but a simple broadcast system was used to send the referee's directives to the robots and monitor their operating status. The RF transceivers are capable of operating on a half-duplex communication at the modest speed of 19.2Kbps. In terms of raw competition performance, the ViperRoos performed admirably for their RoboCup debut. The team finished the round robin stage with one win and two

8 loses against three global vision teams. In a specialized local vision only competition the robots performed well but no goals were scored either for or against. However, ViperRoos demonstrated their speed and accuracy over other local vision teams during the penalty shoot out. The ViperRoos missed one goal in ten attempts and managed to block all shots on goal from the opponents. From the programmer's perspective the robots performed reliably and robustly. The programming interface worked satisfactorily, allowing fast development and with the EPP and RF link relatively easy debugging. The ability to retrieve live video feeds from the robots, albeit through an EPP cable, enabled fast calibration of the system parameters before each game while the RF link enabled run-time debugging of robot software. More work is required however to improve the GUI features of the debugging interface to make it truly user friendly. In terms of producing fast, efficient, code no extensive effort was required. Careful attention was required in the development of the vision library, but typically is not required elsewhere. Indeed, the limitation on frame rate was due to the limited bus bandwidth of the SH-3 rather than its processing capabilities per se. 4 Discussion 4.1 Comparisons to other Systems There are a number of alternative approaches to building small, local vision robots. As with the Viper, most approaches rely on building custom hardware to achieve the desired performance characteristics within the compact size requirements. Probably the best amongst these are the Eyebots [2]. The Eyebot controller board is designed around a Motorola processor and uses a commercially available CCD camera with a parallel output. As the entire robot system is built around the same processor used for motor control on the Viper robot, the Eyebot is naturally more limited in terms of its processing capabilities meaning it must use significantly coarser images to obtain the same processing speeds. Outside of the small-size scale, there are a number of local vision robots that are either low cost or commercially available. The most notable of these is the Sony Aibo robot dog which provides a common robot platform for the RoboCup s Sony legged league (e.g. [11]). These robots offer relatively cheap robot vision with the addition of legged motion. The mid-size league consists entirely of on-board vision robots, but typically these systems are neither cheap nor small. In many cases, these systems, due to the larger size specifications, use laptops or single board computers to process vision with simpler local processors to perform motor control (e.g. [5]). This is clearly a similar strategy to the Viper robot taken to a larger extreme. 4.2 Limitations and Future Work The heavy use of the Viper system for the RoboCup competition clearly demonstrated the versatile ability of the system. The approach taken to build the Viper robot

9 demonstrated a number of points that, in our opinion, worked effectively. In particular, the choice of the dual processor architecture enabled a wider selection of processors more suited to the differing tasks of vision and motor control. In addition, this approach which divides a system into loss coupled modules allows each processing board to be upgraded without re-implementation on either the software or hardware of other modules. The compact mechanical design and careful selection of battery and motor technology produced a small fast robotic platform that is robust for the competitive conditions. The choice of CMOS imaging technology as opposed to CCD's that reduced the complexity of the electrical interface and the power consumption of the camera overall. Of course, as it is a prototype, there are always bugs or deficiencies that need to be improved. There are a number of problems with the Viper platform that require future work to improve the system overall. Firstly, better performance from the vision system to achieve the full possible 30Hz frame rate requires an upgrade the vision processor. At the time of designing the Viper prototype, there was a lack of availability of higher end processors. This is no longer the case, the replacement of the vision processor is now possible and is currently being carried out. In addition to improving the general frame rate, the higher bandwidth processor should enable pixels to be processed as they arrive rather than buffering an entire image before processing it. This would significantly reduce the system latency, which will in turn improve the overall robot performance regardless of the control architecture being used. With a packet structure including start and stop bytes with Manchester encoding, the robots can reliably communicate with one another at 19.2kbps. The weakness to the approach, other than the low bandwidth, was the significant delay required when switching from transmission to reception for the token ring network (typically around 250ms). Using newer RF transceiver technologies such as BlueTooth, the single chip 900MHz transceivers used in portable phones or 2.4GHz Spread Spectrum Transceiver offer an opportunity to greatly increase the transmission speed and throughput of the RF link. 5 Conclusions This paper has described the Viper robot system and its performance as a robot platform in the robot soccer competition and as a general research vehicle. We believe that the robust performance of the vehicle demonstrates both the virtue of investigating cheap (<US$1000) autonomous robots with vision sensing, and our approach to doing so. Specifically, the dual processor architecture presented in this paper offers a way to make the most of processor technology that is currently available without breaking the budget. There is considerable remaining work to develop the Viper platform into a truly capable and versatile robot base for research and robot soccer purposes. Most of this work focuses on a redesign of the system to incorporate the latest technology that was not available during the initial design phase. Additionally, improvements to the software and development environment are required to make the developer's life easier and to aid in general productivity.

10 References 1. Behnke, S., Frtschl, B., Rojas, R., et al. "Using hierarchical dynamical systems to control reactive behavior", Proceedings of IJCAI-99, 28-33, Bräunl, T., Reinholdsen, P., and Humble, S., "CIIPS Glory Small Soccer Robots with Local Image Processing," submitted for RoboCup-2000: Robot Soccer World Cup IV, Springer Verlag, Browning, B. A Biologically Plausible Robot Navigation System, Phd. Dissertation, Computer Science & Electrical Engineering Department, University of Queensland, Chang, M., Browning, B., Wyeth, G., "ViperRoos 2000", submitted for RoboCup-2000: Robot Soccer World Cup IV, Springer Verlag, Emery, R., Balch, T., Bruce, J., Lenser, S., et al. CMU Hammerheads Team Description, submitted for RoboCup-2000: Robot Soccer World Cup IV, Springer Verlag, Kitano, H., Asada, M., Kuniyoshi, Y., Noda, I., Osawa, E., & Matsubara, H., "RoboCup: A Challenge Problem for AI and Robotics," RoboCup-97: Robot Soccer World Cup I, Nagoya, L.N. on A.I., Springer Verlag, 1998, pp Marchese, F., Sorrenti, D., Omni-directional Vision with a Multi-part Mirror, Proceedings of The Fourth International Workshop on RoboCup, 2000, pp Photobit Web Site 9. RoboCup Official Website at Veloso, M., Bowling, M., Achim, S., Han, K., and Stone, P. "The CMUnited-98 champion small robot team", M. Asada, H., Kitano (eds), RoboCup-98: Robot Soccer World Cup II, pages Springer Verlag, Berlin, Veloso, M., Winner, E., Lenser, S., Bruce, J., and Balch, T., "Vision-servoed localization and behavior-based planning for an autonomous quadruped legged robot", Proceedings of AIPS-2000, Breckenridge, Wyeth, G., Tews, A., & Browning, B., "RoboRoos: Kicking into 2000," submitted for RoboCup-2000: Robot Soccer World Cup IV, Springer Verlag, 2001.