From String-Puppets to Autonomous Systems 1 ... - Semantic Scholar

From String-Puppets to Autonomous Systems

On the Role of On-board Control in the Small Robots League Andreas Birk and Holger Kenn and Thomas Walle Arti cial Intelligence Laboratory Vrije Universiteit Brussel fcyrano,kenn,[email protected]

Abstract We discuss in this article the positive prospects and the pitfalls of the Small Robots League of RoboCup in respect to on-board control and other on-board features for the players. For this purpose, we introduce a classi cation of teams based on a general set of components for players. With this background, we motivate the importance of fostering on-board features for the players and present bene cial and negative aspects of size constraints. As our contribution to a fruitful exploitation of on-board features, we present the most recent version of our RoboCube system, a special robot-controller hand-tailored for players in the small robots league. The RoboCube is conceptualized to implement players with as many on-board features as possible in an extreme exible way. For this purpose, the RoboCube provides quite some computation power and memory as well as a multitude of I/O-interfaces within the space-constraints. As it facilitates the use of many sensors and eectors, including their on-board processing, the RoboCube allows to explore a large space of dierent robots and team set-ups. In addition to the basic system, we present the option to enhance RoboCube with high-resolution color vision to a so-called VisionCube. In doing so, we exploit the possibilities of a completely new technology in imaging based on C-MOS chips. Among other advantages, the particular imager used in our design allows a selective read-out of pixels. Unlike CCDs where a complete frame has to be read, the VisionCube can read subsets of the 512512 colored pixels of its imager in an extremely fast way. This makes it feasible to explore the challenging option of local vision with on-board processing.

1 Introduction The Small Robots League of RoboCup [KAK+ 97, KTS+97] allows global sensing, especially bird's view vision from an overhead camera, and restricts the size of the physical players to a rather extreme minimum. These two, most signi cant features of the small 1

robots league bear an immense potential, but as well some major pitfalls for future research within the RoboCup framework. First of all, it is tempting to exploit the set-up with an overhead camera for the mere sake of trying to win, reducing the robot-players to RF-controlled toy-cars within a minimalistic, but very fast vision-based closed-loop. The severe size limitations of the players in addition encourage the use of such \string-puppets" with o-board sensing and control instead of real robots. The Mirosot competition gives an example for this type of approach [Mir]. This framework would lead to dedicated solutions, which are very ecient and competitive, but only of very limited scienti c interest from both a basic research as well as from an application-oriented viewpoint. If the teams in the small robots league would follow that road, this league could degenerate to a completely competition-oriented race of scienti cally meaningless, specialized engineering eorts. A signi cant exploitation of on-board control, or more precisely of general on-board features (as de ned in section 2.1), is in contrast an extremely interesting scienti c issue for three major reasons. First, it is directly related to one of the greatest intellectual challenges of our time, namely the quest for a constructive understanding of intelligence. This aim to foster AI and related disciplines has been a major goal of RoboCup right from its beginning [KAK+ 97, KTS+97]. Second, RF-controlled toy-cars can hardly be called robots as already mentioned above. Therefore, it is important to encourage on-board features for the players to promote RoboCup as an experimental framework for robotics research. Third, the exploitation of on-board features is also related to an important technological development, namely the emerging eld of autonomous systems [Bir99] as networked embedded devices, i.e., computerized systems with sensors and eectors as well as standalone and communication capabilities. Information Technology has signi cantly in uenced our daily lifes in the last decades and it will continue to do so. But the potential of the increasing dominance of computer and networking facilities has its limits as IT is restricted to the transport, provision, and processing of mere information. In addition, there is the enormous possibility and the actual need to free devices which engage in physical perception and manipulation from explicit and permanent human supervision. For example E-commerce can only rise to its full potential if a multitude of autonomous systems collaborates in an automated ordering, delivery, and reception of goods. Though the two major properties of the small robots league, global sensing and severe size restrictions, discourage the important investigation of on-board control, they also have positive eects. First of all, the global sensing eases quite some perception problems, allowing to focus on other important scienti c issues, especially team behavior. An indication for this hypothesis is the apparent dierence in team-skills between the small robots league and the midsize league, where global sensing is banned. In RoboCup'98, teams in the small robots league managed to demonstrate some real team behaviors, like e.g. passing of the ball. The teams in the midsize league seemed not yet to be that far. Another indication for this hypothesis is that the midsize league considers reducing the 2

number of robots per team from Five to Four for RoboCup'99. The size restrictions as a second point also have a bene cial aspect for the investigation of team-behavior. The play- eld of a ping-pong-table can easily be allocated in a standard academic environment, facilitating games throughout the year. It is in contrast dicult to embed a regular eld of the midsize league into an academic environment, thus the possibilities for continuous research on the complete team are here limited. The severe size restriction of the small robots league has another advantage. These robots can be much cheaper as costs of electro-mechanical parts signi cantly increase with size. Therefore, it is more feasible to build even two teams and to play real games throughout the year, plus to include the team(s) in educational activities. The rest of this article is structured as follows. In section Two, we introduce a classi cation of team approaches based on possible basic components for players. With the help of this background, we motivate the importance of fostering on-board features for the players and present bene cial and negative aspects of size constraints. The third section deals with our RoboCube system, a special robot-controller hand-tailored for players in the small robots league. RoboCube's basic properties, its design, and its implementation are described. It is shown how RoboCube is conceptualized to implement players with as many on-board features as possible in an extreme exible way. In the fourth section, we present an option to enhance RoboCube with high-resolution color vision-facilities to the so-called VisionCube. There, we introduce a completely new way to deal with local vision under limited on-board processing capabilities. By exploiting the advantages of the recent technology of C-MOS imaging instead of CCDs, VisionCube provides a way to selectively read pixels from its 512512 imager in very fast ways. For this purpose, the VisionCube features subsampling windows, which read-out an arbitrarily shaped rectangle from an arbitrary position of the imager. Subsampling windows are dynamic, they can be moved, changed, created, and deleted at any time. Concretely, the read-out of a complete frame would take roughly 100 msec. The (virtual) parallel read-out of 8 subsampling windows, each of 6464 pixels and a sampling density of 4, takes only 6 msec in total, allowing on-board processing of local vision-data. Section Four concludes the article.

