To fulfil the robot functionality, some on-board modules are necessary to guarantee that the robot will work. Therefore some sub-tasks have been described which depend on the following issues:

• Onboard powering
• Locomotion Unit
• Onboard electronic
• Communication Unit

Furthermore, software and algorithms are necessary for the scenarios we want to examine as well as the implementation of the functional drivers, i.e. for the locomotion, into the electronic hardware.

Onboard Powering:

Providing and distributing the maximum power with the minimum volume on the robot is the main challenge of this task. This power is needed for on-board electronics to properly drive the robot, use the novel tools and communicate with other robots in the swarm. In this context, heat management is important for both energy saving and avoidance of detrimental effects on system components. This task concerns not only the power generation and transmission but also the proper interface to the on-board circuitry. Two approaches are available for wireless powering the micro robots:

• Independent on-board power, and
• Wireless power transfer.

Because an on-board-power module was not developed due to constraints in resources, the decision for using external powering via wireless power transport was the right choice. Thinking about this technology, power can be wirelessly transferred with magnetic coupling, electromagnetic wave (micro-wave, solar cell, etc.) transfer, heat-powering and kinetic energy conversion. Some experiences from the past micro-robot project MiCRoN showed the possibility of transferring about 2 W power by means of an alternating magnetic field (coupled coils). The latest development showed the possibility of transferring stable power within a working area of 25 x 25 cm2. However, in this situation, the transferred power did not exceed 200 mW. The big problem of this method is the strong alternating magnetic field causing strong interferences in the robot's electronics. Additionally, the transfer efficiency is easily influenced by large metal surfaces on the robots through eddy current in the metal material. The use of micro-waves as a medium for power transfer was realised and 450 mW of power was transferred, but the focus of the micro-wave beam must be well controlled.

The best solution was the usage of on-board solar cells with a very high efficiency. The present technology could ensure 0.1 mW of energy by a 1 x 1 mm 2 cell surface. If a robot’s size is only 3 x 3 x 2 mm 3 and four surfaces (16 mm 2) are covered by solar cell, it is possible to obtain 1.6 mW of energy. What needs to be taken into account is the interference of the light sources for the solar cells to other parts of the system, e.g. the wireless communication via infra-red between the robots.

The I-SWARM consortium decided to develop and produce solar cells for powering and sensing (for the GPS). The selected technology of the solar cells is based on Amorphous Silicon (a-Si:H), which offers a high efficiency (23%) for the illumination conditions expected (details on illumination are described in the paragraph dedicated to the arena below). EPFL, in cooperation with IMT, made a preliminary study on power aspects for 3 × 3 × 0.15 mm3 solar cells.

Image of a solar cell	U/I-Diagram of the solar cell

Locomotion Unit

All specifications of the locomotion unit (as well as the other units) can be found in the document ”Hardware Specifications”. The legs have to be folded by an angle of about 60 degrees to get a sufficient spacing between the tantalum capacitors and the floor. This gives a somewhat lower speed but a higher load carrying capacity. Several designs that would allow for placement of both the locomotion unit as well as the tantalum capacitors on the same side of the robot backbone flexible printed circuit board (FPC) have been evaluated. There appear to be no simple solution that will guarantee a reasonable yield and the final choice has been to extend the robot backbone FPC and make a second folding. In that way the locomotion and tantalum capacitors can be assembled on either side of the extended part of the FPC and the assembly will be rather straightforward. The negative part with this solution is an additional folding step of the robot backbone. Still, the robot size does not increase noticeably (only the thickness of the FPC is higher than100 μm). The leg bending has been tested to verify that the electrodes and multilayer withstands the large strain during leg bending to a 60 degree angle. The capacity of the legs before and after bending is a good measure of the integrity of the multilayer. Experiments have shown that there might be problems if the multilayer is bent in tensile mode. If the multilayer is arranged to be on the inside of the bending curvature on the leg, there will be compressive stresses/strains. In figure 2.45 experiments show that the multilayer can manage large angle folding in compression. The capacity loss during the experiment is probably an artefact due to the experimental set-up. After unloading the capacity typically is slightly reduced but this change is acceptable.

Image of the locomotion unit. The size is about 2x2mm, the thickness is about 0,2mm	Step Resolution of the locomotion unit

