A Prototype of a Low-Cost, Downsizeable, Dynamically Reconfigurable Unit for Robot Swarms

Lluís Ribas

Microelectronics and Electronic Systems Department Universitat Autònoma de Barcelona

08193 Bellaterra, Spain Email: Lluis.Ribas@uab.cat

Miquel Izquierdo, Jordi Mujal, Eloi Ramon HW/SW Prototypes and Solutions Lab. (CEPHIS)

Universitat Autònoma de Barcelona 08193 Bellaterra, Spain

Email: {Miquel.Izquierdo, Jordi.Mujal}@campus.uab.cat, Eloi.Ramon@uab.cat

Abstract—Swarm robotics deals with emergent behavior of a collection of robots. These robots must be cheap and small in order to make it feasible to have a swarm out of them. In this work we present a prototype for one of such robots with emphasis on communication and processing capabilities. The result is a flexible, reconfigurable, dual-processor robot that could be used in physical modeling of robot swarms. The built prototype shows that further implementations can be easily downsized and inexpensive.

I. INTRODUCTION

Robot swarms might be used in a number of applications in the future, from agriculture to biomedicine. Differently from robot teams [1], a robotic swarm [2] may consist of hundreds or more units. The robots are simple and usually exhibit the same behavior, though when considered as a whole a complex, more sophisticated one may be observed. This is a form of “emerging” behavior that is of interest in order to validate the system with respect to a given application.

The development of such systems mainly relies on simulation because of the high cost of building physical, real ones.

However, simulation entails some problems that stem from both the difficulty of providing the system model with appropriate, complete set of stimuli, and the hidden flaws of the model itself, mainly due to abstractions of the real environment.

In order to partially overcome these drawbacks, a prototype of a real system should be built. For the sake of cost, it would usually consist of only a portion of the number of robots of a true system. Moreover, the robots themselves might be simplifications of true ones, either by using scaled (down or up) ones, by being made of off-the-shelf components, by using different and restricted sensors and actuators, or by a combination of these and other points.

This form of emulating robotic swarms is by no means much better than simulation by software but for the point of giving the developers a strong feeling of how the system might be and what type of problems might occur in reality.

There are many research groups that have built such robots for that purpose (e.g. [3], [4], and [5]), many of them relying

on tiny robots that do not require large areas to operate, others on commercially available mini-robots so to greatly diminish the total cost.

In this work, we have developed a prototype of a low-cost robot that might be used for, again, prototyping robot swarms in a wide range of application targets. (Note that the prototype itself is not intended to be low-cost.) The prototype of this mini-robot is built upon commercial off-the-shelf components (COTS) put together with a simple framework out of Meccano pieces. It contains two PCB, one for the RF communications and reconfiguration of the robot, and another to control the motor and the sensors. Therefore it has two processors (two Microchip PICs) so normal control of robot operation is not interfered with communications processing workload. The cost of the resulting robot is comparable to that of many commercially available mini-robots but can be drastically cut by building a single board one. The latter is, in fact, the target unit we have built the prototype of.

The paper is organized as follows. The next section describes the robot architecture in which there is a strong division of tasks among its elements. The communication and reconfiguration part is discussed afterwards. Then, the positioning mechanism is detailed. As the robot can be added a variety of sensors, only a basic configuration is described in section V. The resulting robot and the discussion about this work are presented in the concluding section.

II. ROBOT ARCHITECTURE

The goal of building such a prototype of a mini-robot is to prove the validity of the approach before implementing units that can be used to prototype robotic swarms. For the latter reason it is required to have a programmable robot that enables emulation multiple behaviors.

The robot architecture has been designed to satisfy a series of requirements ranging from providing the designers with a framework with easy reprogrammability to allowing mimicking real swarms at a reasonable cost.

A. Reprogrammability The controlling algorithm of the robot has to be easy to

change. Many microcontrollers have Flash memories that can

21671-4244-0755-9/07/$20.00 '2007 IEEE