2 Quo Vadis, Small Robots League? 2.1 Classi cation of Team-Approaches For a more detailed discussion of the role of on-board control and other positive prospects and negative pitfalls within the small robots league, it is useful to have a classi cation of dierent types of teams and players. Minoru Asada for example proposed in the RoboCup mailing-list to use a classi cation of approaches based on the type of vision (local, global or combined) and the number of CPUs (one or multi). He also mentioned that in the case of multiple CPUs a dierence between 3

systems with and without explicit communication between players can be made. Though this scheme is useful, it is still a rst, quite rough classi cation. Therefore, we propose here to make ner distinctions, based on a set of crucial components for the players. In general, a RoboCup team consists of a (possibly empty) set of host-computers and o-board sensors, and a non-empty set of players, each of which consist of a combination of the following components: 1. minimal components (a) mobile platform (b) energy supply (c) communication module 2. optional components (a) computation power (b) shooting-mechanism and other eectors (c) basic sensors (d) vision hardware Note, that the most simple type of player, consisting of only minimal components, is hardly a robot. It is more like a \string-puppet" in form of a radio-controlled toy-car without even any on-board sensors or computation power (though it could well be possible that this type of device has an on-board micro-controller for handling the communication protocol and the pulse-width-modulation of the drive motors). The actual control of this type of players completely takes place on the o-board host(s). This is not necessarily a bad thing, but there is, as explained later, a negative pressure to move away from this state towards the important inclusion of on-board features for the players. Based on this minimal type of player, the optional components can be freely combined and added. In doing so, there is a trade-o between 1. on-board sensor/motor components, 2. on-board computation power, and 3. communication bandwidth. A player can for example be built without any on-board computation power at the cost of communication bandwidth by transmitting all sensor/motor-data to the host and back. So, increasing on-board computation power facilitates the use of a smaller communication bandwidth and vice versa. Increasing sensor/motor channels on the other hand increases the need of on-board computation power and/or communication bandwidth. 4

A

1111111111 0000000000 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111

host-computer(s)

B

1111111 0000000 0000000 1111111 0000000 1111111 0000000 1111111 0000000 1111111 0000000 1111111

global sensor(s)

unlimited player

111 000 000 111 000 111

severe size constraints

111 000 000 111 000 111 000 111

111 000 000 111 000 111

communication local vision 000 111 111 000 000 111 000 111

111 000 000 111 000 111 pressure against on-board features

energy supply computation power basic sensors shooting mechanism mobile platform

Figure 1: There are several basic components which can be, except the minimal ones, freely combined to form a player. Situation A shows the most simple type of player, a radio-controlled toy-car, which can hardly be called a robot. Situation B shows a much more elaborated player. Unfortunately, the size-constraints of the small robots league put a strong negative pressure against the important implementation of on-board features for the players. Unfortunately, there is a rather strong pressure against the implementation of on-board features within the small robots league in form of the quite severe size-constraints. A thorough restriction of the base-area of the players is of course necessary, as these dimensions determine the capabilities to block the ball and to otherwise interact with it. But the rather extreme limitation in height, 15 cm for players without and 22.5 cm for players with on-board vision, can hardly be well justi ed. There is the single issue that very tall players can obstruct the ball in few situations from the view of an overhead camera. But this \bug", which actually can be very well dealt with, can also be seen as a nice opportunity to encourage on-board vision, where these types of obstructions do not occur. In addition, the height of the players is already well restricted by stability constraints. In general, it only can be hoped that on-board features are encouraged by the organizers.

2.2 The importance of On-Board Features The exploitation of on-board features has, as already indicated in the introduction, several interesting scienti c aspects. The three major ones are

 its relevance for robotics,  its relation to the constructive investigation of intelligence, and 5

 its importance for the emerging technological eld of autonomous systems.

2.2.1 On-board features for Robotics and AI On-board features are important for research in robotics as well as AI and related disciplines for several reasons. Mainly, they allow research on important aspects which are otherwise impossible to investigate, especially in the eld of sensor/motor capabilities. For eector-systems for example, it is quite obvious that they have to be on-board to be within the rules of soccer-playing. Here, the possibilities of systems with many degrees of freedom, as for example demonstrated in the SONY pet dog [FK97], should not only be encouraged in special leagues as e.g. in the one for legged players, but also within the small robots league. In general, a further splitting of the RoboCup activities into too many leagues seems not to be bene cial and it also seems not to be practical. Too many classi cations which would justify just another new league would be possible. In addition, the direct competition and comparison of dierent approaches together with the scienti c dialogue are one of the main features of RoboCup. In the case of sensors and perception, the situation is similar to the one of eector-systems, i.e., certain important types of research can only be done with on-board devices. This holds especially for local vision. It might be useful to clarify here the often confused notions of local/global and on-/o-board. The terms on- and o-board are easy to distinguish, general properties. They refer to a piece of hardware or software, which is physically or logically present on the player (on-board) or not (o-board). The notions of local and global in contrast only refer to sensors, i.e., particular types of hardware, or to perception, i.e., particular types of software dealing with sensor-data. Global sensors and perception tell a player absolute information about the world, typically information about its position and maybe the positions of other objects on the play eld. Local sensors and perception in contrast tell a player information about the world, which is relative to its own position in the world. Unlike in the case of on- and o-board, the distinction between local and global is fuzzy and often debatable. Nevertheless, it is quite clear that the important issue of local vision can only be investigated if the related feature is present on-board of the player. Hand in hand with an increased use of sensor and motor systems on a player, the amount of on-board computation power must increase. Otherwise, the scarce resource of communication bandwidth will be used up very quickly. Note, that there are many systems using RF-communication at the same time during a RoboCup tournament. Especially in the small robots league, were only few and very limited o-the-shelf products suited for communication exist, transmission of large amount of data is impossible. It is for example quite unfeasible to transmit high-resolution local camera images from every player to a host for processing. 6