The locomotion unit consists of a flexible printed circuit board (FPC) with three legs that have a piezoelectric polymer actuator multilayer film on top. The processing of the units has been modified several times during the past year due to yield issues. Some of the experiments have been done on larger legs (10 mm) while most have been done with legs of the final size. The most critical processing part is the interconnection of the electrodes in the multilayer. The etching step of the contact areas on this structure were problematic since the RIE equipment

Onboard electronics

Electronics integration in I-SWARM rise important challenges related to area limitations and power consumption. Small area and low power consumption requirements necessarily imply the use of specifically designed Integrated Circuits. Off-the-shelf circuits and re-programmable ASICs are not considered due to such strong restrictions (2mm x 2mm and 750uW-1mW). The solution adopted for I-SWARM has to cope also with the functionalities desired for the I- SWARM robot, e.g. information processing capabilities and movement management, sensing and communication. The hard restrictions and the wide functionalities necessitate the implementation of electronics in the form of a mixed-signal customized IC consisting of a large digital core, including a CPU and memory, and several analogue interface electronics. Technically speaking, the electronics is implemented in what is called a System-on-Chip (SoC) because it includes a digital IP from an IP vendor (the processor). The chip also includes the required regulation of voltage to assure the correct operation if the power is maintained properly.

The silicon provider chosen to fabricate the ASIC is a large company in Italy to which we have access through Circuits-Multi-Projects (CMP) in France [CMP]. The technology used has to deal with the high density of integration required to implement a processor, memory and all the rest of components, while maintaining low power. Both, density of integration and low power consumption are improved with each new advance in the microelectronic technology and hence one of the most advanced processes is preferred for the I-SWARM chips. The technology of 130nm of that company was selected because of its cost, maturity and because the process was considered enough advanced for I-SWARM. It was used an Ultra-Low-Leakage (ULL) option of the technology in order to decrease the static power consumption of the digital modules. The power consumption issue in analog modules is addressed in the full-custom design of each module. The voltage used for the core region is 1.2V. The voltage used in the Input/Output (IO) region is 3.3V.

Architecture of the I-SWARM chip

Image of the ASIC-Core

Although with today technologies it is possible to integrate processors with up to 32 bits, 8-bit processors are used instead for most of the applications, especially in low-power. The processor used is an IP of the 8051 processor provided by Synopsys . The IP was chosen instead of a low power IP with similar or better processing capabilities as it can be obtained from public sites, such as opencores.org, because such IPs do not have the necessary development tools for the construction of the software, i.e., compilers are not available. The 8051 processor is a very common processor in the industry and has many different tools for software development. We increased the processing capabilities of the processor by designing specific hardware modules for specific actions. Advanced features such as navigation or object recognition must be processed by the software because providing such advanced features in hardware requires a high level of knowledge of the whole system being not yet available during the design phase. In any case, the IC has been designed to be very flexible.

The first final prototype is the result of the design, fabrication and test of two previous prototypes that included only certain features of the chip. The first chip being fabricated with all the functionalities required for the I-SWARM robot should be appreciated as a ‘first final prototype’. The first tests will be in December 2007.

Robot-Robot-Communication

Communication is a prerequisite for swarming behaviour. Hence, the robots will be equipped with devices for information exchange. A proposal for the realization of the communication hardware was showing also the feasibility of such a solution, even with the specified size of the freely moving I-SWARM robots of 2 × 2 × 1 mm 3 . The performance of the communication is not limited by its hardware only. The scheme of the data transfer from one robot to the other, the protocol, has also a big influence. A first low-level protocol was also given in D1-4 taking into account the physical properties and restrictions of the communication modules hardware. This protocol together with the hardware was tested by measuring the packet error rate under lab conditions. With the inductive communication set-up, a transmission of up to 7 mm was achieved without errors, and with the optical module a range of up to 10 mm was achieved.

Image of the CAD-design of the communication unit. The size of the unit is 3x3 mm

From the hardware point of view, the protocol must be simple in order to be not too demanding for the processor. In addition, it must be compatible to the physical signaling and be efficient in terms of energy consumption. As it has been decided by the consortium, the robots will communicate via a short range optical link. Here, short light bursts will be used for transmission in order to save energy.