be updated via serial ports (typically, a RS232 port, but, more recently, via USB) of the boards where they are mounted on. The relatively large number of robots and, during development, the number of changes might turn this task into a quite heavy one. Therefore, we have also considered the possibility of wireless programming. In this framework, all robots can be programmed in a single session.

In sum, there are two forms of programming a robot. 1) Wired Programming: By using the serial port of the board

of the main microcontroller of the robot. 2) Wireless Programming: Using a second board with RF

communication capabilities and a second microcontroller with a fixed program it is possible to do the job. This microcontroller receives a message with an order to program the first board and the corresponding data-stream. Then, it proceeds to program the main microcontroller in the conventional, “wired” manner.

B. Wireless Communications The robots in swarms might communicate among them

explicitly or implicitly, through the environment (stigmergy). Besides, for monitoring and remote control operations, it is interesting to have the possibility to communicate with the robots from a sort of “base station”, especially during system development.

Though the architecture should allow explicit communication among robots and between them and the base station, normal operation of the system requires minimizing RF communications to reduce the overall workload and to content power consumption. (A technique might be to use indirect communication through the environment.)

C. Positioning Subsystem The positioning subsystem is in charge of moving the robot

from one point, the reference, to another, the destination, in a plain surface. There are a number of different mechanisms to provide robots with mobility.

Articulated limbs require complex control algorithms while wheel-based systems appear to be simpler. In our case, we assume that robot can move from one point to another with enough precision as to the application.

Accurate positioning systems are usually more expensive than rough ones. Given that the idea of the robot is to serve as a scale prototype for the real robot and, what is more, that it may use different devices to move around, it sounds reasonable to overlook the lack of accuracy. In fact, as we shall see later, we have opted for a single-motor approach, even it does not allow a fine positioning.

D. Concurrent Robot Control The robot must have enough computing power to control all

operations of the robot, from communications to sensor data processing. On the other side, cheap solutions are looked for.

A dual-processor architecture enables concurrent control tasks be executed on the robot. One processor is in charge of executing application independent tasks such a communication or movement related ones, while the other is devoted to

execute application-dependent tasks, which include sensor and actuator (if there is some) control. In short, there is one processor for the system tasks and another for the users, i.e. for those which depend on the use of the robot, and that can make use of the system routines.

As a result, the robot is controlled by concurrent processes, which enables more flexible operation. For instance, it can sense some information while sending previously acquired data.

Fig. 1. Architectural view of the mini-robot.

III. COMMUNICATIONS AND RECONFIGURABILITY

To meet the objectives set for the robot prototype, communications and reconfigurability have to take into account, among others, price and autonomy (mobility and “intelligence”). Mobility imposes the use of low-power solutions to maximize battery duration, which clearly favours a low-range RF communication such as Zigbee. (This protocol, based on IEEE 802.15.4 standard [6], has been chosen because one of the creator objectives [7] has been, precisely, to be low-power.) PIC microcontrollers ([8], [9]) have also been chosen because of their contended power consumption, of their broad availability, and of being among the cheapest.

We have used the Microchip PICkit 2 and PICDEM Z [10] development kits. The latter includes the Zigbee transceiver, which is the Chipcon’s CC2420 [11], the PIC 18LF4620 [12] and the correspondent motherboard. Moreover Microchip offers for free its Zigbee stack [13].

The communication between the transceiver and the MCU0 (the microcontroller that is in charge of the communications and of the positioning) is done by SPI interface [14]. MCU0 also communicates with the “user” microcontroller (MCU1) through USART interface [15] to offer wireless communication and motion services to it.

The USART interface implies that two connections between the microcontrollers must be done, as shown in fig. 2, both are for data because USART is configured in mode asynchronous and full-duplex.

MCU0 can only be programmed on board, while MCU1 (the microcontroller for the user’s application) can be both directly programmed or through the MCU0. The basic idea is that the

2168