2.2.2 Autonomous Systems In addition to the relevance of on-board features for research in robotics as well as AI and related disciplines, they are also of high interest for research on autonomous systems, i.e., computerized systems with sensors, motors and some on-board intelligence, which allows them to interact with similar devices and which frees them from permanent and explicit human supervision. Research on this type of devices is a vastly growing eld and they are predicted to be a key technology of the starting millennium. The main reason for their commercial relevance is the continuously increasing amount of networking. With increasing availability and capacities, the use of networking facilities goes more and more beyond the mere transport, processing and provision of information. Starting with the current boom in \simple" teleoperation, actual physical manipulation through networked devices gets more and more important. The full potential of electronic commerce for example can only be reached, if a multitude of physical devices cooperate autonomously on the delivery of goods. Imagine for example an autonomous household, where the refrigerator and other devices keep accounts of goods, re-order if necessary, schedule transports from the \goods-port" at the front-door, and so on. An advantage of the study of autonomous systems over the eld of mere software agents is the relation of autonomous systems to the real world. Autonomous systems are and have to be grounded in physical concepts, leading to several concrete bene ts. First of the all, the real world and especially some \limited" environments as e.g. households, oces, and factories establish a better de ned context than some abstract information space. Dierent scientists, designers, and manufactures of devices are much more likely to share common ideas and principles, which are re ected in the theory and technology of these systems. Second, for basic issues of autonomous systems, for example sensing, manipulation, mobility, there is the possibility to pro t from the advanced status of already existing elds, like especially robotics. Last but not least, the real world provides, in combination with the sensors and motors, a supplementary and especially unambiguous information channel. Imagine for example the possibility of autonomous devices to schedule their activities to save energy. This is can range from a simple exploitation of lower electricity prices in certain periods of the day to an elaborated adaptation to an unpredictable supply from solar energy1 . In this context, devices already can coordinate their activities just by individual adaptation based on measuring supply and consumption. For autonomous systems, there are two major tasks that have to be accomplished. On the technological side, embedded devices have to be developed that provide sucient sensor/motor interfaces and that allow for network connections. On the theoretical side, coordination of system interactions, including the issues of cooperation, communication, and group formation, have to be investigated. So, RoboCup is an ideal testbed for these The changing, partially unpredictable supply is a major problem for domestic exploitation of solar energy. The standard solution of using a large buer in form of many lead-acid-batteries is expensive, needs quite some storage room, and is especially not very environment-friendly. 1

7

two purposes. The feature of including wireless components adds, apart from its other research issues, further attractiveness to RoboCup as testbed for autonomous systems. The development of large-scale networks for domestic and other private use will include quite some wireless components, as indicated by most recent home-networking initiatives. Wireless networking makes life easier for the common user, but on the system side, still many problems need to be solved.

2.2.3 Potentials and Pitfalls Of course, the implementation of on-board features is far from being the only important research issue of RoboCup. But we see some potential risks, that without an encouragement from the organizers and a fruitful scienti c discussion between participants on this issue, the small robots league might miss some promising opportunities. As already mentioned in the introduction, the small robots league also bene ts from the size constraints and the global sensing. The \string-puppet" approach of simple radio-controlled toy-cars also has its validation. It can for example serve as a rather easy and inexpensive way to enter RoboCup, it can be useful for educational purposes; shortly, it can be good for a start and to get acquainted with the basic issues of RoboCup. But in the long run, we hope that participants in the small robots league of RoboCup cooperate to improve the options of on-board features. Only through a joint eort, it will be possible to overcome the pitfalls and to mutually bene t from the positive potential of the limited size requirements in this league.

3 The RoboCube as \universal" \special-purpose" Hardware RoboCup is not laid out as a single event, but as a long-term framework for fostering signi cant scienti c research. Within this framework, it is expected that robots, concepts and teams co-evolve trough iterated competitions. As explained before, on-board control has to play an important role within this process. For this purpose it must be possible to not only explore a multitude of team and control approaches, but also the vast space of physical implementations of the robot players. General body features | like speed, mobility, and so on | as well as special body features | like e.g. shooting and dribbling capabilities | are like in real soccer the basis for successful performance. It follows that the architecture of the robots must be exible enough to allow physical changes and addons without requiring substantial re-engineering. Unlike in commercial robots, it must be possible to upgrade or add motors and other eectors, to use dierent sensors, and so on. 8