The speed of transmission as well as the volume of information to be transmitted varies depending on the global swarm communication strategy. For instance, the scheme using coupled oscillators as observed in bush cricket communities needs only message sizes of just one bit. Also the speed can be quite low (1 bit/s). The bio-inspired bee trophallaxis communication scheme needs more information to be passed from one bee to the other: Here, an integer number has to be passed from one I-SWARM agent to the other. Simulations have shown that a 10-bit integer figure is sufficient (reference) for this swarm communication scheme. Similar amounts of data are needed in other, more technically oriented schemes such as interchanging ego-positioning values for relative positioning.

Image of the moulded mirror prototype. Depicted is the plastic mirror body, the chomium laser for the mirror itself. the LED and the substrate

For further information regarding the communication module, please be referred to the publication list.

Vibrating needle as a sensor

The vibrating cantilever sensor (VCS) was designed as a modified leg, where one of the top piezoelectric layer in the stack is used as a passive sensor, rather than a driving (or active) layer, thus enabling the detection of a feedback voltage, generated by the oscillation of the cantilever itself (in resonance). The VCS will be 0.75 mm longer than a leg, and this is due to the fact that, as a sensing tool, it needs to protrude more than the front legs in order to be the first part of the micro robot touching an obstacle, object or other micro-robots. In addition, there might be a risk that a longer vibrating cantilever creates a minor perturbation on the robot locomotion, while still offering satisfactory performance from the sensing point of view.

Schematic design of the vibrating needle which is used as an actuator as well as a sensor

The VCS is a parallelepiped structure designed with a size of 2.75 × 0.4 × 0.06 mm 3. It is supposed to be integrated in the locomotion unit. The VCS is nearly identical with the locomotion legs with the difference that the top layer in the multilayer structure is working as a passive sensor in order to monitor the vibration of the whole VCS. The top Al electrode is used to sense the piezoelectric voltage induced by the mechanical deformation of the top P(VDF-TrFE) layer, consequently supplying the micro-robot with a feedback signal about the characteristics of the vibration of the VCS.

The different layers of the vibrating needle

Scenario overview

Because the robots do not have an external supervisor which guides them from task to task, as it is done in tele-operated robotics, scenarios are needed which are performed by the robot clients without any action from outside, i.e. autonomously. This requires some kind of “swarm mathematics” which is implemented into every robot client. The robots show a typical behaviour leading to the emergent effect we want to provoke. The best way of accomplishing a scenario is the usage of modular strategies during the implementation of the software agents into the real robot. Therefore, we use a benchmark scenario having a modular structure. Ranging from less complex modules like aggregation and dispersion to more complex scenarios like finding the shortest path between a source and a sink. The following text will pick up this scenario and describe it again as a guideline for the work progress.

The scenario has been designed to satisfy the following objectives:

• It should be feasible to be performed with the final I-SWARM robots,
• It should be robust
• It should make the benefits of swarm mechanisms understandable for a public audience.

Additionally, it should demonstrate in an obvious way the following features:

• The robots should be autonomous,
• They should show “intelligent” group behaviours,
• The swarm should be self-organized.

This scenario presented below does not represent a “lowest common denominator” of all the suggested scenarios so far. In contrast, the scenario represents a “modular scenario approach”, where every software-partner elaborates one (or, for more risky parts in the implementation two alternative) solutions for some of the “modules” of the scenario. This approach guarantees a very robust implementation plan, because it will result in incrementally constructing the sketched scenario within the consortium co-operatively. The risk of failing to implement one or several

of the scenario “modules” (regardless whether the failure is rooted in the software implementation or the robot hardware does not fully meet the specifications) is compensated by the possibility to drop parts of the scenario modules and still have a presentation which will show the overall impact of the project both on the software and the hardware side.

“Map” of the scenario with the different modules needed. Each partner is a work leader for one task of the scenario with their different sub-task partners which are people out of all institutes involved in this project.

There are several basic functionalities in all scenarios we want to realise:

• Holonomic drive

While the underlying robot hardware is not, using suitable control schemes, holonomic behaviour can be “emulated”. Belonging to the BIOS of the final micro-robots (a reference implementation will also make the wheeled Jasmine robot holonomic), an abstraction layer will provide higher levels of the software architecture with a set of holonomic drive functions.

• Collision avoidance

As above, this is a basic functionality which will be supported to some extent by the robots’ BIOS. This functionality also plays a special role in our scenario. For this basic function, the main approach is behavior-based. For scientific purposes, an analytical approach will also be realised to assess the scalability and adequacy of behaviour-based methods for large swarms.