latter will do so when it receives RF data encoding special “programming instructions”. This very mechanism enables re-programming of a large number of robots in a single session.

The MCU0 is connected to the ICSP (In-Circuit Serial Programming) [16] utility pins of the MCU1. When it receives the “program instruction” code, it changes the MCU to a programming state through its corresponding I/O pins. After setting the program power on, it waits for the new program code to come and, as it comes, it is fed to the data pin of ICSP. The programming is halted when the code stream is finished and an “end program” instruction code is received. Then, the MCU0 forces the MCU1 to return to its execution mode.

As seen above, the MCU0 provides the RF communication services to the MCU1. Incoming data is filtered in the MCU0 so special programming instruction codes and subsequent data is not fed to the MCU1. Instead, these codes are used to program the MCU1 and reconfigure some setup data of the MCU0 (not in the current version). Later on, we shall see that the MCU0 holds the positioning service routines.

To sum it up, the MCU0 has two modes of operation. In the programming mode, it programs the MCU1 with the program code that receives from de Zigbee transceiver. In the “service” mode, it lets the MCU1 to communicate with the RF transceiver and to use other service routines related to positioning. It “swings” from one to another when special codes (to mean “begin programming” and “end of programming”) are received.

IV. POSITIONING SUBSYSTEM

The development of a prototype for a low-cost robot requires careful evaluation of the different options available for the locomotion system ([17], [18], [20], and [21]) which enables it to move throughout its environment, especially because motors and its associated mechanical and electronic components are usually the most expensive part of any such mini-robots.

To reduce the cost we have considered a three-wheeled locomotion system that only needs one motor to reach any position on the plane.

For the sake of simplicity and development rapidity, we have chosen a well-known servomotor [19] from Futaba, which in a

single package also includes the gearbox and the servo control circuitry, allowing an easy control from a microcontroller with PWM. (The final version of the mini-robot should carry a cheaper, smaller motor, though.)

The system (see fig. 3) is based on the common tricycle ([17], [18]) but modified in such form that the movement is constrained to a sinusoidal form [22]. The steering wheel (number 3 in fig. 3) is connected to the driving motor (number 6) so it can turn either direction. This turning causes the whole to move to either mechanical stop (7). When the wheel is turning against it, it pushes the stop so that the tricycle turns to the corresponding side. Appropriate selection of geometrical parameters enables the vehicle to move forward in a waving fashion by alternating the motor spin.

The kinematics of this system is more complex and the motion is not so optimal than other systems like differential drive [23], which needs two motors. However, it can contribute to the robot’s cost cut significantly on the final unit. (The cost of the COTS-based prototype does not vary notably.)

A secondary objective is to have a simple control algorithm for the servomotor of this “waddling” tricycle, hence named “waddlebot”. If the algorithm is simple enough, it can be partially located in the MCU0, abstracting the application with cumbersome details.

The controlling algorithm is in charge of setting appropriate control values for the servomotor so to drive the waddlebot to the destination point, given in polar coordinates (r, θ ). It is divided into two steps:

1) Angle correction. It moves the robot to deviate it θ degrees from the straight course and recalculates r so to take into account the turning. This calculation is not trivial and an approximation is required for the MCU to get the appropriate control signals.

Fig. 2. Interconnection between MCU0 (the programmer) and MCU1.

Fig. 3. Tricycle platform of the mini-robot (schematic view).

2169

2) Forward movement. After the first step, the robot must go forward until the destination is reached. As it cannot go straight ahead, it calculates the sinusoidal wave that must follow to reach the end of segment (r, 0); i.e., the wavelength and the number of cycles. Once they are calculated, the related control signal waveform of the motor is derived from equations that involve the geometry and features of the robot and the servo. The resulting waveform is a simple frequency modulated square wave that the microcontroller has to transmit to the servo by the PWM. The result is a sinusoidal motion.

This algorithm allows an easy movement control to the users, which are only concerned about the particularities of this kind of motion in its environment and its repercussions.