Figure 2: A picture of the RoboCube Short, it must be possible to explore the whole space of physical interactions between the robots, the ball, and the rest of the environment. But this exibility has to be provided within the concrete limitations of the RoboCup regulations, especially size constraints. Therefore, a careful design of a \universal" \specialpurpose" hardware is needed. The RoboCube is our attempt to provide the cornerstone for a conceptual framework and the technological implementation of a system allowing the fruitful and eective investigation of on-board control in the RoboCup small robots league. The RoboCube evolved out of pure robot-control hardware developed in the VUB AI-lab. Beginning in the mid-eighties up to now, various experimental platforms for behaviororiented architectures have been build. In doing so, experiences with approaches based on embedded PCs and dierent micro-controllers were gathered and lead to the SensorMotor-Brick II (SMBII)[Ver96]. The SMBII is based on a commercial board manufactured by Vesta-technology providing the computational core with a Motorola MC68332, 256K RAM, and 128K EPROM. Stacked on top of the Vesta-core, a second board provides the hardware for sensor-, motor-, and communication-interfaces. The RoboCube is an enhanced successor of the SMBII. In RoboCube the commercial computational core is replaced by an own design, also based on the MC68332, which saves signi cant costs, and the architecture is simpli ed. In addition, the physical shape of RoboCube is quite dierent from the one of the SMBII. First, board-area is minimized by using SMD-components in RoboCube. Second, three boards are stacked on each other leading to a more cubic design compared to the at but long shape of the SMBII. 9

Figure 3: A picture of main boards of the RoboCube We demonstrated the versality of RoboCube with our team that competed at RoboCup'98 [BWB+ 98]. This team consists of a heterogeneous set of robot-players, based on quite dierent components. We combined for example shooting-mechanisms and fast agile drives for an oensive type of player and a more precise drive-platform with good grip for a more defensive type of player. In addition to these electro-mechanical components, it is also possible to exchange sensor-systems and communication-facilities between the robots in a plug-and-play manner, or to add completely new ones.

3.1 Overview of the Architecture In order to have a very exible architecture we chose for an open bus system. As shown in g. 5 there is a global bus that comprises several sub-buses which are managed from dierent sources. The system is logically divided into 6 subsystems: 1. The processor subsystem contains the Motorola MC68332 microcontroller. It provides the address bus, data bus, special timing channels (TP), interrupt lines (/IRQ), several chip selects (/CS), an SPI bus and an ordinary RS232 serial bus. The capabilities of the processor are further described in subsection 3.4. Furthermore, a 1 MByte Flash-EPROM and a 1 MByte SRAM are included in this basic system. 2. The memory subsystem is separated from the processor because it then can easily be adjusted to the necessary size. In its maximum con guration, it consists of 13 10

Figure 4: The VUB AI-lab team at RoboCup'98

3. 4. 5. 6.

MByte of DRAM memory. The optional FPU subsystem provides a 25 MHz oating point unit.2 The extension busmaster subsystem provides two serial RS232 buses and two I2C buses for which a broad variety of sensors and actuators ICs are available. The I/O subsystem contains all the interfaces needed in our current control for the robots. The optional vision subsystem (discussed later in section 4) houses the FUGA15 vision chip and all necessary hardware support for it.