• Get Position

By using the ego-positioning system (GPS), the robots will frequently be supplied with their current position in the arena. This feature will be available onboard. Some of the alternative approaches make use of this information to achieve specific goals and others do not. However, the robots will collect this information and spend a certain amount of time, power and computation for it.

• Roles of the scenario members

Two roles for the robots are planned. If we cannot achieve this goal, then the robots should act as both: as “scouts” and as “workers” simultaneously.

-   Role 1: Scouts

This role will be assigned at the beginning of an experiment to a certain fraction of the robots (e.g., 20% of the robots). The implementation of this assignment is straightforward: using the GPS, a suitable function can compute the assignment from the robot’s initial position. The robots assigned Role 1 will search the arena for specific points, further on called “point A” and “point B”.

-   Role 2: Workers

The robots assigned this role do not search for the two points (A+B), instead they are sent for by scout-robots (aggregation).

 

The scenarios

• Scenario 1: Disperse the “scouts” in the arena evenly

First, only the designated scouts will be active in the arena. When given a downlink signal via the GPS, these robots should distribute themselves randomly but evenly within the arena. The worker robots will already be present in the arena (to avoid manual handling of hundred robots) and act as obstacles in this phase of the scenario. The swarm goal is to cover the arena evenly distributed. The robot is to equalize the distance to all neighbors

• Scenario 2: Distribute the “workers” in the arena evenly

The workers are given a second downlink signal via the GPS. Then the robots should distribute themselves randomly but evenly within the arena (in between of the scouts). The swarm goal is to cover the arena evenly distributed, the robot goal is to equalize the distance to all neighbours.

• Scenario 3: Explore the arena to find the two points A and B

This scenario is performed after the scenario 2 “Distribute the workers in the arena evenly” is finished. These two points (A and B) are marked places (landmarks) in the arena. Several alternatives to mark these points represent different levels of complexity as a problem to solve using swarm intelligence. They include (with increasing complexity, and therefore in their order of realisation):

-   Using a pattern projected from above (light intensity)

-   Sending the information about point A and point B directly via the GPS downlink

-   Placing an obstacle in the arena that emits light by itself (this involves perception by the individual robots:
    “Where is the light?”)

-   Placing a specialized robot as a landmark instead of an object. The robot sends a message meaning:
    “I am point A” or “I am point B”.

-   Placing two obstacles with different features in the arena. This can be the dimensions of the object:
    The scouts form a line around the obstacles and by sending a “hop-count”, they can measure the circumference
    of the object by collective perception. Other possibilities are geometrical properties like concaveness etc.
    This task is only performed by the scouts, the workers just work as beacons. The swarm goal: Having
    navigation-information about the nearest landmark sent to all robots with the lowest possible error.
    The robot goal: Detecting a landmark.

• Scenario 4: Calling the workers to the nearest obstacle (point A or B)

This scenario is performed after scenario 3 is finished. This is mainly an aggregation task. Several solutions for this task have already been proposed in I-SWARM. The implementation of this task will be communication-based. The task is only performed by the workers. The remaining scouts work as beacons again. Swarm goal: Minimizing the average distance of all robots to one of the two landmarks, having approximately 50% of the worker robots aggregated at each landmark, having the scouts still almost evenly distributed in the arena to allow information-bridging between point A and point B. Robot goal: Minimizing the distance of all robots to one of the two landmarks .

• Scenario 5: Finding the shortest way between the two points

This scenario is performed after scenario 4 is finished. This can be done either by forming direct lines or by generating paths like ant-trails. Swarm Goal: Forming a line having the shortest possible length and connecting Point A and point B. Robot goal: depends on the solution.

To get a feeling for all those scenarios, a lot of simulations have been performed. With the help of the multi-agent simulation framework “breve” we got an impression of the swarm mathematics we have to implement.

Fig. 1: Initial state of a scenario	Fig. 2: Scouts are spreading over the arena
Fig. 3: Workers (red)are spreading after they are called by the scouts	Fig. 4: The scouts (blue) are identifying the two landmarks A and B
Fig. 5: The scouts call the workers for aggregation	Fig. 6: The workers for a line between the two landmarks
Fig. 7: The workers form two trails	Fig. 8: Introducing a small labyrinth