Besides, it can be used for composite robots that snake or to control multiple winging devices, provided that they describe a sinusoidal movement [21].

To the work’s goal, this approach meant a significant reduction of the robot cost at the expense of some complexity in the controlling algorithm and in the performance (the distance covered and the extra power consumption to follow the sinusoidal path with respect to linear runs).

The complexity of the control program arises from the number of products, divisions, and other operations like sinus or modulating the PWM signal with a frequency variable squarewave function. (We have approximated sinus with linear equations.)

The other handicap is about performance in terms of distance and power consumption. If we compare the larger space covered by the waddlebot with a robot with differential drive locomotion, we have that, to cover a distance r, the latter is running both motors during 2r, because they are moving on a straight line.

On the other side, the waddlebot, due to the sinusoidal motion, covers a distance l that depends on the amplitude of the sinusoidal motion with the parameter α as shown:

rl )sin/( αα= , with ]2/,0[ πα = , (1) where α is the maximum angle of the robot direction

(determined by segment L in fig. 3) with respect to the straight line towards the destination point, and is related to the amplitude of the motion.

A brief study of the motor speeds covering the same distance with the same time shows that the relationship between the waddlebot’s motor speed ωw and the ωd of both motors of differential drive is:

dw kωω = , where αα sin/2=k (2) As a consequence, the amplitude of the motion is

constrained to values where α is low and then the speed of the motor required is lower. In practice, we can use α with k nearly to 2.

This affects power consumption ([17], [22]) as shown: mre PPP += , (3) where:

=eP electrical (battery) power,

=== τωFvPm mechanical (output) power, (4) ≡τ motor torque, and

== RIPr2 power loss in resistor. (5)

For a differential drive mechanical output: ddmdP ωτ2= . (6) For the waddlebot system: wwmwP ωτ= . (7) because of one motor moves the same robot that both, dw ττ 2= (8) and replacing (8) on (6) and (7): mdmw kPP = (9) for the power losses in resistor, the motor’s torque depends

only on the current I:

τ

τk

I = (10)

≡τk torque of the motor

Fig. 4. The relationship k between angular speeds of both types of movement (ωw = k·ωd) depends on the motion amplitude α.

2170

replacing for both systems (10) on (5):

Rk

P drd

2

2

=

τ

τ

rddw

rw PRk

Rk

P 24222

=

=

=

ττ

ττ

finally: rdmdew PkPP 2+= (11) The final result shows that for the same distance covered in

the same time the power consumption of the waddlebot is, at least, the double than the one of a differential drive system. Moreover, it depends of the amplitude of the sinusoidal form with k, which, means that they should be used motions with low amplitudes.

The former discussion, however, assumes that motors are efficient. In the case of the Futaba servos, the most power is devoted to overcome internal friction. Therefore, the waddlebot prototype is not that worse as depicted.

(There are conditions, e.g. steep ramps, when the straight movement requires large forces, i.e. torques, and a sinusoidal one performs better.)

V. BASIC SENSOR CONFIGURATION

In this section, we shall discuss about a simple sensor configuration of the waddlebot that enables it to move around and do some elementary tasks.

The sensors are chosen to fulfill these criteria: not to increase much the cost and be able to foster non-contacting mobility, i.e., to make it easy to do obstacle avoidance.

Among the huge variety of sensors that exist in the market, one of the cheapest are IR ones. (Ultrasound sensors had been discarded because of price and the complexity to use them, but can be embedded into the robot, added to the basic configuration.)

In the waddlebot, there will be up to four IR LED/sensor pairs, as shown in fig. 5. The location of the sensors on the robot may take into consideration the type of movement that follows. For example, the robot does not move backwards and, consequently, it might not be necessary to have a sensor looking to that direction.

The movement is basically from side to side, so it is important to put sensors at both sides of the robot and, at least, one sensor must be placed at the front of the robot, not only for the lateral movements, but also for the forward movement and other detection utilities. For example it can be used as a radar-like sensor, provided that the MCU1 is programmed to collect the data during a swing of the robot.

As the robot is designed to be used as a platform to model swarm robots, it has a free prototyping area to add new sensors and, eventually, some actuator. The MCU1 has some digital inputs/outputs ready for that intention. Moreover, there are some unused ADCs which can be used in the user’s application. (Also there are free DACs to use with actuators.)

The possibility of adding more sensors creates a great number of variations that can be applied to one robot. Moreover, if each robot has different sensors, there will be a huge quantity of possible combinations. So if the swarm needs some specific datum from the environment, it will have at least one of its members with the appropriate sensor and the ability to communicate to the others that piece of information and to ask another member to act with a some actuator to do a certain job.

VI. RESULTS AND CONCLUSIONS

Researchers on robot swarms envisage a variety of interesting applications. The development of such systems requires simulation and prototyping. The latter allows designers to have a feeling of how they perform in realistic environments.

In this work we have developed a robot out of commercial off-the-shelf components to prototype a mini-robot suitable to serve as a scale prototype of a swarm. As such, we have used commonly available components while preserving maximum adaptability of the resulting unit. Hence, reprogrammability had been an important issue. Therefore, besides standard programmability through serial interface, the robot includes the wireless programmability option. The latter feature enables robotic swarm developers to easily program the whole and to include dynamic reconfiguration characteristics in the resulting system.

The robot prototype uses a PICDEM Z (75€) and a PICkit 2 (50€) boards from Microchip, a Futaba servomotor (15€), some Meccano pieces (15€ for a 2-model kit), and a few sensors (not counted here). Hence, totaling 155€, approximately. The advantages of using COTS parts basically stem from the fact of allowing a rapid development. (The actual prototype had been

Fig. 5. Basic sensor distribution in the waddlebot.

2171

built in less than one month, not including the development time of the embedded software.)

The waddlebot prototype uses only a servomotor and a few IR emitter/sensor pairs so to enable building final, single-PCB versions of small size and at a low price. (Notice that the sum of the parts for the prototype is 155€ retail price, which indicates that a self-developed one might be built on components whose price sum far below that price. The cost of material for a mini-robot based on this prototype is, therefore, comparatively low.)

The use of a single driving-wheel mechanism has implied to use a non-conventional motion for the robot, which waddles its way to every destination. Both, the vehicle mechanics and the controlling algorithm are patent pending.

We have also shown that the waddling can be done with some power consumption overhead with respect to the differential drive system on plain surfaces, but that it can be kept under a tight bound if the sinusoidal trajectory has low amplitude.

The single motor control and the RF communication programs are included in the microcontroller of the PICDEM and the rest of the robot control should be put on the second MCU, which is in the PICkit 2 board.

Wireless communications not only can be used to program the second MCU but also to give the robot the capability to communicate with its mates.

The prototype of the waddlebot shall be used as a reference for a lower-cost unit done on a single, specific PCB, and to develop the appropriate programming framework for the latter. We expect to have the single board waddlebot in the near term.

ACKNOWLEDGMENT

This work has been supported by the Spanish Ministerio de Educación y Ciencia project no. TEC2005-08066-C02-02,

“COCOABOTS: Colonies of collaborative autonomous robots. Methods and tools.”

REFERENCES [1] T. Balch, and L.E. Parker (editors). Robot teams. From diversity to

polymorphism. A. K. Peteres, Ltd., MA (USA), 2002. [2] E. Bonabeau, M. Dorigo, and G. Theraulaz, Swarm Intelligence. From

Natural to Artificial Systems. Oxford University Press., USA, Sep. 1999. [3] G. Caprari, and R. Siegwart, “Mobile Micro-Robots Ready to Use:

Alice.” In Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS’2005) Canada, 2005.