In the current setup, there are the following I/O extensions with their proposed use available:

 binary inputs and outputs: switches, bumper, LEDs, hardware encoding of the `name' of a robot.

2

There is also a 40 MHz version available, but at a rather high cost.

11

Data, Adr, /CS, /IRQ, TP, SPI, 2xI2C, 3xRS232

CPU Flash SRAM

DRAM

Extension Busmaster

FPU

Bin I/O

I/O Subsystem

Vision Subsystem

IR send

SPI ext TP ext

IR recv

Motors ADC/DAC UHFtrcv

Figure 5: Block diagram of the RoboCube architecture

 infrared transceiver: simple obstacle avoidance, slow data transfer  UHF transceiver: medium bandwidth data transfer (40 kBit/s, very small in size)  analog-to-digital converters: measurement of light intensity, magnetic and sound

sensors, ...  special connectors decouple the devices from the central control: { Motors: direct plug ins for motor controllers and shaft encoders { SPI: extension { TP: enables control of far away devices with possibly complicated timing

3.2 Features and capabilities The system boots out of a 1 MByte Flash-EPROM which holds a basic input/output operating system (BIOS) and oers space for a small le system. A huge part of the BIOS is dedicated to the ecient handling of dierent actuators and sensors. In the basic con guration the main memory consists of a 1 MByte low power SRAM. No wait states have to be generated for that type of RAM. With the 24 bit address bus, the main memory can be extended up to 16 MByte. Since 2 MByte are allocated by SRAM and EPROM and 1 MByte is reserved for the I/O-space, the DRAM subsystem allows 13 12

MByte of additional main memory. Only when the DRAM performs a refresh cycle, the access to it causes some wait states. But this will happen once every 200th processor cycle and thus, not slow down its performance. There are 3 types of serial buses in the system. Serial buses allow to bridge long distances and are usually simple to handle, but they oer normally only poor throughput. The main advantage here is the small number of wires. First of all, we have 3 standard RS232 serial busses. Hence, connecting a board to a host-computer is very simple. This is especially useful for debugging and downloading software at startup. One of the RS232 connections is dedicated to the UHF transmission system, which enables the communication to the board at run time. The microcontroller oers a synchronous serial bus | the SPI bus. The SPI bus is fully duplex and allows multiple bus masters. It has 4 address lines encoding the destination of the transfer. Two additional lines carry the data in each direction (from and to the master). The relatively large number of wires and the fact that only a few devices are available for this bus type make the SPI bus unattractive for general usage. Nevertheless, there is the interesting option to attach a 64 bit CCD line segment, which implements a simple visual perception module, via this bus. A very powerful bus is the inter IC bus from Philips (I2 C). It is a synchronous bus that uses only two lines. There are many devices available. The major features are:

   

multiple masters bidirectional operation hardware bus arbitration hardware bit and byte level synchronization. This gives a slow device the opportunity to adjust the transfer speed to its own capabilities and can force wait states during the transfer.  7 bit addresses  maximum 100 kBit/s On one of our I/O subsystem board based on the I2 C, there are 24 analog input, 6 analog output channels and 16 general purpose binary in/outputs available. The board uses only one of the implemented I2 C-buses. Thus, by stacking a second I/O subsystem board into a RoboCube, the above numbers can be doubled.

3.3 Physical layout One of the most striking features of the RoboCube is its size. With the size of 50mm x 60mm x 80mm, it is very small and compact. As you can see in gure 6 the vision 13

subsystem is connected with a at cable. This allows a exible mounting that can be panned or tilted. It is also possible to just stack the vision system on top, leading to a height of 60mm instead of 50mm.

CPU + MEM Ext Busmaster vision

I/O extension

Figure 6: Physical layout of the complete RoboCube This layout relies on two special facts. First, all ICs are in SMD packages. Second, we use a special stacking connector from AMP which builds the global bus perpendicular to the boards plane. Hence, the system can be very easily extended by stacking additional boards on top of the others. Finally, due to these two connector blocks the whole layout gets mechanically very stable and guarantees secure connections.

3.4 The Motorola MC68332 microcontroller The MC68332 is a 32-bit integrated microcontroller in our case running at 25 MHz, combining high-performance data manipulation capabilities with powerful peripheral subsystems. The subsystems work independently from the main CPU32 instruction processing unit, thus allowing for a high overall system performance. The two most striking features of the microcontroller are:

 the very low power consumption. It consumes a maximum of 150mA at 5V. Mea-

surements of the current of the whole processor board (including Flash-EPROM and SRAM) turned out a consumption of 60mA only. In standby mode, the processor is even speci ed for 0.1mA.  the time processor unit (TPU). 16 microcoded channels for performing time related activities from simple input capture or output compare to complicated motor control or pulse width modulation are provided.

On top of that, the controller also provides high speed serial communications by the queued serial module (QSM) with synchronous and asynchronous protocols available. Through a programmable module of chip selects attaching external modules is very easy. 14

With its internal 32-bit architecture this processor oers on the one hand a powerful processing unit. With the independent and programmable submodules which are specialized to control applications many tasks can be done directly by the processor. This allows for a very compact and powerful design of the control hardware.

3.5 The RoboCube's Basic Input/Output Operating System (BIOS) RoboCube's BIOS has a quite special design to address the speci c needs for robotic control, which is documented in detail in [Ver96]. Besides the usual BIOS functionality like serial I/O for program download and debugging, it provides the following additional core functions:

 Memory and process management  Access to sensors and actuators  Wireless communication interface management The BIOS consists of a multithreaded runtime environment, a set of low-level drivers for sensors and actuators and a protocol engine for radio communication. The multithreaded runtime environment uses a cooperative multitasking scheme to run several tasks in a rate-monotonic schedule. These tasks consist of system threads to service sensors and actuators and user threads.

3.5.1 Sensor/Motor-Access To have a simpli ed and uniform access to the dierent actuators and sensors, the a system thread regularly reads the sensors, preprocesses the sensor data and stores the results in its RAM. Due to the multithreaded nature of the BIOS, the application threads can access these values as a special type of local variable, a quantity, without any additional delay since the sensor values are already stored in memory. Since the actual read/write operations to the hardware occur within the rate-monotonic schedule and are triggered by a timer interrupt every few milliseconds, sensors are read out in well-de ned synchronized time intervals. This is especially important for reading out pulse accumulators to get well-de ned results. The actuators are updated the same way, also in well-de ned intervals. An important aspect is that RoboCube's on-board software core supports an easy handling of I/O-ports in combination with common sensors and motors. This means that it is possible to plug-and-play various components, which can be accessed in a high-level manner in software. RoboCube runs the Process Description Language (PDL) which combines C with special constructs facilitating behavioral control through networks of dynamical processes. 15

3.5.2 Wireless Communication The wireless communication interface provides reliable radio communication between several stations without any need for a designated master station. Stations can form ad-hoc network groups, called cells, in which they can communicate. Each station in a cell is identi ed by a unique number (ID). The data is transmitted in packets, which can be directed to only one other station (unicast), several other stations (multicast) or all stations in the cell (broadcast). At the moment, no routing is performed and all stations in a cell are assumed to be directly reachable. The radio communication protocol provides two communication channels, one for reliable stream communication and one for unreliable direct communication, comparable to TCP and UDP in the TCP/IP protocol suite. The reliable stream communication channel provides automatic retransmission of lost packets and proper packet reordering on reception. Since the protocol is only used for direct station-to-station communication, no adaptive windowing has been implemented. In a later version, adaptive windowing and multi-cell-routing could be implemented as well. Packets are CRC-checked upon reception and are discarded, if the CRC-check fails. Each packet in the reliable stream communication channel has to be acknowledged, non-acknowledged packets are assumed to be lost and will be resent after a timeout. To optimize the throughput of the communication channel without neglecting the reliability aspect, the protocol engine uses two methods for obtaining transmission right on the shared medium, Time Division Multiple Access (TDMA) and Carrier Sensed Multiple Access (CSMA). Each station has its own time slot for transmission, and each station tries to identify its proper timeslot by listening to packets from other parties, identifying their IDs and synchronizing the protocol's time slots. Then the station waits for its own timeslot. But before transmission really starts, the presence of a carrier is checked. If no carrier is present, then the station starts to transmit. If, however, the transmission gets interrupted by another station, a CRC mismatch will occur and the packet is discarded upon reception. The receiving station will not acknowledge that packet and the packet will be resent. If a packet-acknowledge is lost, the sender will send the well-received packet again, but the recipient will discard the packet because a packet with the same packet sequence number has already been received. The wireless communication interface has its own UART , interrupt service routine and server thread, therefore the communication is hidden from the application program, it only has to empty the receive queue from time to time. On the hardware side, the wireless communication interface is implemented with a Ra16

diometrix Bim433-F UHF Transceiver directly connected to the UART. This low power device can transmit half-duplex serial data with 40 kBit/s over about 30m and provides on-board carrier detection and signal decoding circuits. Although the protocol has been specially implemented for this architecture, it does not rely on any special features of the hardware. An implementation of the protocol engine for Windows 95 has for example been designed. This protocol engine serves as an application level gateway to the Internet.

4 Towards On-Board Vision Vision is an important and very exible mean of perception. This hypothesis is for example supported by the fact that roughly one third of the human brain is devoted to visionrelated activities. But so far, the use of vision in the small robots league of RoboCup is mainly restricted to global perception with an overhead camera, including all the negative side-eects as discussed in section 2. But exploiting the scienti cally important feature of on-board vision is very dicult within the small robots league due to the severe size constraints. Especially, the common technical approach of using a CCD-camera, a framegrabber, and a PC cannot be used within the given dimensions, even if special embedded solutions are considered. Therefore, we propose here a conceptual framework and technical implementation, the so-called VisionCube as augmentation of the RoboCube, which opens the potential of on-board vision for extremely compact systems. In doing so, we especially exploit the possibilities of the recent availability of C-MOS technology for image chips instead of CCDs. The main advantages are as follows. First, a C-MOS image chip roughly behaves like a ROM. Especially, no framegrabber-like part is needed. This simpli es the architecture signi cantly. The ROM-like behavior leads in addition to a second important advantage. The selective read-out of pixels is possible. Subsampling of the image therefore speeds up substantially. This is especially an advantage when combined with attentional mechanisms. A third advantage of the particular C-MOS image chip used in our design consists in its high dynamic range. In contrast to the linear sensitivity of CCDs or other C-MOS based image chips, cells of the FUGA15 measure light logarithmically. In addition, the output signal of a cell is an instantaneous measure of the photocurrent. Therefore, it is not necessary like in CCDs to adapt the exposure-time to the light conditions. The main disadvantage of using a C-MOS image chip is its need for a single-pixel calibration. But this can be implemented eciently in hardware without any time-loss during the read-out of pixel as explained later.

17

4.1 Simple Vision-Modules instead of Video-Transmission VisionCube is not intended to transmit complete raw or processed images (though this is possible) to other devices. Instead, it is designed to convert data-intensive visual input to low-dimensional information which is directly used to control various actuators. Within the last years the concept of active vision has emerged [AS89, Bal91, BY92, Alo93]. Roughly speaking, it is motivated by nature, regarding vision as part of a behavior-oriented system which is situated in an environment. Active vision is characterized by a close coupling between action and perception, the exploitation of cues and attentional mechanisms, and the absence of elaborated representations. It has proven to be very useful for the control of mobile robots [Hor93, KIR+ 94, RK95, BB97]. An important aspect of active vision is that it can help to cut down the amount of resources needed. Compared to other approaches extremely few computation power, memory, and image-data is needed on the hardware side. Instead of using complex models and algorithms, it is tried to exploit the most simple environmental constraints of the concrete application.

4.2 Exploiting the advantages of C-MOS imaging The main idea behind the VisionCube concept is the exploitation of the very special features of a particular C-MOS image-chip called FUGA15 from C-CAM. These features lead to several, signi cant advantages compared to CCD-based devices. The rst one is its huge dynamic range over 6 decades of light-intensity due to its logarithmic sensitivity ( gure 7). This makes the on-board control software for robot-players much less dependent on the particular light-conditions during a game or between dierent competitions and training phases. The second advantage is its ROM-like behavior. This aspect is of quite some importance for this article as it substantially in uences the underlying hardware architecture and the whole scheme of how the vision processing is done. It is not necessary, like in CCD-based architectures, to consecutively read the 512  512 pixel. Instead, an arbitrary number of pixels at arbitrary positions can be accessed. To exploit this feature, we introduce here the concept of subsampling windows (SSW): starting from an oset coordinate ( ), pixel are read from a rectangular frame with limits and in a certain resolution by stepping horizontally with width and vertically with width . Subsampling windows can be read on VisionCube with a single command which is supported in hardware. The time required in doing so is linear in the number of pixels read (see below). Note, that there is no limit in the number of SSW. All vision-modules running in (simulated) parallel on Vision-Cube can use arbitrary many SSW at arbitrary positions, with arbitrary resolution, size, and shape at the same time. By using SSW, attentional mechanisms can substantially speed-up the image processing xo; yo

xl

xs

yl

ys

18

Figure 7: A picture from a welding application as an example of the huge dynamic range of a FUGA15 C-MOS image chip. In comparison to a CCD chip, many more details can be seen in the image as the FUGA15 reacts logarithmically to the light intensity. (Pictures with courtesy from C-CAM) already at the very rst step: the image-snap. Figure 8 shows some possibilities to pro t from SSW. Overview sampling exploits the possibility to horizontally and vertically skip pixel. This establishes a kind of software zoom. When surveying for example a part of the play- eld, it is sucient to sample with low resolution to detect a moving object with dierence-images. If a motion is detected, a vision-module can be activated that uses an area of interest which is placed on the related location in the image. This small window of high resolution can then be used to process image-data to check if the object is the ball, an opponent or a team-mate.

4.3 Performance of the vision subsystem A detailed description and evaluation of the vision subsystem can be found in an internal technical report [BKW98]. In short, the CMOS imager chip is directly mapped into the address space of the CPU, thus can be accessed directly. The subsystem provides a RAM for pixel calibration and some additional control registers to support a fast burst read out of a row of the imager with a exible step width. The detailed evaluation of the number of cycles needed to read out a window of times pixels with an arbitrary step width results in the following formula: nx

ny

readout  [(ny ? 1)
(39 + (nx ? 1)
9) + 35]
1=fsystem

T

19

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7

512

Overview Sampling example: read_ssw(0,0,512,512,2,3)

= pixel read out

...

512

read_ssw(xo, yo, xl, yl, xs, ys)

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7

512

Area of Interest example: read_ssw(2,3,5,6,1,1)

xo yo xl yl xs ys

horizontal offset vertical offset horizontal limit vertical limit horizontal step-size vertical step-size

...

512

Figure 8: Subsampling of the FUGA15 saves signi cant time as this C-MOS image chip behaves roughly like a ROM. This can be used to build very ecient visual modules based on a single command reading rectangular frames with arbitrary position, size, and density.

20

With this formula, it is easy to determine the main part of the access time for several standard situations, namely:

 an overview sampling window, e.g., a window of 512  512 pixels with a sampling

width of = = 8.  a set of 8 subsampling windows, each with 64  64 pixels and a sampling width of = = 4.  read out of the complete vision chip, i.e., 512  512 pixels. xs

xs

ys

ys

Table 1 shows the resulting gures. Situation readout overview sampling 64 64 1.5ms 8 subsamples 128 128 6.0ms total read out 512 512 94.8ms nx

ny

T

Table 1: Access times for various situations The correspondent number of pixels per row and the number of rows to read is given in column respectively . The last column gives the time spent in the main loop of the driver command to read out a window. As you can see out of table 1 even with this low end CPU (compared to modern PCs with framegrabber extension cards) it is possible to read out 10 complete frames per second. Of course, the CPU is in this case completely busy with the read out. But reducing the window of interest to a reasonable size or doing overview sampling, the speed increases dramatically. Together with a oating point unit and a large main memory, even complex and sophisticated control programs can be implemented and eciently executed. nx

ny

4.4 Related Work Up to our knowledge, there is only very few directly related work. The current trend in vision in respect to hardware is to rely on the combination of a PC, a framegrabber, and a camera as a more or less low-cost solution, or to develop high-performance dedicated hardware on the other end of the scale. Nevertheless, an approach somewhere similar to ours has been done by Horswill and Masaki Yamamoto [HY94]. The main similarities to our work are their intension to provide an inexpensive active vision device and the usage of a Motorola MC68332 microcontroller as the computational core. The main dierences between both approaches are as follows. 21

First, the system of Horswill and Yamamoto is a stereo vision device, i.e., it consists of two cameras mounted on pan-tilt units each. Though stereo vision is of quite some scienti c interest, especially for basic research in active vision, it somehow limits possible practical applications of the device, especially within RoboCup's small robots league. The second and main dierence between the two approaches is the exploitation of C-MOS imaging technology for the VisionCube in contrast to the CCD-based Horswill-Yamamoto-system. The advantages of C-MOS image chips have been mentioned before, but they are even more clear in direct comparison with the other system:

 The Horswill-Yamamoto-system has to read-out complete frames. Therefore, a lowresolution 192  165 black-and-white CCD is used. VisionCube can address sin-

gle pixel. Therefore, the resolution (of the image chip) is no bottleneck. A highresolution 512  512 colored image3 is provided.  The framerate of the Horswill-Yamamoto-system has to be adapted to the lightning conditions as CCD-chips integrate over time. This constraint does not hold for VisionCube as a C-MOS pixel is realized as a direct measure of the photocurrent. In addition, the dynamic range is signi cantly larger as the particular chip we use has a logarithmic sensitivity.  The timing-signals of the CCD in the Horswill-Yamamoto-system are computed by the MC68332 microcontroller. In doing so, at least the control of exposure-time is an additional overhead which consumes valuable processor-time.

5 Conclusion In this article, we argued that the Small Robots League of RoboCup has a very promising potential but that it also bears some pitfalls due to its two major properties, namely its severe size-constraints and the toleration of global sensing. We reasoned that among other positive aspects, these two properties especially foster the investigation of team behavior. On the negative side, these two features suppress the important investigation of on-board features for the players. We argued that without on-board features, the small robots league could degenerate into a \string-puppets"-competition, where radio-controlled toy-cars instead of robots are controlled in very simple, but fast vision-based closed-loops with an overhead camera. This scenario would be of only very limited scienti c interest from both a basic research as well as from an application-oriented viewpoint. Team approaches including on-board features for the players provide in contrast a multitude of scienti c issues, especially in respect The FUGA15 is supplied either as 512  512 grayscale sensor or in a second version with RGB-masks placed in a strip-pattern on the cells. Both versions can be used in the VisionCube. 3

22

to robotics, AI and related disciplines, as well as the the emerging technological eld of autonomous systems as networked embedded devices. Of course, the implementation of on-board features is far from being the only important research issue of RoboCup. But we see some potential risks, that without an encouragement from the organizers and a fruitful scienti c discussion between participants on this issue, the small robots league might miss some promising opportunities. Only through a joint eort, it will be possible to overcome the pitfalls and to mutually bene t from the positive potential of the limited size requirements in this league. As our contribution to a fruitful exploitation of on-board features, we developed the RoboCube system, which we continuously keep on improving. In this article, we present the most recent version of this \universal" \special-purpose" robot-controller. It is somehow universal as it allows an easy and exible construction of a multitude of players. For this purpose, the RoboCube provides quite some computation power and memory as well as a multitude of I/O-interfaces. It is at the same time a kind of special-purpose solution as it is tailored to t the particular needs and constraints of the small robot league. It facilitates the use of many sensors and eectors, including the support from its BIOS to access them in high-level programs. Concretely, RoboCube has a open bus architecture which allows to add \in nitely" many sensor/motor-interfaces (at the price of bandwidth). But for most applications, including playing soccer, the standard set of interfaces should be more than enough. RoboCube's basic set of ports consists of 24 analog/digital (A/D) converters, 6 digital/analog (D/A) converters, 16 binary Input/Output (binI/O), 5 binary Inputs, 10 timer channels (TPC), 3 DC-motor controller with pulse-accumulation (PAC), and a wireless 40 kBit communication channel. As mentioned before, the access to these ports is supported for high-level programming languages, especially C. In addition, software modules exist to ease the direct usage of complete sensor- and eector-systems, like e.g. for motion-control. In addition to the basic RoboCube, we presented here the option to enhance the system with high-resolution vision to the so-called VisionCube. This design exploits the possibilities of a completely new technology in imageing based on C-MOS chips, which leads to several advantages. The most striking advantage, the particular imager used in our design roughly behaves like a ROM. Unlike CCDs where a complete frame has to be read, a selective read-out from the 512512 colored pixels is possible. This can be done very fast, in time linear in the number of pixels, saving in addition memory and processing costs. For this purpose, the VisionCube features subsampling windows, which read-out an arbitrarily shaped rectangle from an arbitrary position of the imager. Subsampling windows are dynamic, they can be moved, changed, created, and deleted at any time. Concretely, the read-out of a complete frame would take roughly 100 msec. The (virtual) parallel read-out of 8 subsampling windows, each of 6464 pixels and a sampling density of 4, takes only 6 msec in total. This makes makes the challenging option of local vision with on-board processing feasible as attentional mechanisms and a exible size and resolution 23

of the image can be used to adapt the speed and accuracy of the vision to the particular needs and constraints.

Acknowledgments Many thanks to all current and former members of the VUB AI-lab, especially Dany Vereertbrugghen who developed the SMBII. Research on the RoboCube is partially funded with the TMR-grant \Development of an universal architecture for mobile robots" (ERB4001GT965154). The VUB AI-Lab RoboCup team thanks Sanders Birnie BV as supplier and Maxon Motors as manufacturer for sponsoring our motor-units.

References [Alo93]

John Yiannis Aloimonos, editor. Active Perception. Lawrence Erlbaum Associates, 1993. [AS89] John Yiannis Aloimonos and David Shulman. Integration of Visual Modules, An Extension of the Marr Paradigm. Academic Press, 1989. [Bal91] Dana H. Ballard. Animate vision. Arti cial Intelligence, 48, 1991. [BB97] Tony Belpaeme and Andreas Birk. On the watch. In Proceedings of the 30th International Symposium on Automative Technology and Automation, 1997. [Bir99] Andreas Birk. Autonomous Systems, The Theory and Technology of Networked Embedded Devices, Mobile Robots, Intelligent Sensor Motor Control, and Active Vision. in preparation, 1999. [BKW98] Andreas Birk, Holger Kenn, and Thomas Walle. Visioncube, an intelligent autonomous vision device. Technical Report MEMO 98-01, Vrije Universiteit Brussel, AI-Laboratory, 1998. [BWB+ 98] Andreas Birk, Thomas Walle, Tony Belpaeme, Johan Parent, Tom De Vlaminck, and Holger Kenn. The small league robocup team of the vub ai-lab. In Proc. of The Second International Workshop on RoboCup. Springer, 1998. [BY92] Andrew Blake and Alan Yuile, editors. Active Vision. MIT Press, Cambridge, 1992. [FK97] Masahiro Fujita and Koji Kageyama. An open architecture for robot entertainment. In Proceedings of Autonomous Agents 97. ACM Press, 1997. 24

[Hor93]

Ian Horswill. Polly: A vision-based arti cial agent. In Proceedings of the Eleventh National Conference on Arti cial Intelligence. AAAI, MIT Press, 1993. [HY94] Ian Horswill and Masaki Yamamoto. A $1000 active stereo vision system. In IEEE/IAP Workshop on Visual Behaviors, 1994. [KAK+ 97] Hiroaki Kitano, Minoru Asada, Yasuo Kuniyoshi, Itsuki Noda, and Eiichi Osawa. Robocup: The robot world cup initiative. In Proc. of The First International Conference on Autonomous Agents (Agents-97). The ACM Press, 1997. [KIR+ 94] Y. Kuniyoshi, M. Ishii, S. Rougeaux, N. Kita, S. Sakane, and M. Kakikura. Vision-based behaviors for multi-robots cooperation. In IEEE Int. Conf. on Intelligent Robots and Systems, 1994. [KTS+97] Hiroaki Kitano, Milind Tambe, Peter Stone, Manuela Veloso, Silvia Coradeschi, Eiichi Osawa, Hitoshi Matsubara, Itsuki Noda, and Minoru Asada. The robocup synthetic agent challenge 97. In Proceedings of IJCAI-97, 1997. [Mir] The micro-robot world cup soccer tournament (mirosot). http://www.mirosit.org. [RK95] J. Riekki and Y. Kuniyoshi. Architecture for vision-based purposive behaviors. In IEEE Int. Conf. on Intelligent Robots and Systems, 1995. [Ver96] Dany Vereertbrugghen. Design and implementation of a second generation sensor-motor control unit for mobile robots. Technical Report Thesis, Tweede Licentie Toegepaste Informatica, Vrije Universiteit Brussel, AI-lab, 1996.

25