[4] Grabowski, R., Navarro-Serment, L. E., and Khosla, P. “Army of Small Robots,” Scientific American, November 2003.

[5] Mondada F., Guignard A., Bonani M., Floreano D., Bär D., Lauria M. “SWARM-BOT: From Concept to Implementation.”, In Proceedings of the 2003 IEEE/RSJ International Conference on Intelligent Robot and Systems (IROS’2003), pp. 1626-1631, 2003. IEEE Press, Piscataway, NJ, USA.

[6] IEEE 802.15 WPAN™ (TG4), IEEE Standard 802.15.4. [Online]. Available: standards.ieee.org/getieee802/download/802.15.4-2003.pdf

[7] “3. What is the goal of the ZigBee Alliance?.” In Zigbee FAQ. Zigbee Alliance. [Online]. Available: http://www.zigbee.org/en/about/faq.asp#3

[8] J. Angulo, S. Romero, and I. Angulo, Microcontroladores PIC. Diseño práctico de aplicaciones. (Segunda Parte: PIC 16F87X.) McGraw-Hill/Interamericana de España, Madrid, 2000.

[9] Microchip Homepage. (2006, April). Microchip Co. [Online]. Available: http://www.microchip.com

[10] Picdem Z documentation. (2006, April). Microchip Co. [Online]. Available: http://www.microchip.com (part=DM163027-2).

[11] CC2420 Product Information and Documentation. Chipcon AS. [Online]. Available: www.chipcon.com/index.cfm? kat_id=2&subkat_id=12&dok_id=115

[12] PIC 18F4620 Datasheet. Microchip Co. [Online]. Available: ww1.microchip.com/downloads/en/DeviceDoc/39626b.pdf (Apr. 2006)

[13] Microchip Stack for the ZigBee™ Protocol Document AN965. Microchip Co. [Online]. Available: http://ww1.microchip.com/downloads/en/ AppNotes/00965a.pdf (Apr. 2006)

[14] PIC 18F4620 Datasheet SPI Mode Microchip Co. [Online]. 17.3 pp. 161-169. Available: ww1.microchip.com/downloads/en/DeviceDoc/ 39626b.pdf (Apr. 2006)

[15] PIC 18F4620 Datasheet Addressable USART Microchip Co. [Online]. 21 pp. 429-455. Available: http://ww1.microchip.com/downloads/en/ DeviceDoc/39626b.pdf (Apr. 2006)

[16] PIC 18F4620 Datasheet In-Circuit Serial Programing [Online]. 23.7 pp.266. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/ 39626b.pdf (Apr. 2006)

[17] J.L. Jones, A.M. Flynn, and B.A. Seiger. Mobile robots. AK Peters, Ltd, 1999.

[18] K. Goris. Autonomous mobile robot mechanical design. PhD thesis. 2005. [Online] Available: mech.vub.ac.be/multibody/final_works/ ThesisKristofGoris.pdf

[19] R. Arrick. The difference between stepper motors, servos, and RC servos. [Online] Available: www.Robotics.com

[20] Karl Williams. Amphibionics. Build Your Own Biologically Inspired Robot. McGraw-Hill.2003.

[21] K.J. Dowling. Limbless Locomotion: Learning to Crawl with a Snake Robot. The Robotics Institute, Carnegie Mellon University. 1997. [Online] Available: www.solarbotics.net/library/pdflib/pdf/ limbless_locomotion.pdf

[22] J. Mujal, M. Izquierdo, E. Ramon, Ll. Ribas. “Sinusoidal movement control of single-driving wheel, tricycle robots”, in Proceedings of the 9th International Conference on Climbing and Walking Robots and the Support Technologies for Mobile Machines (CLAWAR). Sept., 2006.

[23] Jizhong Xiao. Motors and Control (lecture). Department of Electrical Engineering,City College of New York. [Online] Available: http://www.ee.ccny.cuny.edu/www/web/jxiao/motor.ppt

Fig. 6. The prototype of the waddlebot without sensors.

2172