Using Bluetooth to Control a YaMoR Modular Robotbiorob2.epfl.ch/pages/studproj/birg57460/report-final.pdf · Project description 1.1 Introduction The aim of the YaMoR (Yet another

bluemove Using Bluetoothr to Control a YaMoR Modular Robot

Semester ProjectWinter 2004-2005

Cyril Jaquier - Kevin Drapel

Supervisors: Professor Auke Ijspeert, Alessandro Crespi, Andres Upegui

February 11, 2005

Abstract

The Biologically Inspired Robotics Group (BIRG) of the Swiss Federal Institute of Technologyin Lausanne (EPFL) is working on modular robotics. Computer simulations are mainly usedbut prototypes also exist. Most of them are controlled by a wired connection. This documentexplains how the wires can be replaced by a Bluetooth connection on the YaMoR robot units.Wireless communication allows better freedom of movements and ease of use. Although completeautonomous unit is the final aim, a centralised Java application is used to control every module.The problems and solutions met during the development of this software are discussed in thefollowing pages.

Using Bluetoothr to Control a YaMoR Modular Robot

Contents

1 Project description 61.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 A literature and projects review 72.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Bluetoothr in robotics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Dengoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Aibo ERS-31xb series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Autonomous Systems Lab flying robots (EPFL) . . . . . . . . . . . . . . . . . . . 9

2.6.1 Blimp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.2 Indoor plane - F2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 µFR-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8 Monsieur II-P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.9 Morph (Atom Project) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.10 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 An overview of the Bluetoothr protocol 113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Piconets and scatternets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Bluetooth protocol layers and the Bluetooth stack . . . . . . . . . . . . . . . . . . 123.4 The Bluetooth packets scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 The Bluetooth implementation in the YaMoR modules . . . . . . . . . . . . . . . . 13

4 Modules 144.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Power board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.2 What went right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.3 What went wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.2 What went right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3.3 What went wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4.2 Control via an USB dongle . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4.3 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4.4 What went right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4.5 What went wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

C. Jaquier - K. Drapel 1 v1.0 - February 11, 2005


5 Bluemove 195.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Java 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2.1 Why Java and not another language ? . . . . . . . . . . . . . . . . . . . . . 195.2.2 The Bluetooth stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2.3 Transmission between Bluemove and the module . . . . . . . . . . . . . . . 205.2.4 What went right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2.5 What went wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3.2 The different tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3.3 What went right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3.4 What went wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.4 The inners of Bluemove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.4.1 An overview of Bluemove architecture . . . . . . . . . . . . . . . . . . . . . 265.4.2 Linear and spline interpolation . . . . . . . . . . . . . . . . . . . . . . . . . 265.4.3 Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Experiments 306.1 Two working modules and an inactive skeleton . . . . . . . . . . . . . . . . . . . . 30

6.1.1 2-standup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.2 3-stickworm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.3 More examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7 Further developments 327.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1.1 Mechanic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.1.2 Electronic boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8 Conclusion 36

A Bluemove short manual 37A.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A.1.1 J2SE 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37A.1.2 Java Bluetooth stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37A.1.3 Bluemove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.1.4 Launching the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A.2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.2.1 The menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.2.2 The tool bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38A.2.3 Timelines tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.2.4 Modules Manager tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.2.5 Console tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.2.6 The status bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A.3 Tutorial: a small example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.3.1 Step one: add a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.3.2 Step two: edit a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.3.3 Step three: add an actuator . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.3.4 Step four: add another module . . . . . . . . . . . . . . . . . . . . . . . . . 41A.3.5 Step five: draw a module trajectory (spline) . . . . . . . . . . . . . . . . . . 41A.3.6 Step six: draw a module trajectory (linear) . . . . . . . . . . . . . . . . . . 41A.3.7 Step seven: save the project . . . . . . . . . . . . . . . . . . . . . . . . . . . 42A.3.8 Step eight: play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42



A.3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42



List of Figures

1.1 A complete module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 ”Bluetooth: Connect without Cables” . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 ”Bluetooth for Java” - APress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 ”Dengoro” controlled by a Toshiba phone . . . . . . . . . . . . . . . . . . . . . . . 82.4 ”Dengoro” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 The Sony AIBO ERS-31x family . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 The ”Blimp” airship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 The ”F2” plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8 The Seiko Epson micro-flying helicopter . . . . . . . . . . . . . . . . . . . . . . . . 92.9 The ”Monsieur-II” robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.10 Morph 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.11 The ”Nuvo” robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 A piconet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 A scatternet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Bluetooth protocol - Main layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 A Bluetooth frame composed of a 5-slots packet and 1-slot packet . . . . . . . . . 133.5 A Bluetooth packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 YaMoR exploded view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Power board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Electronic bug tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4 Power board schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.5 MAX1774 internals and the shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . 154.6 FPGA board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.7 The Bluetooth board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.8 the MSI 6967 Bluetooth dongle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.9 Communication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1 From Java application to the Bluetooth device . . . . . . . . . . . . . . . . . . . . 205.2 JBuilder designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3 Demopaja by Moppi Productions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.4 Adobe After Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.5 Modules Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.6 Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.7 .NET properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.8 A schematic view of Bluemove architecture . . . . . . . . . . . . . . . . . . . . . . 265.9 An example of an Hermite spline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.10 The Hermite basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.1 A 2 modules example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2 A 3 modules example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30



7.1 Weak point of the servo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.2 Milled side panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.3 Male and female Velcro-like tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.4 Distance measuring sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.5 Real-time control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.6 Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.2 Tool bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.3 Timelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.4 Modules Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.5 Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.6 Status bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.7 Main screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.8 Modules manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.9 Module edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.10 Actuator edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.11 Second module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.12 Timelines tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.13 The first curve with spline keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.14 The second curve with linear keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 42A.15 Saving a project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42



Chapter 1

Project description

1.1 Introduction

The aim of the YaMoR (Yet another ModularRobot) project at BIRG is to construct a wire-less autonomous modular robot made of severalunits. These units were designed by Elmar Dit-trich who was in charge of the mechanical as-pects (motor, case, materials). Rico Moeckelthen worked on the electronics (power supply,Xilinx FPGA and Bluetooth boards), the con-trol software in VHDL for pulse width modu-lation and the Bluetooth protocol. Despite thefact that a Bluetooth support was available oneach module, a real interface between a com-puter and the modules was still missing. Thevideos produced by Elmar show several moduleswithout electronics and connected with wires toan intermediate device. This device was actinglike a multiplexing bridge between the computerand the modules. Positions were generated bythe PC and sent via the serial interface (RS232)to the Bluetooth device on the computer. TheBluetooth signal was then received by the in-termediate device which would in turn generatethe PWM commands for the servos.

With the new wireless features added by RicoMoeckel, it was obviously necessary to get ridof this middle component and provide a directwireless communication between the PC and therobot. With a low budget in mind, the solutionbased on Bluetooth had to be simple and easyto install. This solution is described in Chap-ter 4. Another point which had to be reevalu-ated was the software used to communicate withthe modules. Jean-Philippe Egger had writ-ten a Java application called ”Java-Motion” [15]where the user could draw trajectories. ElmarDittrich slighty modified this application to fitwith the modules. We wrote a new applicationfrom scratch which is called Bluemove. We used

Figure 1.1: A complete module

some concepts already present in Java-Motion.We added new features such as a project man-ager or smooth interpolation. Bluemove will beexplained in Chapter 5.

As Rico left the BIRG after only six months,he did not have time to assemble enough mod-ules. We were in charge of ordering and assem-bling the rest of the modules. The goal was tomount seven modules to form a robot in a pi-conet network before the end of the semester.We directly ordered additional components toreach a total of 17 units (plus some ”rescue”components from the 18th unit). The delays be-tween ordering and shipping are quite long andat the time of writing, we can not construct newmodules. In Chapter 7, we will discuss the prob-lems and solutions related to hardware. We alsohad to experiment and take videos of the wire-less YaMoR with different configurations.



Chapter 2

A literature and projects review

2.1 Bluetooth

As Bluetooth is a complex protocol, we first hadto read some documentation. This helped tohave a better idea of the advantages and lim-itations of wireless communications based onthis protocol. Knowing the Bluetooth termi-nology was useful to find the necessary soft-ware components and understand the steps thatRico Moeckel went through when he designedthe electronics of the modules.

The Chapter 3 is a reminder of the Bluetoothprotocol and addresses its issues. We also ex-plain how the specifications relate to the YaMoRmodule.

There are more than a dozen books aboutBluetooth. Most of them share chapters aboutthe protocol. Some books favour low-level andelectronic/physical concepts while others aremeant to be read by people interested in thecommunication itself.

We first read some chapters of an in-depthguide to the version 1.1 of Bluetooth protocolwithout many links to a programming languagenor electronics.

The book ”Bluetooth: Connect without Ca-bles” [10] covers the whole v1.1 specification andis hence quite complicated. Nonetheless, it is anexcellent source for people who are making theirway through the Bluetooth protocol.

We skipped some chapters about the ra-dio, power consumption and the low-level as-pects which were rather part of Rico Moeckelproject and focused on the higher levels of Blue-tooth protocol (serial communication, devicesdiscovery, master/slave configuration). ”Blue-tooth: Connect Without Cables” also featuresadvanced topics like encryption and securitywhich our project was not concerned with.

This book as well as the official specifications

Figure 2.1: ”Bluetooth: Connect without Ca-bles”

of the Bluetooth protocol furnished a clarifica-tion for the following points:

• rate of Bluetooth communications

• delays related to communication slots andfrequency hopping

• limitations in the slave/master architecture

• amount of devices that could be controlled

• range and maximum distance between de-vices

• the Bluetooth services useful for the mod-ular robot

Some of these points are restricted by the soft-ware and the type of hardware which are used(the communication range and the maximumamount of devices in a network may vary).



2.2 Java

After we decided to use Java as the main pro-gramming language for the project, we read abook called ”Bluetooth for Java” [18]. Thisdocument explains the JSR-82 norm, namelythe javax.bluetooth namespace which providesa standardized interface to communicate withBluetooth devices from Java. In Section 5.2.1,we will discuss the different languages and solu-tions we examined and why we chose Java.

Figure 2.2: ”Bluetooth for Java” - APress

2.3 Bluetoothr in robotics

We also looked if other research groups had beenworking on Bluetooth based robots. Some in-teresting projects have been developed, mainlyin Japan but also here at EPFL. Most of themare humanoid robots. We did not find anotherproject combining modular robotics and Blue-tooth. The modular robots either work withwires or radio/IR interfaces. Nonetheless, thefew robots below show that Bluetooth is a goodprotocol for short range communication. It alsoensures a compatibility with cellphones.

2.4 Dengoro

This humanoid robot can be controlled usinga Bluetooth cellphone. Toshiba, KDDI and IBee worked on the Dengoro (namecoded ”PirkusR.Type 01”) which is made of aluminium andwill be sold as a self-assembly-kit for about$1800 (February/March 2005) [12]. Toshiba wasin charge of the cellphone part and the operat-ing system, KDDI together with I Bee designed

the mechanical and electronic parts of the robot.The robot can walk, jump and wave his hands.

Figure 2.3: ”Dengoro” controlled by a Toshibaphone

Figure 2.4: ”Dengoro”

2.5 Aibo ERS-31xb series

A variant of the famous dog-like robot by Sonysupports Bluetooth communication via a remotecontrol shipped by Sony. The other Aibo ver-sions work with IEEE802.11b. The product ofthe ERS-311b (white dog on Figure 2.5) hasbeen discontinued and replaced by a similarmodel, ERS-312b (black model on Figure 2.5)[4]. It also uses Bluetooth. As far as we know,these Aibos are only available in Japan and notsold in Europe or the USA.



Figure 2.5: The Sony AIBO ERS-31x family

2.6 Autonomous SystemsLab flying robots(EPFL)

The Autonomous Systems Lab at EPFL workson flying robots. Obviously, wires between therobot and a computer or other devices are notconvenient and must be replaced by a wirelesssolution. They chose to use a serial communi-cation based on Bluetooth.

2.6.1 Blimp

The lightweight flying robot developed at ASLcommunicates in a wireless manner with a PC[39]. The channel is bidirectional and ensuresa short-range link between the microcontrollerand the PC. Weight is the main concern andspecial care was taken to decrease the size andthe mass of the components. The robot cease-lessly evolves in a room with black and whitestripes on the wall.

Figure 2.6: The ”Blimp” airship

2.6.2 Indoor plane - F2

This Bluetooth plane is extremely lightweightwith only 30g. With its autonomy of about 20minutes, F2 can fly using 2 or 3 linear camerasand additional sensors (gyroscope, accelerome-ters) [6]. Compared to the Blimp, the plane hasmore degrees of freedom but can not be evolvedin a room. A simulator has been specially de-veloped for this purpose. The communicationis similar to the one in the Blimp with a bidi-rectional channel between the robot and a PC[29].

Figure 2.7: The ”F2” plane

2.7 µFR-II

A similar project, µFR-II, concerning a micro-flying helicopter (8.6 grammes) with Bluetoothtransmission of data (camera snapshots) andcommands has been presented by Seiko EpsonCorporation [32]. An interesting fact about thisrobot is that the flight instructions are precalcu-lated and sent via the Bluetooth channel. More-over realtime control is supported and signalscan also be transmitted using two LEDs. Powerconsumption is, therefore, lowered if only basicsignals must be sent at a short range via LEDs.The Bluetooth chip can be switched off afterhaving received the trajectories.

Figure 2.8: The Seiko Epson micro-flying heli-copter



2.8 Monsieur II-P

A very small robot with a volume of only 7.8 cm3

and a weight of 12.5g developed by Seiko EpsonCorporation and presented in 2002 [24]. It isthe successor of the ”Monsieur” robot launchedin 1993. Moving at about 7 cm per secondwhen Bluetooth is activated (15 cm per secondwithout wireless), it features a promising ultra-sonic motor designed for tiny devices. Withtheir built-in Bluetooth support, these robotscan be used simultaneously to create swarms.The Bluetooth and CPU are powered at 2V andthe running time is approximately 5 hours.

Figure 2.9: The ”Monsieur-II” robot

2.9 Morph (Atom Project)

Another humanoid robot is part of an ambitiousproject supported by the Japanese governmentat the rate of 50 billion Yen per year over threedecades [25]. However, according to some arti-cles and the economical situation, this will bedifficult to sustain and the development of therobot could be delayed.

Figure 2.10: Morph 3

The goal of the Atom Project maintainedby the ERATO (Exploratory Research for Ad-vanced Technology) is to create an humanoid

with the neural and physical capacity of a 5-year-old child [26]. Morph would be used torescue people in natural disasters. It could alsobe sent in dangerous or contaminated environ-ments.

2.10 Remarks

There are many other humanoid Bluetoothrobots like ”Nuvo”. Unfortunately, they are ei-ther undocumented or the research pages are inJapanese. Moreover, companies are competingeach other on the toy market and do not givemuch relevant information about the technicaldetails implemented in their robots.

Figure 2.11: The ”Nuvo” robot

What we can notice is that all these robotsexcept the ”Monsieur II-P” are supposed to beused as independent devices. There are no inter-actions between units to create new behavioursas in the modular robotics paradigm. The SeikoEpson Corporation has demonstrated that itwas possible to create Bluetooth robots whosesize does not exceed a few centimetres. The”Dengoro” robot is a good example of a robotcontrolled by a small remote device. Clearly, amodular robot could receive its commands froma cellphone or a PDA instead of a desktop com-puter.



Chapter 3

An overview of the Bluetoothr

protocol

3.1 Introduction

Bluetooth was first developed by Ericsson andthen Sony, IBM, Intel, Toshiba and Nokiajoined the project. It was intended to providea cheap wireless support for mobile devicescommunicating at close range. Bluetooth issaid to be a cable replacement for personal areanetwork while 802.11x is used for local areanetwork. Hence, Bluetooth is the best solutionwhen distances between mobile devices arerelatively short, high transmission rates are notneeded, and power consumption has to be low.With their 1 mW transmission power, mostBluetooth devices operate in a range of a fewmeters (class 3). There are two other powerclasses: 100 mW (class 1) and 2.5 mW (class2). They obviously allow wider coverage, up to100 meters with class 1.

The first specification was released in 1999but it suffered from many issues related to inter-operability. This was fixed in version 1.1. Sup-port for non-encrypted channels was also partof this update. Bluetooth 1.2 is the version cur-rently used by most devices available, thoughchips based on version 2.0 are available sinceOctober 2004. Bluetooth 1.2 contains majorimprovements like adaptive frequency hopping,synchronous connections and information aboutthe signal strength and timing. The transmis-sion speed in versions 1.x was set at 723 Kbit/sbut in practise, this rate was only achieved withversion 1.2. Frequency hopping is probably themost important feature in this revision as itimproves resistance to interferences. Actually,the license-free 2.4 GHz frequency band used byBluetooth is quite crowded. Popular wireless de-

vices and systems (cordless phones, door open-ers, 802.11 networks) also work in this band andfrequency hopping together with a low powersignal was a solution to avoid collisions betweenpackets.

Bluetooth devices pseudo randomly switchbetween 79 channels available in the 2.4 GHz to2.4835 GHz range. Although in some countrieslike Japan, the bandwidth is more limitedand only 23 channels are available. Hoppingis performed every 625 microseconds (1600switches per second) and is also supposedto improve security. This kind of protectionscheme is quite insecure nowadays and has beenreplaced by robust cryptographic primitives inBluetooth 2.0.

The second generation of Bluetooth is com-patible with previous versions. Among the newfeatures in Bluetooth 2.0 are support for broad-cast/multicast, a faster mode which replaces thefrequency hopping, data rate of 2.1 Mbit/s andimproved response times with less handshak-ing. Another interesting feature for mobile de-vices is the power consumption which has beenhalved in Bluetooth 2.0, the chip itself needsmore power than an equivalent Bluetooth 1.2chip but as transmissions are three times fasterwith less exchanges, this results in a diminishedconsumption.

3.2 Piconets and scatternets

As Bluetooth is intended to connect many de-vices to create small networks, the protocolwas designed with a master-slave architecture inmind. Each Bluetooth device can handle up to 7



connections, one per slave device. Only one con-nection is fully active (transmission), the othersare in a special semi-active state. In short, theyhave an active-member address but are simplywaiting their turn. The frequency hopping de-fines slots of 625 microseconds, the master trans-mits its packets in even time slots while slavesuse odd time slots.

Figure 3.1: A piconet

The master can finally handle 255 standby(parked) slaves. These slaves are synchronisedwith the master but do not have a specific ad-dress. If the master wants to send data to one ofthese standby devices, he must first discard oneof the active slaves and send a notification tothe parked slave. It may take some time beforethe freshly woken up device gets his address andbecomes active.

A device can either be a slave or a master andchange its state when needed. A master with 7slaves is called a piconet in the Bluetooth termi-nology. The master initiates the communicationand defines a hopping sequence. It also main-tains a clock used for synchronisation betweendevices. A device can be part of more than onepiconet. This allows more complex networkscalled scatternets. A scatternet is basically agroup of piconets. As some devices belong toseveral piconets, they act like bridges and helpto increase the coverage of the network. A de-vice can be the master of its piconet and on theother side, it can be a slave in another piconet.For example, a slave device can send a packet toits master, the host will then forward the packetto the master of an adjacent piconet.

Figure 3.2: A scatternet

3.3 Bluetooth protocol lay-ers and the Bluetoothstack

Bluetooth protocol is complex and for the mod-ular robot project only a small subset of theprotocol features is useful. Bluetooth is dividedin many layers starting from the hardware/radiolayer up to the top layer represented by the ap-plication.

There are mainly two types of data transferavailable between devices. The first one calledSCO (synchronous connection oriented) couldbe compared to TCP/IP (a connection is main-tained between the devices) but is unreliable, ittries to maintain a constant bandwidth. Thesecond is the ACL (asynchronous connection-less) . The ACL transmission rate is higher thanSCO rate. The ACL is a reliable communica-tion. Bluetooth also supports a third type oftransfer with voice channels for phones.

The host controller interface is mainly re-lated to hardware and responsible for radio,frequency hopping and other low level aspects.The L2CAP layer provides services for connec-tionless data transfer. Using the SDP (ser-vice discovery protocol), one can get informa-tion about a device and what kind of servicesare available on this device (file transfer, voicechannels support, modem,...). When one workswith a known kind of device, the service discov-ery, which is quite long, is not necessary. TheRFCOMM layer is a serial port emulation. Itprovides a RS-232 protocol useful for upper levelservices like OBEX which is a session protocolfor exchanging objects. The Bluetooth stackalso contains modules for TCP/UDP and canbe used as a bridge between Internet and the



vCard / vCal

OBEX

WAE

WAP

UDP TCP

IP

PPP

RFCOMM

L2CAP

SDP

LMP

BASEBAND

BLUETOOTH RADIO

Host controller interface

Figure 3.3: Bluetooth protocol - Main layers

Bluetooth device (a phone cell used as a modemfor WAP browsing).

3.4 The Bluetooth packetsscheme

Each packet can be composed of multiple slots(one slot has a length of 625 microseconds).Thus, a Bluetooth packet extends itself over 1,3or 5 slots. A Bluetooth frame consists of a mas-ter packet (transmit packet) followed by a slavepacket (receive packet). The advantage of multi-slots packets is that they allow higher data rates,the packet header overhead is lower compared toa single-slot communication. With a single-slotcommunication, the maximum data rate is setto 172 Kbps. With 5 slots for the master and 1slot packets for the slave, Bluetooth can achieverespectively 721 Kbps and 57.6 Kbps.

The packets have an internal format whicis fixed and consists of three parts. The firstheader called ”access code” has a size of 72 bits.It contains the master identity which is uniqueas long as communication occurs on the samechannel. The access code also contains the mas-ter clock. A 54-bits header follows the accesscode, it features error corrections (for the dataand the header), controls and retransmission in-formation. The last part is the payload contain-ing data between 0 and 2745 bits. Dependingon the number of bits, the packet will be spreadon 1, 3 or 5 slots.

Figure 3.4: A Bluetooth frame composed of a5-slots packet and 1-slot packet

Figure 3.5: A Bluetooth packet

3.5 The Bluetooth im-plementation in theYaMoR modules

Some of the features of Bluetooth are not neces-sary for YaMoR. The service discovery is useless,the modules are all the same and their char-acteristics are known in advance. Encryptionand security are aspects which have been leftaside for the YaMoR project since they wouldonly add superfluous complexity and decreasethe transmission speed.

As the modules work with absolute positionsand not relative parameters (deltas), some lossof information from time to time will not havemuch impact. The ACL communication is reli-able but discards packets after a given timeout.If the robot can not be found (out of range),some positions will be flushed out. As soon asit gets closer to the transmitter, it will receivenew positions and will synchronize with a cor-rect motion. If the robot is close but a packethas not be received for any reason, the trans-mitter will resend the packet to the module.

The firmware mounted in the Bluetooth chipwas designed by Zeevo and works with a piconet.It does not support scatternet yet, but RicoMoeckel is working on this feature and a cus-tom protocol especially designed for the modu-lar robot.



Chapter 4

Modules

This chapter describes the YaMoR unit. Af-ter a short summary of the previous work, wewill see the module in more details. This chap-ter does not present the mechanical pieces ofYaMoR but focuses on the electronic part.

4.1 Summary

The YaMoR unit was designed by Elmar Dit-trich. One of the main goals was to developthe cheapest module unit possible. An explodedview is shown on Figure 4.1. We will not dis-cuss the mechanical characteristics more in thischapter except on Section 7.1.1. However, werecommend the reading of Elmar’s work whichis available at [13] for further information.

Figure 4.1: YaMoR exploded view

During his summer internship [27], RicoMoeckel developed all electronic boards neededto make YaMoR units autonomous. The mod-ules are controlled using a wireless Bluetoothconnection. As explained earlier in Section 2.3on page 8, Bluetooth does not seem to be widelyused in modular robotic. However, this typeof communication is a good choice in terms ofpower consumption and costs which are often

decisive in modular robotics. One of our projectgoals was to build more modules and find aneasy way to control them. It allows the user tofocus on the development of new kinds of move-ment rather than dealing with technical issuesand an unfriendly user interface. We will nowexamine in more details each electronic boardembedded in a YaMoR unit.

4.2 Power board

4.2.1 Description

The power board supplies the different voltagesneeded by the FPGA board (+3.3V, +1.2V),the Bluetooth board (+3.3V) and the servo(+6V). A battery taken from the Amphibot I [8]provides the energy to this board. An embed-ded charger is integrated. It can also be pow-ered with an external power supply. A completepower board is shown on Figure 4.2.

Figure 4.2: Power board

This board takes place at the top of the mod-ule. The dimension is 4cm x 3.2cm.



4.2.2 What went right

Once all the problems listed in Section 4.2.3were resolved, the power board was really easyto use. The dip switch allows the user to ef-fectively control the various functions. Theoutput voltage stability is good thanks to theMAX1774. Once the device was running, wedid not encounter further problems because ofthis board.

4.2.3 What went wrong

MAX1774 problem

When Rico left the BIRG, he had only onepower board working. The two others did notwork and had the same problem: after connect-ing the battery, some components’ temperaturehighly increased. Therefore, we started compar-ing the working board with the two others. Af-ter hours of binocular search, we were not ableto find any differences. Andre Badertscher andFabien Vannel helped us tracking this hardwarebug. We exchanged some components, checkedall the voltages and currents (see Figure 4.3).Finally, Fabien discovered the source of theseproblems: the BIN pin was connected to theground as shown on Figure 4.4. Current flowedacross a PMOS transistor inside the MAX1774because CS- was connected to +3.3V and BINto the ground. The problem was that the tran-sistor was not designed to work in this direction(see Figure 4.5). The problem was solved bydisconnecting the BIN pin.

Figure 4.3: Electronic bug tracking

Charger problem

The power board has an embedded charger. Itallows to charge the battery without having to

dismount the module. The datasheet and Rico’sschematic recommend an input voltage of +10V.We applied this voltage of +10V precisely mea-sured with a calibrated multimeter. After a fewminutes, the red led started to blink, indicat-ing a charging error. After some investigation,we found out that applying a voltage just be-low +10V allowed the charger to work correctly.The voltage must be decreased to about +9.5V.

Polarity inversion

The board does not support polarity inversion.If the battery is connected the wrong way, itcan result in destroyed components. In orderto minimize the risks, Andre Badertscher sol-dered a diode between VBAT and GND on afew boards. This protection should be put onall power boards in order to enhance the relia-bility of the circuit.

Figure 4.4: Power board schematic

Figure 4.5: MAX1774 internals and the shortcut

4.3 FPGA

4.3.1 Description

The FPGA board contains a Xilinx Spartan3 with 400’000 gates and 4 Mbit of highspeed SRAM. FPGA programming is done us-ing JTAG or slave serial. We currently use theFPGA as a PWM generator which drives theservo. The PWM duty is sent by the Bluetooth



board using a serial line. These duties or posi-tions are sent to the Bluetooth board (see Sec-tion 4.4) by an external computer. The ulti-mate step would be that the FPGA calculatesits servo position and transmits it to the oth-ers modules. This could be achieved with theimplementation of one or more MicroBlaze intothe FPGA. An external +2.5V reference voltageis needed in order to program the Spartan.

Figure 4.6: FPGA board

The board dimensions are 7.5cm x 4cm. Ittakes place vertically along the servo. There isa square hole of 2.4cm which allows the batteryto be placed horizontally at the bottom of themodule.


We never had problems with this card. TheFPGA programming is easily completed withthe Xilinx tools and the JTAG connector. Onemust not forget to connect the +2.5V voltagereference. The PWM design written in VHDLby Rico Moeckel is used without any modifica-tion.


During our tests a module sometimes stoppedmoving without any apparent reason. The Blue-tooth connection was established but the servodid not move anymore. After a reset of themodule and FPGA reprogrammation, the mod-ule started to work as expected. We were notable to track this problem down as it only occursrarely and randomly.

4.4 Bluetooth

4.4.1 Description

The Bluetooth board on Figure 4.7 is equippedwith a System on Chip from Zeevo [38]. This

chip (ZV4002) is a combination of a Bluetoothradio frequency system and an ARM core [5].The board contains 8 Mbit of SRAM and up to32 Mbit of flash memory. The ARM program-ming is done by JTAG or via RS232. With itsdevelopment kit, Zeevo provides a basic oper-ating system called BlueOS with a basic multi-tasking. The communication between processesare done using messages1. Zeevo also provides atest application called ”Zerial” which is basedon their BlueOS operating system. It allowsthe replacement of serial cable with a Bluetoothconnection.

Figure 4.7: The Bluetooth board

4.4.2 Control via an USB dongle

At its early stage, the modular robot was con-trolled via a serial interface (RS232) with sig-nals generated by the desktop computer and for-warded to its Bluetooth device. The Bluetoothsignal was then received by an intermediate de-vice connected to the modules with wires. Thismiddle device generated the appropriate PWMcommands for the servos.

We had to remove this intermediate deviceand provide a simple solution to directly com-municate with the modular robot from the com-puter. A few solutions appeared:

• A Bluetooth stick connected to the USBport of the PC

• Many Bluetooth devices connected to aFPGA which routes data coming from a se-rial port

1also called ”signals” in BlueOS terminology.



• A PC with many serial ports, each serialport is connected to a Bluetooth transmit-ter

We quickly decided to use Bluetooth sticks.It was the cheapest way to get a handy Blue-tooth solution. The USB sticks are available inall computer shops for a low price. One mustverify that they are compatible with Linux. Webought two different models (class I with 100mrange) that perfectly work in a Linux envi-ronnement: MSI (MS-6967 on Figure 4.8) andACER (AG.BTCSR.UD3).

Figure 4.8: the MSI 6967 Bluetooth dongle

A custom Bluetooth device would have beenexpensive to build and difficult to transport ordeploy. It did not provide any significant ad-vantages compared to the Bluetooth stick. TheBluetooth sticks are versatile devices that sup-port all features needed for the modular robot.They are particularly useful for laptops as theyare lightweight and small. Compared to the cus-tom device which would have been a big blackbox with maybe an external power supply, theyare the best solution for a seamless integrationinto a personal computer.

4.4.3 Connection

The connection establishment between two ”Ze-rial” interfaces is achieved using special AT com-mands. Here is an example:

AT+ZV Discovery

This command launches a discovery scan andreturns all the available Bluetooth devices foundin the area. Another example.

AT+ZV SPPCONNECT 00043e000000

This one connects the current ”Zerial” in-terface to another one whose address is”00043e000000”. After the connection setup,the interface switches to ”bridge” mode and justforwards the received data.

This firmware is distributed in source codeand binary file. This serial line replacement canbe used to communicate with the YaMoR units.As we do not want a ”Zerial” interface on thecomputer side, we tried to find a more flexiblesolution. We discovered that it was possible tomake a direct serial connection between a ”Ze-rial” interface and a standard Bluetooth dongle.This is the adopted solution in regard to its flex-ibility and low cost. We will discuss this in moredetails in Section 5.2.3. The data flow is repre-sented on Figure 4.9.

Computer

Serial data PWMBluetooth

Servo

Bluetoothboard

FPGAboard

Figure 4.9: Communication flow

The data are transmitted from the computerto the Bluetooth board using the Bluetooth pro-tocol. The packets are then forwarded to theFPGA board which expresses them into PWMvalues. These pulses finally arrive at the servowhich converts them into a mechanical position.

Each Bluetooth device needs to have anunique address in order to be identified withoutany confusion. The address of the ZV4002 canbe statically set with the firmware loader appli-cation. It is a one time operation. However it ispossible to program the address dynamically af-terwards. A Bluetooth address is a 48 bits value.We decided to use the following convention forYaMoR units.

• The address begins with 42495247.

• The four last positions are the module num-ber.

• 0000 is reserved and must not be used.

For example, module 1 has the Bluetooth ad-dress 424952470001. This is not a random num-ber but the hexadecimal ASCII representationof ”BIRG” (42 stands for A, ...). These addressesare statically stored in the ZV4002.

The dimension of this board is 7.5cm x 4cmlike the FPGA board. It takes place vertically



along the servo on the opposite side. There isa square hole of 2.4cm which allows the batteryto be placed horizontally at the bottom of themodule.


The ZV4002 programming is done using JTAGand the Zeevo flash tool. This operation is easyto accomplish and needs to be done only once.Afterwards it is only required to turn the poweron in order to have an operational board.

A green led shows the Bluetooth connectionstate. It flashes when no connection is estab-lished and remains on when connected to ourmaster Bluetooth device. This was really help-ful for debugging.


CRC errors

We quickly got three built modules. One was al-ready flashed by Rico with the ”Zerial” firmwarefor his project presentation. The second unitwas flashed by us without any troubles. Butthe third one always reported CRC errors whenlaunching the flash tool. We exchanged theZV4002 and the flash memory. Unfortunately,the CRC failure still occurred. At this time,we have not yet discovered the reasons of theseerrors but we highly suspect the flash memorycomponent to be faulty. We have not yet re-ceived these memories, further investigations aretherefore impossible at the moment.



Chapter 5

Bluemove

This chapter focuses on the software applica-tion developed during this project. After a shortsummary, we will see in more details the differ-ent parts of Bluemove, the technologies we usedand the mathematical routines implemented inthis application.

5.1 Summary

When we started this project, the YaMoR unitswere quite functional. But it lacked a good soft-ware. We thus wrote a Java application thatallowed the user to control a robot without hav-ing to learn a programming or script language.

Even an unskilled person had to be able tocreate and play with YaMoR modules. We alsowanted to make an application generic enoughto be reused in other projects with minimalchanges. We will show how we accomplishedthese aims.

5.2 Java 1.5

5.2.1 Why Java and not anotherlanguage ?

While we were looking for a software solution,we quickly noticed that Java was the languagethat provided the most convenient interface.Despite its standard status, Bluetooth hasbeen efficiently implemented only in a smallset of languages including Java, C/C++ andC#. C# suffers of portability problems as it isclosely related to the Win32 API. We checked ifthe open source .NET implementations (Mono,DotGNU) could provide the needed services.Their network code being at an alpha stage1,

1about 13 classes are missing in DotGNU, Monoseems to be a little more advanced

Mono or DotGNU are still missing vital features.

A solution based on C or C++ was not goodeither for the portability. We did not find a li-brary that could transparently work on Linuxor Windows. The remaining language that weconsidered was Java 1.5 (J2SE 5.0). It quicklyturned out to be the best candidate for the Blue-move project. It is indeed exceptionally well-suited for applications that must be deployedon several operating systems. Moreover, Javais the only language with a standard and con-sistent interface for Bluetooth (JSR-82). Javavia Swing gives a powerful access to graphicalfunctions which were necessary to design the in-terface. Thanks to the J2ME (Micro Edition ofthe Java 2 Platform) and its wireless toolkit, itwould be possible to create Bluetooth applica-tions for the modular robot on mobile phones,PDA or other small systems that support Javaand Bluetooth.

5.2.2 The Bluetooth stack

The Java API for Bluetooth (JSR-82) standard-izes an interface for the following protocols:

• RFCOMM

• OBEX

• Service Discovery

An expert group composed of engineersof big companies (IBM, Ericsson, Nokia andMotorola) has leaded the JSR-82 to a robustand consistent specification (released in March2002). Additional protocols could be added infuture versions. However for our project, theRFCOMM (serial ports emulation) protocol isenough.



JSR-82 only defines a set of functions butdoes not provide any implementation. Thelatest which is called ”Bluetooth stack” isleft to the chips manufacturers and othercommercial third-parties. Some open sourceprojects have started but their stacks are ratherlimited, they do not work with the Bluetoothstick connected to the USB port of a PC.Many companies sell more advanced stacksfor both Windows and Linux. One of them,Rococo offers a special academic edition ofits Bluetooth stack. Moreover, it is free foruniversities and works under Linux. Theirdevelopment kit called ”Impronto” just needsa text file license which is stored in the samedirectory as the application.

The specifications and the good documenta-tion ensured that it was the perfect stack tostart our project. If another stack is releasedby another company or targeting anotheroperating system, we could easily replace theRococo stack. It basically behaves like a plugin.The Rococo stack contains some helpers foradvanced Bluetooth functions but we did notuse them because they would break the JSR-82compatibility. Some of these extra functionsfurthermore adds a layer of complexity. Theyare unnecessary for a serial communicationto devices whose specifications are known inadvance. For instance, the services discoverywhich is essential for mobile phones could beleft apart in Bluemove.

5.2.3 Transmission between Blue-move and the module

Communicating with a module is a matter ofsending data to a specific URL starting with”btspp://” and followed by the address ofthe device in hexadecimal. The btspp prefixstands for ”Bluetooth serial port profile”. Thefirmware which is mounted on the Zeevo chipaccepts a serial communication. After theBluetooth headers, a data containing two bytesis appended. The first byte indicates a moduleID, the second byte is the servo position.The system was designed with a broadcastingsupport in mind. This turns out to be usefulwhen all modules are reset to the same value.The module ID is set to 255 for a broadcast(all modules receive the same packet). Anothervalue indicates a packet forwarded to one and

only one unit according to its ID.

In the current version of Bluemove, the ID isalways set to 255 but a packet is transmittedto its final destination using the btspp URL; nobroadcasting is used.

Java Application

Impronto stack

BlueZ librairies

Hardware

BlueZ stack

User space

Kernel space

Figure 5.1: From Java application to the Blue-tooth device

Figure 5.1 represents the communication flowfrom the Java application to the Bluetooth de-vice. The Impronto stack does not directly in-teract with the hardware device. Instead, it usesthe BlueZ [1] libraries which then interact withthe kernel Bluetooth drivers. With this scheme,Rococo Software do not need to rewrite codealready present in BlueZ and hardware depen-dent.


The Rococo stack

We did not have much problem with the Rococostack except some unsuccessful scans that ran-domly happen (devices are not detected at all).It is hard to tell whether they are caused by theRococo stack or the underlying Linux system.In such cases, it is recommended to reset theBluetooth device in Linux using the hciconfigcommand or to call hcidump to check the trafficon the Bluetooth device. If the problem per-sists, the best is to reset the kernel modules asfollows.



# rmmod hci_usb bluetooth# modprobe bluetooth hci_usb

The Java namespace which is in charge ofthe Bluetooth implementation is extremely well-designed and was straightforward to use. TheRococo stack is transparently integrated in theapplication and sending data is a matter of afew functions calls.

New features in Java 1.5

We used the latest version of the JDK, J2SE5.0 which is in fact Java 1.5. Useful featuresthat were previously missing in the Java lan-guage have been added in the new version [23].Among all these major updates, we used the fol-lowing features which had a significant impacton the ease of development:

• generic types

• autoboxing

• enhanced ”for” loop

• enums

The generic types are mostly present in codedealing with Collections (lists, hashmaps, etc.).In previous versions of Java, the Collectionsonly contained objects of type Object. It wasup to the programmer to insert casts when heretrieved objects from a collection. This kindof syntax was error-prone and could lead toarduous debug sessions. With generic types,an additional constraint is appended to acollection, it must contain objects of a giventype and casts are not needed anymore.

The autoboxing avoids clumsy conversionsbetween primitive types (int, float, double,etc.) and their equivalent Object counterparts(Integer, Float, Double, etc.). Previously toJava 1.5, one could not store primitive typesin collections. The programmer first had toconvert the primitive to its Object with codesimilar to list.add(new Integer(1234)).With Java 1.5, this extra code is not neededanymore: list.add(1234). The opposite isalso true. In Java 1.5, a primitive retrievedfrom a list does not have to be explicitly casted.

The enhanced ”for” loop was already presentin most high level languages such as C#,Python or PHP, though often named differently

(”foreach” keyword). It is a powerful syntaxthat avoids the creation of ”iterators” whenone just wants to read all elements from acollection. The code looks like: for (Integeri : list) {...} and is probably the mostuseful feature among the changes from Java 1.4to Java 1.5.

The enums that all C or C++ programmershave at least used once, are often used to definea set of choices. Prior to Java 1.5, the enums hadto be simulated through a sequence of staticfinal int. It was tedious to write and a valuehad to be given to each integer. In Java 1.5,an enum keyword has been added. Such a defi-nition looks like this: public enum Choice {ok, wrong, cancel };. Enums can be usedin switch/case blocks and are considered as ob-jects.


The Java 1.5 compiler

We faced serious problems with the Java 1.5compiler2. Our mathematical code raisedstrange errors with signs in floating operations.For example, a float or double variable wassupposed to be negative but the executedcode discarded the sign. This ended up withtotally wrong results in the interpolations andtimelines. It was actually hard to track thisproblem as it seemed to depend on externalconditions like the size of the code, previousrecompilations or changes in other classes.

After patiently investigating the differentsteps that the compiler went through, we con-cluded that the issue was not caused by the vir-tual machine or the operating system as it alsooccurred on a Windows XP platform.

We disassembled the generated bytecode andnoticed that the compiler simply removed thesigns of some constants. Code such as float f= -2.0f + a; could be interpreted like floatf = 2.0f + a; once compiled. One solu-tion was to move the constant at the endand add some parenthesis: float f = a -(2.0f);. Another possibility was to use theobject counterparts of the concerned primitive.The code would then use declarations like newFloat(-2.0f) but this led to complex code in

2all 1.5.x were plagued by this bug, for Bluemove, weused build 1.5.0 01-b08



mathematical routines. We tried to avoid thelatest solution as much as possible.

We filled a complete bug report and sent it toSun. Unfortunately, we did not get a response.We hope they will fix this problem as soon aspossible as it may lead to serious bugs and un-stable applications.

JBuilder designer

JBuilder comes with an integrated GUI designer(see Figure 5.2). This tool allows the user todraw the application interface on screen insteadof coding it. A lot of time is thus saved. More-over, coding a GUI interface can quickly becomeunmanageable when the complexity of the inter-face grows. However, we faced some problemswith the JBuilder designer.

Figure 5.2: JBuilder designer

When starting the designer on a newly cre-ated class, it worked as expected and was re-ally helpful. But as soon as we started to addour own code, especially constructor parame-ters or class variables with direct instantiation,JBuilder crashed. The returned error was thefollowing.

An unexpected exception has beendetected in native code outsidethe VM.

This happened under Windows and Linux andwas a really annoying problem because unsavedfile modifications were lost. We were forced tomodify GUI code directly by hand.

We tried other GUI designer such as JFor-mDesigner [33] or IntelliJ IDEA [20] but eachone has its own code generation style which didnot integrated well in JBuilder. So we continuedto use JBuilder designer and took the practiceto save our files regularly. For big GUI modifi-cations, we copied the JBuilder generated codeto a new class file, then worked on this version.

We finally copied the newly generated code tothe original class. Note that the ”JBuilder 2005Update 1” did not solve the problem.

5.3 Interface

5.3.1 Description

”Java-Motion” by Jean-Philippe Egger was thesoftware modified and used by Elmar Dittrichand Rico Moeckel to generate trajectories onthe robots shown in their videos. Unfortu-nately, Java-Motion lacks many features andsomehow looked too limited for the modularrobot project. One of the main drawbacks inthe version used by Elmar was the fact that onlysix modules could be managed. Moreover, Java-Motion did not provide a tool to draw smoothcurves, the trajectories were linearly interpo-lated.

We preferred to focus our efforts on a newsoftware that used some ideas present in Java-Motion but with a drastic change in the in-terface and flexibility. Bluemove was writtenfrom scratch because our new features wouldhave been incompatible with the code presentin Java-Motion. It was more efficient to rewritethings instead of fixing them. We also wantedto create an application that could be used withother robots, not only the Bluetooth modularrobot. If we did not go as far as a plugin system,we still have a flexible system split in several in-dependent parts. A given part could be replacedor slightly modified to fit with constraints andspecifications of another robot, protocol, etc.

As we had a good experience with Java, Swingand its graphical functions, we aimed at a niceand convivial GUI with custom controls whennecessary. This was particularly true for thetimelines which were simply too difficult to cre-ate with the standard Java controls. We alsotried to find the best solution for each problemrelated to human interaction, we wanted Blue-move to be simple and that the user could playwith the main functions without even readingthe documentation.

As said above, we took our inspiration fromJava-Motion and added ideas that we had seenin other softwares. Systems based on timelinesare present in many applications. Most of themdeal with video or audio editing.

Here is a non-exhaustive list of such softwares:

• Demopaja by Moppi Productions (video)



• 3DSMAX by Discreet (3d)

• After Effects by Adobe (video)

• Sonar by Cakewalk (audio)

• FruityLoop by FL Studio (audio)

Among the different applications cited in theabove list, one of them had a strong impact onBluemove: Demopaja [30]. It is a free realtime-animation authoring tool similar to MacromediaFlash and Adobe After Effects [3]. The inter-face is based on a tree. Its nodes can be ex-panded to display different types of timelines.These timelines contain trajectories with linear,smooth and hold keys, segments of curves canbe displaced or deleted.

Demopaja provides curves for different ob-jects: colours, scalars, ranges, etc. Another con-cept that we did not have time to implement inBluemove but which is present in Demopaja iswhat they call ”time segments”. It is, therefore,possible to enable or disable some parts of thesequence.

Figure 5.3: Demopaja by Moppi Productions

As stated by their authors, Demopaja isstrongly based on Adobe After Effects. Look-ing at a screenshot, we see many similarities inboth the interface and the ideas. There are clearadvantages of such interfaces. They are straight-forward to use and if they may look eye-candyat first, they are still the easiest way to defineand work with curves.

5.3.2 The different tabs

The current version of Bluemove is split intothree tabs:

• the timelines manager

• the modules manager

• the console

Figure 5.4: Adobe After Effects

The timelines manager

The timelines manager is in charge of the tra-jectories for all modules that were loaded inthe modules manager (from a previous projectstored on disk or a new project). It is composedof three parts which are custom Swing controls(modules tree, timelines tree and timescale).The left part is a summary of the project andits modules (name, range, address). This panelis in fact a tree whose nodes can be expandedor collapsed. The user can also disable a mod-ule or a subcomponent such as an actuator or asensor3. When a component is disabled, it turnsred. When activated, the panel is green. Whenexpanded, the components available in a mod-ule can be resized. The user just has to dragthe cursor over the grey bar at the bottom ofthe component zone.

Changes in the left panel are propagated tothe right panel that contains the curves. Thetrajectories can be drawn using the mouse.Clicking on the left button will add a new key.The key can be moved with a drag and drop(pressing the left button and keeping it downwhile moving the key). There are currently twotypes of keys available in Bluemove:

• Linear key

• Hermite spline key

Both can be mixed within the same curve,the interpolator will properly compute the tra-jectory. By default, the user works in a ”splinemode”. To add linear keys, he must select the”linear keys tool” icon in the icons bar. He canswitch back to splines keys with the ”spline keystool” icon.

3sensors are not available in the current version ofBluemove



A right click will bring a popup menu. Ifthe user right-clicks on a key, a key menu willappear. It features actions like deleting a keyor converting the key to the opposite type (toa spline if it’s linear and vice-versa). A right-click at another place (not on a key) will bringa global popup menu. The user can delete allkeys or converts them to the same type (linearor spline). Bluemove does not provide more ad-vanced features yet such as selecting some keys,moving or deleting a whole set of keys at once.These features are planned for the next version.

At the bottom of the timelines manager, atimescale is available. It gives informationabout the frames and the current frame positionon the curve. This position is represented by asmall triangle moving on the timescale. Drag-ging the mouse cursor over the timescale willshift the curves in time. The user can also scalethe time range using the zoom-in and zoom-outicons.

On the lower left part of the timelines tab,the player zone and its ”play/pause”, ”stop”,”repeat” buttons allow the user to send thedata to the robot, interrupt the sequence or en-able/disable looping of the whole sequence. Theend of the sequence is represented by the verylast key in all active trajectories. This is some-thing to consider when designing the trajecto-ries.

The modules manager

Bluemove has been built with the idea of stor-ing everything into a compressed file that we call”project”. The project contains the informationabout a robot, its modules and the trajectories.In the modules manager, one can modify thedifferent parts available in a project (see Figure5.5). The modules manager acts like a serialisa-tion and management system; it drives all rou-tines related to loading and storing data. Theuser can add, modify or remove modules. He canalso write a description about the robot and up-load a picture. It is indeed quite useful to havea sketch or a real picture of the modular robotwhen mounted. The modules manager is com-posed of a tree on the left side and a panel forsettings and information on the opposite side.

A module contains actuators or sensors; theinterface provides a way to deal with all theseparameters. The user can add or remove thesecomponents and change their settings (such asthe range for an actuator).

By pressing on the ”Apply” button, the usersaves the changes to the local version of project.The project can later be saved on disk using themenu bar or the save icon in the icons bar. Itis obviously possible to load a previous projectfrom the menu or the open icon. All parameterswill be restored as well as the trajectories. Anew project can be created using the new com-mand in the menu or the new icon.

The modules manager is synchronised withthe timelines manager. If a module is removedfrom the modules manager, the timelines willdisappear in the timelines manager. The sameapplies for the actuators and sensors. Changesin the modules manager (settings or new compo-nents) will be notified to the timelines manager.

Figure 5.5: Modules Manager

The console

The console tab (see Figure 5.6) displays the logmessages generated by Bluemove. There are fivelevels of messages:

• DEBUG: messages useful in order to debugthe application

• INFO: information messages

• WARN: a problem leading to an error oc-curred

• ERROR: something that should not havehappened

• FATAL: unrecoverable error

Each level is displayed in a distinct colour withits specific icon. This allows the user to quicklydiagnose what appended in the application.



Figure 5.6: Console


The small learning curve for the end-user

The timelines manager is a nice set of customcontrols. It is easy to use and quite powerful.The learning curve is small and the user canquickly add or delete keys, move them around.The integration with the modules manager isalso quite robust thanks to a last-minute ”inten-sive software engineering session”. The user willhave a summary of the whole robot with a quickglance at the left part of the timelines manager.As everything is based on a tree, the interfacespace is optimized and not too crowded.

The console

We did not encounter many problems with thispart. We only noticed that it could slow downthe application and the communications withthe robot if a large amount of messages wasprinted. The filter option is hence quite usefulin such cases. Printing a message takes about15 ns, this delay is insignificant compared to therest of the routines executed during runtime.


Writing bugs free and clean Swing con-trols are tedious

Writing complex Swing controls is quite crypticand error-prone. There are many concepts todeal with, including timing, refreshing, perfor-mance, interaction with the user (mouse events).It is quite time consuming because one has towrite everything from scratch. Bluemove stillhas some minor issues related to the timelinesbut it is sometimes hard to say whether they arecaused by Java or a bug in the application. For

example, when the user wants to resize a mod-ule component (left part of the timelines man-ager), the cursor is supposed to change when themouse is over the grey rectangle. When the ap-plication is in fullscreen, this does not work any-more. Coming back to a windowed mode fixesthe problem. Such a minor bug could also becaused by the Linux windows managers (metac-ity, fluxbox, enlightenment, etc.).

When we started writing the code for thetimelines, we quickly noticed that it would bedifficult to come up with a clean solution. A firstversion of the code was not satisfying and we de-cided to rewrite it with a slightly better archi-tecture. Despite the attempts to design a goodstructure using our knowledge in software engi-neering, we are pretty confident that it could beimproved and simplified if we had more experi-ence with Swing. The most complex part wasto write the code related to the tree system (ex-panding, collapsing components), there are stilla few bugs that may appear from time to timebut none of them is critical.

Attempts to tweak standard Java controlsfailed

In order to improve the interface, we tried touse the JTree control (tree control of Swing) forthe settings. We wanted to achieve somethingsimilar to what is proposed by .NET (Figure5.7) or the L2FProd components [11]. Thesecontrols provide rows with various settings likecolor pickers, text, number, sliders, etc. Unfor-tunately, the JTree and JList controls of Swingare rather limited. It is impossible to resize asingle row without a large amount of obscurecode. After extensively searching on Google, wecame to the conclusion that everybody had thisproblem but only a few bad solutions had beenproposed. It was also difficult to add controls in-side the row of a JTree/JList, though not impos-sible. Most of the suggested hacks have a signifi-cant impact on performance and we preferred tokeep a fast and clean code. The L2FProd couldhave been a solution but it lacked a real docu-mentation. As the settings window was not animportant part of Bluemove, we did not wastetoo much of our time on this issue.



Figure 5.7: .NET properties

5.4 The inners of Bluemove

In order to make a versatile application, we de-signed Bluemove in such a way that the differentparts were as independent as possible from eachothers. The modules manager could be modi-fied to support for example an I2C communica-tion instead of Bluetooth without big changes inthe timelines manager. However, there are stillsome links between all these parts, we did nottry to make a system based on plugins. It wouldhave been more complex to handle but we thinkthat features like scripting could replace partsof the advantages provided by plugins (more onthis in Section 7.2).

5.4.1 An overview of Bluemovearchitecture

On the code side, Bluemove is composed of twocentral parts: the timelines manager and themodules/project manager. They are themselvessplit into two conceptual groups: the core andthe GUI. The core is in charge of the logical andsystem operations; it is used by the GUI. TheGUI acts like a bridge between the user and thecore.

In Bluemove, the real ”brain” is the modulesmanager core. Its purpose is to link the time-lines, the modules, the communication part andthe rest of the settings. The modules manager isin charge of serialisation and persistence (load-ing/storing in files).

The timelines core maintains the curves, thisincludes algorithms dealing with keys, interpo-lation and other mathematical routines. The

modules manager GUI just needs to call themethods provided by the various objects at-tached to the modules manager core. On theother side, the timelines manager gets its infor-mation from the modules manager. When thetimelines manager asks for the curve X of themodule Y, the modules manager will query thetimelines core. The latest will provide the rightcurve that will be transferred to the timelinesGUI via the modules manager.

Modules Manager GUIModules Manager

Communication

Timelines Manager Timelines GUI

XML / Zip

Player

Curves /Interpolation

Figure 5.8: A schematic view of Bluemove ar-chitecture

The Bluetooth communication is initialisedby the modules manager after a request by thetimelines GUI. The modules manager delegatesthis threaded task to a subgroup of objects spe-cialized into communication and Bluetooth.

To sum up, there is a clear cut between theGUI and the underlying core. We could easilyswap two different user interfaces while keepingthe same core.

We invite the reader to look over the Blue-move programmers documentation for UMLschema and additional information about themethods, objects, and namespaces.

5.4.2 Linear and spline interpola-tion

Bluemove can compute linear and smooth tra-jectories. Each trajectory is made of severalkeys. A key is itself composed of two scalars: aframe 4 and a value. Two keys can not share thesame frame as this would lead to an inconsistenttemporal state. Moreover, a stronger constrainthas to be respected when interpolating a trajec-tory: it must be a function in the mathematicalsense. For the same frame, we can not havemore than one value. This is a problem whenworking with splines that are usually evaluated

4in this section, time or frame are equivalent, theyare proportional to each other



in a two-dimensional plane. They are not func-tions but parametric curves that can overlap.For the modular robot, we needed interpolationmethods, not approximations. Indeed to ensurecorrect motions, we had to be sure that the servois at the correct position at a given time. This isnot guaranteed by an approximated trajectory.We will now discuss how we solved these variousmathematical issues.

Linear interpolation

Linear interpolation is straightforward to imple-ment. Assuming that at least two keys A and Bare available (with At < Bt), we can computeany intermediate trajectory position y at time t(t ∈ [At, Bt]) using the following formula:

y(t) = Ay +t−At

Bt −At(By −Ay)

The main drawback of a linear interpolation isthat the first derivative is not continuous. Theconsequence is a complete absence of smooth-ness in the generated trajectory.

The smooth interpolation problem

For the modular robot, it was necessary to haveat least one type of interpolation that providedsmooth curve. By smooth, we mean trajectorieswith a continuous first derivative (speed). Thisavoids the sudden changes of speed that appearwith a simple linear interpolation and producejerky motions.

The problem of smooth interpolation has beenwidely covered in the numerical analysis field.Among the many methods developed through-out the last centuries, Lagrange’s interpolationis a famous way to pass a polynomial of degreeN − 1 through N points. However, this methodis not convenient for most purposes because itintroduces large oscillations. Moving or addinga single point on the curve will radically changethe shape of the whole curve. It is actuallyquite slow to compute and is consequently not agood interpolation scheme for a servo trajectory.Another method, the Chebyshev approximationminimizes the oscillations but as stated by itsname, it’s an approximation not an interpola-tion and the errors introduced by such a schemeare not acceptable.

What we can conclude after playing withhigh-order polynomials is that they are very sen-sitive to small perturbations in the keys posi-

tions and lead to unwanted oscillations (Runge’soscillations).

Piecewise interpolation schemes

Another way to solve the interpolation problemis to split the final trajectory into many pieces.Such methods are called ”piecewise interpola-tions” and most of them are based on ”splines”5.A piecewise interpolation is a good way to con-trol local conditions and only modify a part ofthe curve.

At this point, we can either use Bezier curvesor Hermite splines. There are other typesof splines such as B-Splines but their namesare confusing because they are approximationschemes.

It would have been possible to use Beziercurves but one must be careful with the posi-tions of the control points. In the case of a cu-bic Bezier curve, four control points are needed.The first and last points are placed at the keyslocations. The second and third points act liketangents. The curve is always enclosed by theconvex hull formed by these four points. Thecurve reduces to a function under a strict condi-tion on the X axis: the second and third controlpoints must not be moved before or after thefirst and fourth points.

To keep a continuous first derivative betweentwo Bezier curves, it is necessary to align thethird point of the first curve with the secondpoint of the second curve. This adds somecomplexity when the user moves a point sincethe tangents symbolized by the two middle con-trol points in both curves must satisfy the con-straints described above.

Hermite splines

Hermite splines do not exhibit this control prob-lem though it is more difficult to ensure that theparametric curve will not overlap in a ”S” shapeand hence lose its function properties. On theother side, the Hermite splines are simple to im-plement and in our case, it was easier to get acontinuous first derivative compared to Beziercurves. We thus used Hermite curves in Blue-move.

From the mathematical point of view, an Her-mite curve (often called ”cubic spline”) is aparametric curve expressed by a parameter swith s ∈ [0, 1]. It is constructed using a set

5”smooth lines”



Figure 5.9: An example of an Hermite spline

of four third-order polynomials which form theHermite basis functions as seen on Figure 5.10.An Hermite curve is composed of four vectors: astarting point and its tangent, the ending pointand its tangent. The four polynomials are alsocalled ”blending functions”. We will refer tothem using the notation H1(s), H2(s), H3(s)and H4(s).

H1(s) = 2s3 − 3s2 + 1

H2(s) = −2s3 + 3s2

H3(s) = s3 − 2s2 + s

H4(s) = s3 − s2

Figure 5.10: The Hermite basis

Each of the four vectors is multiplied by itsrespective Hermite function. The polynomialsare first evaluated using the parameter s. Next

the vectors are weighted and summed up to getthe final position. The starting point is multi-plied by H1, the ending point is multiplied byH2. The tangent for the first point is weightedusing H3 and the second tangent using H4.

Assuming we are working in the two-dimensional plane and the starting point is P1,the ending point is P2, the tangent for the start-ing point is T1 and the tangent for the endingpoint is T2, we obtain the following set of para-metric equations:

x(s) = P1x ∗ H1(s) + P2x ∗ H2(s) + T1x ∗H3(s) + T2x ∗H4(s)y(s) = P1y ∗ H1(s) + P2y ∗ H2(s) + T1y ∗H3(s) + T2y ∗H4(s)

With s at 0, the returned point will be P1.With s at 1, we will get P2.

Computing the tangents

There is a simple way to compute the tangentfor a key ~Kn. One just needs to retrieve theposition of the previous and next keys: ~Kn−1

and ~Kn+1. The tangent for ~Kn is the vector~t = ( ~Kn+1− ~Kn−1) ∗α where α is a smoothnessfactor usually between 0 and 1 (a higher valuewill give a smoother curve).

There are special cases at the start and end ofthe trajectory. When the next key is not avail-able, we can compute the tangent using the pre-vious and current key. The similar thing can beperformed to find the tangent for the very firstkey. In that case, the tangent is the vector be-tween the current and next key.

Converting an Hermite spline to a func-tion

With the description in the previous section, wesupposed that the curve was evaluated in a two-dimensional plane. It is not a function since thesame value on the x axis could have more thanone position on the y axis. For the trajectory, wehad to find a way to convert the Hermite splineto a real function. Moreover, the parameter sdefines the position along the curve. It is notrelated to the x axis which is the time axis inour case. To find a s parameter given a timevalue along the horizontal axis, we did not usean analytical solution but a simple numericalmethod: the bisection method.



To find a parameter s for a given X (timevalue), we first compute the position on thecurve with s = 0.5. If the value x(0.5) is aboveX, it means that the parameter s is too high. Insuch a case, we compute the middle value of therange [0, 0.5], we obtain 0.25 and compute thecurve with the parameter s = 0.25. Otherwise,we compute the middle value of [0.5, 1.0] whichis 0.75. The algorithm recursively evaluates theposition on the curve and splits the range in twosmaller parts. A stopping condition is met whenN iterations have been done or the error is belowa given threshold.

For Bluemove, 12 iterations are enough for agood accuracy. The resolution of the s parame-ter is fully determined by the minimum step sizewhich is 1

212 = 0.0002.

5.4.3 Persistence

As almost all softwares, Bluemove needs to saveand retrieve its data from disk. This is calledpersistence. It can be done using data bases,XML files, binary or text files. In Bluemove, wechose to use the XML standard for persistence.XML is widely used today and lot of libraries areavailable. One of the best of them is Xerces [17].It provides a DOM [35] implementation which isexactly what we need. DOM is an API whichallows the creation of XML tree with simplefunctions. We also used Xalan [16] which pro-vides XPath [36] features. XPath is a languagewhich allows retrieving nodes of a XML docu-ment without complicated XML parsing. Bothof Xerces and Xalan are free softwares.

When saving a project, a DOM tree is createdwith all the modules parameters such as mod-ule name and address, components and sensors.The DOM tree is transformed afterwards into aXML file using Xerces serialization possibilities.

When opening a project, the module manageris regenerated by reading the XML files. Thisis done using XPath. A disadvantage of XPathis its slowness. However we do not handle largeXML files so this is not noticeable.

The timelines are treated in the same way;they are just stored in a separate file. This al-lows a better reliability and separation of con-cepts.

As explained at the beginning of Section 5.3.2,a Bluemove project is a compressed archive.The modules and timelines XML files are thuspacked in this archive. We used the ZIP formatbecause it is widely present and Java has an API

for handling such files. Below is a typical projectarchive content.

config/timelines.xmlconfig/modules.xmlCreated on 19 01 2005 - 16 23 09images/model.png

Note that there is a file calledCreated on 19 01 2005 - 16 23 09. This isan empty file created the first time that theproject is saved. It is indeed impossible tocreate an empty ZIP file with the Java API.



Chapter 6

Experiments

6.1 Two working modulesand an inactive skeleton

As we only had two fully mounted modules, wehad to play with this limitation in mind and tryto find interesting configurations. Looking atthe videos produced by Elmar Dittrich helpedus to find some robots based on two workingmodules and a few inactive units.

Even with the most basic configuration, wenoticed that the smooth interpolation offerednice motions compared to the jerkiness of thelinearly interpolated trajectories. Using Blue-move, we were able to quickly test variouscurves. Most of them are small oscillations witha shifted phase between the two working mod-ules.

6.1.1 2-standup

This modular robot is inspired from 3-head2tail dragon carpet.avi [13]. The basic ideais to start from a side position. The robot bendsitself and quickly returns in a straight position.This fast movement makes it rotate and reachits moving position. The robot can then moveforward using simple oscillations.

One important thing in this modular robotto take into consideration is the alignment ofthe modules. The centre of gravity may slightlymove according to the main axis and it is there-fore difficult to predict the motion. Figure 6.1shows this modular robots.

6.1.2 3-stickworm

This one was discovered almost by accident. Asall modular robots we tried were composed ofunits connected in the same axis, we had theidea to put one module perpendicular to the oth-

Figure 6.1: A 2 modules example

ers. This leaded to an interesting kind of wormwhich moved laterally.

Quick movements with low amplitude are re-quired so as to get a good locomotion. Thismodular robot is represented on Figure 6.2.

Figure 6.2: A 3 modules example

6.1.3 More examples

YaMoR units combinations are almost infinite.Even with only two or three modules, it is possi-ble to imagine tons of different modular robots.



The number of trajectories for each unit is evengreater.

A genetic algorithm would no doubt havehelped to discover innovative configuration thatnobody would have expected. We are lookingforward playing with the results of Daniel Mar-bach and making Bluemove compatible with hisapplication.

The two examples describe above and moreexample videos are available on the web site ofthe project [14].



Chapter 7

Further developments

7.1 Hardware

7.1.1 Mechanic

Servos

The servos used in YaMoR were selected fortheir low cost and high torque. They have aweak point as shown on Figure 7.1. One of thewheels inside the servo take place in the plastichole. Because of high load on YaMoR arm, thewheel finally leaves its position and the servoremains blocked.

Figure 7.1: Weak point of the servo

Maybe a more expensive servo could be agood investment for an enhanced unit robust-ness. It would be interesting to test smaller ser-vos. There is not much space left in the unitand adding sensors (see Section 7.1.2) would beproblematic with the current design.

Batteries

When designing the YaMoR robot unit, Elmarplanned to put the batteries along the servo.This can be seen on Figure 4.1. He defined thesize of the module with this idea in mind. WhenRico developed the electronic components, he

found out that the best solution was to put theboards along the servo. He moved the batteriesto the bottom of the module, in a horizontalposition. The problem is that the module is50mm large and the batteries is 48mm long. Thebatteries are too wide and we could not firmlyfix the sides of the unit. We looked for smallerbatteries but did not find a good replacement.Andre Badertscher had the great idea to millthe two panel at the location of the batteries(see Figure 7.2). This way, it was possible tocorrectly screw the side panel.

Figure 7.2: Milled side panel

Modules connection

The connection of a module to another is donewith Velcro-like tape. There is a male and fe-male version which should be used together.These two types are visible on the arm of therobot on Figure 7.3. This Velcro-like tape al-lows to quickly reconfigure a modular robot andtry new configurations. Although the link be-tween the two modules is strong, it is not stableenough to ensure reliable operations. It wouldbe interesting to try other solutions such as mag-netic or mechanical ones.



Figure 7.3: Male and female Velcro-like tape

Note that we finally use only the male version(in foreground on Figure 7.3). They connectwithout any problem but a male/female connec-tion is definitely too weak.

7.1.2 Electronic boards

Sensors

YaMoR units are totally blind. There is nofeedback for the module about its environment.Adding sensors like distance sensors (see Fig-ure 7.4), cameras, shocks sensors or temper-ature sensors to the units could provide use-ful information about the environment. Thesedata could be used in order to adapt the com-portment of the modular robot. We have al-ready taken sensors into account in Bluemovealthough they are not yet available.

Figure 7.4: Distance measuring sensor

Sensors also imply bidirectional communica-tion. Bluetooth is naturally designed for thiskind of communication. Moreover, the Zerialfirmware is a serial cable replacement and thusallows transmission in both ways. Most of the

work would be on the FPGA part which shouldsend the sensors values to the Bluetooth board.Slight modifications should also be done in thecommunication package of Bluemove in order toreceive the data.

FPGA board

Distributed control The Xilinx Spartan 3 ofthe FPGA board is clearly under used. It onlyfeatures a PWM generator although it couldsupport up to six MicroBlaze [37] soft proces-sor cores. One big improvement would be tohave completely autonomous modules with allthe controls delegated to the FPGA and com-municating with each other using the Bluetoothboard. However, the actual Zerial firmware willnot be adapted for this task because it only al-lows one connection at a time. A more sophis-ticated protocol should be implemented. Morelow-level investigations about Bluetooth proto-col are certainly required.

FPGA configuration In the current YaMoRunit, FPGA configuration must be done withXilinx tools and programming hardware inter-face. With a lot of modules, this operation is re-ally demanding. A wireless configuration couldbe done by the Bluetoothboard. The ARMprocessor of the ZV4002 would be responsiblefor providing the needed signals. The Zerialfirmware should be modified in order to recog-nise a given information telling it that config-uration bitstreams will follow. This probablyrepresents the main work. Some output pins ofthe GPIO should be dedicated and connected tothe corresponding inputs on the FPGA board ei-ther on the JTAG or serial lines 1. This featurewill avoid a lot of waste of time.

Software related information are given on Sec-tion 7.2. We also recommend the reading of ”AnFPGA Dynamically Reconfigurable Frameworkfor Modular Robotics” [34].

7.2 Software

FPGA configuration

As explained in Section 7.1.2, Bluemove shouldbe adapted in order to send the bitstreams gen-erated by Xilinx tools. A specific data sequence

1FPGA boards provide JTAG and Slave Serial pro-gramming mode



should also be defined so as to inform the Blue-tooth board software that configuration datawill follow. Moreover a ”done” informationshould be sent back to Bluemove. Algorithm1 represents a possible implementation.

Algorithm 1 Wireless FPGA configuration1: CFG = {modules to be configured}2: ERR = {}3: for all m such that m ∈ CFG do4: create a connection to m5: if connection succeeded then6: send the configuration mode sequence

to m7: send the bitstreams to m8: if not received done message then9: add m to ERR

10: error message for m11: else12: remove m from CFG13: configuration succeeded for m14: end if15: end if16: end for17: if CFG = {} then18: all configurations succeeded19: else20: check modules which are in ERR21: end if

Maximum of allowed robots

The Bluetooth protocol allows a maximum of7 devices in a piconet and a maximum of 10fully loaded piconets in a scatternet. This givesa total of 80 devices. However, for physical2

and technical reason, it will be almost impos-sible to reach this limit. A 80 units modularrobot would be too heavy and the communica-tion latency probably too high. However, wedo not have enough working modules to experi-ment. We estimate that a modular robot using12 units would be probably the physical limit.We can hardly predict the Bluetooth commu-nication capacity but we estimate that it couldsupport the physical limit. The Bluemove ca-pacity is, however, not limited and depends onthe computer capacity.

2The servos have limited torque.

Real-time control

The current version of Bluemove allows the userto change keys position while playing. This pro-vides a kind of interactive play with the mod-ular robot. An additional way to perform real-time control would be the use of box connectedto other boxes. Figure 7.5 shows an example.The boxes on the left represents inputs (sensors,key pressed, mouse position, ...), boxes in themiddle are transformations (addition, multipli-cation, if-then-else, ...) and finally the box onthe right applies the previous transformationson the given parameter. This interactive con-trol is more ”robot centred” than changing thekeys position (”module centred”).

Module 1Amplitude

Sensor 2Sensor 1 Mouse X

Add

Multiply

Figure 7.5: Real-time control

Scripts

An interesting feature could be the scripting ofcurves. Instead of drawing the curve by hand,a scripting language could be used. One of thepossible solution is BeanShell [7]. It allows theuser to easily write loops, branches and evencomplete programs. Below is an example ofBeanShell usage.

% for(i=0;i<10;i++) {y = Math.sin(i);print(y);

}0.00.84147098480789650.90929742682568170.1411200080598672-0.7568024953079282-0.9589242746631385-0.279415498198925860.6569865987187891



0.98935824662338180.4121184852417566

This scripting language does not require vari-able declaration or strict typing. Thus, theuser could draw curves by writing a script andstoring the wanted position in a given variable.This would be more efficient to get curves frommathematical functions such as sinus. More-over, BeanShell is specially designed for Java soit could be integrated without too many prob-lems in Bluemove.

Module templates

When building a modular robot with Bluemove,it is necessary to describe the structure of themodules. At the moment of writing, Bluemovecan only control YaMoR units. So instead ofdescribing these units every time, it would bemore efficient to have a template module whichrepresents the YaMoR unit.

Import/Export

There is several projects related to YaMoR mod-ular robot at the BIRG. All of them use com-puter simulations in order to evolve modularrobot. The reader is invited to read works ofYvan Bourquin [9] and Daniel Marbach [21].Here the idea is to retrieve data from simula-tions and import them into Bluemove in orderto recreate curves. This could be really inter-esting for comparisons between simulation andreal world. Another possible feature is to exportdata from Bluemove and import them into com-puter simulations. The data can thus be evolvedand imported back into Bluemove.

XML would be a perfect data exchange for-mat for this. A possible example would be thefollowing.

<bluemove><module name="Head">

<key time="0.0" position="0.0"><key time="1.0" position="-1.0"><key time="2.0" position="0.5">

</module><module name="Tail">

<key time="0.0" position="0.3"><key time="1.0" position="0.5"><key time="2.0" position="-0.8">

</module></bluemove>

There would be certainly some work to do inthe computer simulation softwares so as to makethem speak the same language as Bluemove.

Blocks

An interesting feature would be the ability to de-fine blocks in Bluemove. We can imagine repeat,ping-pong or skip blocks. It is often necessaryto have a first step in which the modular robotsets its default position. After that, it moveswith a cyclic movement and finally goes backto its initial state. This could be achieved bydrawing the cyclic movement into a loop blocksurrounded by the one time initialisation andstopping steps. This is represented on Figure7.6.

Figure 7.6: Blocks



Chapter 8

Conclusion

We have seen in this report that Bluetoothvia an USB stick was the best way to controlthe YaMoR robot from a desktop computer. De-spite the problems we had with Java 1.5, we arepretty confident when we look at the final resultthat it was the right choice to write a portableand robust Bluetooth application. Thanks tothe Rococo stack and the Swing interface, ourtimelines based Bluemove tool provides an easycontrol over the robot for the end-user.

Unfortunately, we did not have time to con-struct more modules due to the long delays toget the ordered electronic components. Nev-ertheless, we enjoyed the soldering sessionsand discussions about mechanical and electronicproblems related to this project.

Acknowledgments We want to especiallyacknowledge Prof. Auke Ijspeert, AlessandroCrespi, Andres Upegui, Andre Badertscher andthe rest of BIRG and LSL members. We aregrateful to Rico Moeckel for his precious helpwith the electronic boards and Elmar Dittrichfor his work on the module. We thank ArianeKnuesel for reading this paper and making use-ful suggestions to improve its readability.



Appendix A

Bluemove short manual

This chapter quickly describes the user inter-face of the Bluemove application. It is dividedinto three parts: the first one explains how to in-stall the software and its requirements, the sec-ond one gives an overview of the user interfaceand, finally, the third part provides a step bystep example which shows how to create a sim-ple project with Bluemove.

A.1 Installation

In order to run properly, Bluemove requiressome additional softwares and libraries. The fol-lowing list summarizes the requirements for thisapplication:

• A Linux system on a x86 machine

• J2SE 5.0 (Java JDK 5.0 or JRE 5.0)

• Java Bluetooth stack JSR-82 compliant

Other needed libraries (log4j, xerces, ...) arealready included into the application. You donot need to care about them.

A.1.1 J2SE 5.0

Bluemove needs the J2SE 5.0 from Sun Mi-crosystems. Bluemove takes advantage of thelatest features of J2SE 5.0. In order to get thebest performance, it is important to use the lat-est J2SE 5.0 version. You can choose to in-stall the J2SE Development Kit (JDK) or theJ2SE Runtime Environment (JRE) dependingon whetever you are a developer or not. Youcan find the latest J2SE 5.0 here [22]. We willnot present the installation of the Java Environ-ment. Instructions are available in the down-loaded archive.

In order to see if the J2SE 5.0 is correctlyinstalled, open a new terminal and type the fol-lowing command.

$ java -versionjava version "1.5.0_01"...

You should get a string with "1.5". If not,please reinstall the J2SE environment and fol-low carefully the instructions.

A.1.2 Java Bluetooth stack

In order to communicate with the module, youneed a Java Bluetooth stack . There is a lotof different stacks available for Linux, Windowsand embedded systems. Rococo [31] offers afree implementation of the JSR-82 [19] calledImpronto for University students. Other JavaBluetooth stacks can be found here [2]. By de-fault, Bluemove is compiled to run with the Ro-coco Impronto stack.

Rococo Impronto

Rococo distributes its Impronto DeveloperKit for students under a license which doesnot allow us to distribute it with our soft-ware. Instead you must fill in the formavailable on Rococo website1 and wait forthe confirmation e-mail. After you getthe impronto-1.3-1.i386.rpm, you can sim-ply install the Rococo Bluetooth stack withrpm -ivh impronto-1.3-1.i386.rpm. Thisshould install the required BlueZ libraries [1]. Ifyou encounter any problems, please make surethat BlueZ is correctly installed and configuredon your system. Further information aboutthe Impronto installation can be found in thefile impronto/user_guide.pdf of the Bluemovearchive.

Finally, you have to read and agree theLinuxLicense.txt file. If you agree with the

1http://www.rococosoft.com/registration linux.html



license, you must copy it into the same direc-tory as Bluemove.jar. The Impronto stack willnot work without this license file.

A.1.3 Bluemove

Bluemove is distributed as a JAR archive. Ev-erything you need to run the application is em-bedded into this file. Thus, the only thing youneed to install Bluemove is to copy the JARarchive named Bluemove.jar in a directory. Werecommend to unpack the Bluemove archive inyour home directory and run the application di-rectly from that location.

As seen above, do not forget to copy the Im-pronto license file in the same directory as Blue-move.

A.1.4 Launching the application

Once the J2SE 5.0, the Java Bluetooth stackand Bluemove are installed, you can finallylaunch the application. To start with, you needto initialise your Bluetooth device. Open aterminal and type the following command as”root”.

# hciconfig hci0 up# hciconfig hci0hci0: Type: USB

BD Address: 00:0C:76:48:87:7A...

Your ”BD Address” should not be equal to00:00:00:00:00:00. If so, please check yourkernel configuration and make sure that theneeded modules are loaded or compiled into thekernel.

You can now go into the Bluemove directoryand type the following command.

$ LD_LIBRARY_PATH=/usr/lib java \-classpath .:Bluemove.jar \birg.bluemove.main.core.Bluemove

The path /usr/lib represents the location ofthe file libimpronto.so which is normally in-stalled in /usr/lib.

You should now see the Bluemove splashscreen and then the main screen. If not, pleasecheck that all the previous steps were success-fully completed.

You are ready to discover the power of Blue-move and the pleasure of modular robotic.

A.2 User interface

When you start Bluemove, you see the mainview of the application which contains four im-portant parts:

• the menu bar

• the tool bar

• the tabbed pane

• the status bar

The tabbed pane contains several tabs which arerespectively used to draw the module curves, tomanage the modules, and to view the log mes-sages. In the next section, we will take a closelook at the different items available in the menubar.

A.2.1 The menu

The menu bar is located at the top of the win-dow. It is composed of three menus, each onecontaining several menu items.

The File menu

This menu allows you to do the main operationson a project. You can create a new project,open or save a project. You can also quit theapplication. The last opened or saved project isremembered and can thus be quickly reopened.

The Options menu

This menu allows you to set the properties of theapplication. All the settings are locally storedon your computer.

The Help menu

This menu contains a menu entry called ”Help”.It opens your favourite browser and redirectsit to the Bluemove help site. The menu item”About” displays information about your sys-tem.

A.2.2 The tool bar

The toolbar contains shortcuts for useful actionslike creating a new project, saving or opening aproject.



Figure A.1: Menu

Figure A.2: Tool bar

A.2.3 Timelines tab

The timelines tab is the heart of Bluemove to-gether with the modules manager. You candraw trajectories for modules in the timelineslisted there.

Left part

Each module is composed of one or more actua-tors2. Sensors can also be part of a module. Atthe moment, sensors are displayed but no man-agement is available. The name and the addressof the module is displayed.

Right part

In this right part, you will be able to draw thetrajectories of an actuator. There are two keytypes:

• Linear key

• Hermite spline key

You can mix these two kind of keys in the sameactuator timeline without any restriction. Theinterpolation algorithm will take care of curvescomposed of these two types of keys.

A.2.4 Modules Manager tab

Within the modules manager you can declarethe different parts of your modular robot. Youcan describe every module, set its name andaddress. Each module can have several actu-ators. These components have a name and a

2A YaMoR module contains one actuator (a ”S-71”servo)

Figure A.3: Timelines

range which will be used to send the position tothe module.

Please notice that the YaMoR servo name is”Servo1”. You must use this name for the actu-ator when using a YaMoR unit.

Figure A.4: Modules Manager

A.2.5 Console tab

The console tab displays the log messages gen-erated by Bluemove. You can set the level ofthe output and the refresh rate. There are fivelevels of messages:

• DEBUG: messages useful in order to debugthe application

• INFO: information messages

• WARN: a problem leading to an error oc-curred

• ERROR: something that should not havehappened

• FATAL: unrecoverable error

Each level is displayed in a distinct colour withits specific icon. This allows you to quickly di-agnose what appended in the application.



Figure A.5: Console

A.2.6 The status bar

The status bar displays information about thecurrent action. It is also used to display impor-tant messages.

Figure A.6: Status bar

A.3 Tutorial: a small exam-ple

In this section, you will get to know how tocreate a simple Bluemove project. We considerthat you have already installed the applicationand that you are able to start it. You will alsoneed to have two functional YaMoR units.

A.3.1 Step one: add a module

First of all, start the Bluemove application. Af-ter the splash screen, you get a window similarto Figure A.7.

Figure A.7: Main screen

Now you have to describe the modular robotphysically. In order to do this, switch to themodules manager tab. At the top of the leftpart, you should see a small icon representinga salamander followed by the text ”Project”.Click on this label. This should enable the”Add” button at the bottom of the left part.Click on ”Add”. A new module called ”Mod-ule1” is inserted.

A.3.2 Step two: edit a module

Click on the label ”Module1”. You should get ascreen similar to Figure A.8.

Figure A.8: Modules manager

Now, on the right part, edit the ”Mod-ule name” field and type ”Head”. Enter theaddress corresponding to this module. Herewe suppose that our module has the address”424952470001”3. Edit the ”Comment” textarea and type ”This is the head of our mod-ular robot.”. You can now click on the ”Apply”button. Your window should look like FigureA.9.

Figure A.9: Module edition

3You can also use the inquiry function to found theavailable modules.



A.3.3 Step three: add an actuator

A module without an actuator can not move.The YaMoR units have one actuator named”Servo1”. Let us add it to our ”Head” module.Expand the node ”Head” on the left part. Twonodes should appear: ”Actuators” and ”Sen-sors”. Click on ”Actuators” and then click onthe ”Add” button. You get a new actuatorcalled ”Actuator1”. Click on the label ”Ac-tuator1”. You notice that the right part haschanged. Edit the field ”Actuator name” andtype ”Servo1”. This is the servo name of theYaMoR units. Set a ”Min value” of ”-90” and a”Max value” of ”90”. Click on ”Apply”. Yourwindow should be similar to Figure A.10.

Figure A.10: Actuator edition

A.3.4 Step four: add anothermodule

You should now be able to add another mod-ule without any problems. So restart at stepone and add a new module called ”Tail” withone actuator named ”Servo1” which range is be-tween ”-90” and ”90”. We suppose that thismodule address is ”424952470002”. You shouldend with a screen similar to Figure A.11.

A.3.5 Step five: draw a moduletrajectory (spline)

We have finished the physical description of ourmodular robot. In order to see our animal mov-ing, we have to draw the trajectory of its actu-ators. Here you will see the power of this soft-ware. Let us move to the ”Timelines tab”. Yourscreen should look like Figure A.12.

Expand the ”Head” module by clicking on thesmall blue arrow located close to the label. Dothe same with the actuator ”Servo1”. Now you

Figure A.11: Second module

Figure A.12: Timelines tab

should see the timeline on the right. Enlargethe timeline a bit by dragging the bottom line.Select the ”Spline tool” in the tool bar. Drawthe same curve as the one on Figure A.13. Yousurely noticed that spline keys are representedby a blue round.

Figure A.13: The first curve with spline keys

A.3.6 Step six: draw a moduletrajectory (linear)

Repeat the above step for the ”Tail” module.This time you will use only linear keys. Selectthe ”Linear tool” in the tool bar. Linear keys



are represented by a green rhombus. You shouldend with a window similiar to Figure A.14.

Figure A.14: The second curve with linear keys

A.3.7 Step seven: save the project

Before going further, it is high time to save yourproject. Click on the menu named ”File” andselect the item ”Save As...”. A file chooser dia-log appears. Choose the directory you want andname your project ”first bluemove.zip” like onFigure A.15. You probably noticed that Blue-move projects are simply ZIP archives.

Figure A.15: Saving a project

A.3.8 Step eight: play

We arrive at the last step of this tutorial. Poweron the modules and program the YaMoR FPGA.This operation is described at Section 7.3.3 of[28]. Build the modular robot as shown on Fig-ure \ref{fig:step-10}. Click on the ”Play”button located at the bottom of the timelinestab. After a few seconds, the modules shouldstart to move. If so, congratulations, you havesuccessfully completed this tutorial. If nothingis moving then maybe your Bluetooth device isnot correctly initialised. You can switch to the

”Console” tab and set the debug level to ”ALL”.Retry this step and look at the console.

A.3.9 Conclusion

We briefly looked at the basic operations ofBluemove. There are a lot of other featuresthat were not described in this tutorial. How-ever, you should be able to discover them onyour own. Do not forget to periodically checkthe help website [14]. Lots of information onBluemove are available there.



Bibliography

[1] Bluez. http://www.bluez.org.

[2] Java bluetooth. http://www.javabluetooth.com.

[3] Adobe. After effects. http://www.adobe.com/products/aftereffects/main.html.

[4] Aibo - Sony Japan http://www.jp.sonystyle.com/Product/Aibo/Ers-311b_312b/Store/.

[5] ARM. Processor core. http://www.arm.com/products/CPUs/index.html.

[6] ASL Flying robots http://asl.epfl.ch/research/projects/AdaptiveVisionbasedFlyingRobots/index.php.

[7] BeanShell. Lightweight scripting for java.http://www.beanshell.org.

[8] BIRG. Amphibot i: an amphibious snakerobot. http://birg.epfl.ch/page53468.html, 2003.

[9] Yvan Bourquin. Self-organization of loco-motion in modular robots. http://birg.epfl.ch/page53073.html.

[10] Jennifer Bray and Charles F. Sturman.Bluetooth: Connect Without Cables. Pren-tice Hall, 2000.

[11] L2FProd components. L2fprod compo-nents. http://www.l2fprod.com.

[12] Robot Labs http://www.robot-labs.jp/top.html.

[13] Elmar Dittrich. Modular robot unit - char-acterisation, design and realisation. http://birg.epfl.ch/page50163.html, 2004.

[14] Kevin Drapel and Cyril Jaquier. Us-ing bluetooth to control a yamor modularrobot. http://birg.epfl.ch/page56602.html.

[15] Jean-Philippe Egger. Roboka. http://birg.epfl.ch/page48822.html.

[16] The Apache Software Foundation. Xalanjava. http://xml.apache.org/xalan-j.

[17] The Apache Software Foundation. Xerces2java parser. http://xml.apache.org/xerces2-j.

[18] Bruce Hopkins and Ranjith Antony. Blue-tooth for Java. APress, 2003.

[19] JCP. Jsr-82. http://www.jcp.org/aboutJava/communityprocess/review/jsr082/.

[20] JetBrains. Intellij idea, an intelligent javaide intensely focused on developer produc-tivity. http://www.jetbrains.com/idea.

[21] Daniel Marbach. http://birg.epfl.ch/page32031.html.

[22] Sun Microsystems. J2se 5.0. http://java.sun.com/j2se/1.5.0/download.jsp.

[23] Sun Microsystems. J2se 5.0 in a nut-shell. http://java.sun.com/developer/technicalArticles/releases/j2se15/.

[24] Seiko Epson Corporation - Monsieur2 http://www.epson.co.jp/e/newsroom/news_2003_03_10.htm.

[25] Morph 3 (Atom Project) - http://www.japantimes.co.jp/cgi-bin/getarticle.pl5?nn20030820b8.htm.

[26] Murata about Morph3 - http://www.murata.com/articles/ta0255.pdf.

[27] Rico Mockel. Design and construction ofan autonomous modular robot unit withbluetooth and fpga. http://birg.epfl.ch/page53075.html, 2004.

[28] Rico Mockel. Getting started userguide. http://birg.epfl.ch/page53075.html, 2004.


http://www.bluez.org

http://www.javabluetooth.com

http://www.javabluetooth.com

http://www.adobe.com/products/aftereffects/main.html

http://www.adobe.com/products/aftereffects/main.html

http://www.jp.sonystyle.com/Product/Aibo/Ers-311b_312b/Store/



http://www.arm.com/products/CPUs/index.html

http://www.arm.com/products/CPUs/index.html

http://asl.epfl.ch/research/projects/AdaptiveVisionbasedFlyingRobots/index.php




http://www.beanshell.org

http://birg.epfl.ch/page53468.html




http://www.l2fprod.com

http://www.robot-labs.jp/top.html

http://www.robot-labs.jp/top.html







http://xml.apache.org/xalan-j

http://xml.apache.org/xerces2-j

http://xml.apache.org/xerces2-j

http://www.jcp.org/aboutJava/communityprocess/review/jsr082/



http://www.jetbrains.com/idea



http://java.sun.com/j2se/1.5.0/download.jsp

http://java.sun.com/j2se/1.5.0/download.jsp

http://java.sun.com/developer/technicalArticles/releases/j2se15/

http://java.sun.com/developer/technicalArticles/releases/j2se15/

http://www.epson.co.jp/e/newsroom/news_2003_03_10.htm


http://www.japantimes.co.jp/cgi-bin/getarticle.pl5?nn20030820b8.htm



http://www.murata.com/articles/ta0255.pdf

http://www.murata.com/articles/ta0255.pdf






[29] J.D. Nicoud and J.C. Zufferey. Towardindoor flying robots. In Proceedings ofthe IEEE/RSJ International Conferenceon Intelligent Robots and Systems, pages787–792, 2002.

[30] Moppi Productions. Demopaja. http://moppi.inside.org/demopaja/.

[31] Rococo. http://www.rococosoft.com.

[32] Seiko Epson Corporation - LightweightHelicopter http://www.epson.co.jp/e/newsroom/news_2004_08_18.htm.

[33] Karl Tauber. Jformdesigner, wysi-wyg gui designer for java swing userinterfaces. http://www.ktauber.com/formdesigner.html.

[34] A. Upegui, R. Moeckel, E. Dittrich,A. Ijspeert, and E. Sanchez. An fpgadynamically reconfigurable framework formodular robotics. 2005.

[35] W3C. Document object model (dom).http://www.w3.org/DOM.

[36] W3C. Xml path language (xpath). http://www.w3.org/TR/xpath.

[37] Xilinx. Microblaze soft processor core.http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=micro_blaze.

[38] Zeevo. System-on-chip solutions for blue-tooth and other wireless communicationsapplications. http://www.zeevo.com.

[39] J.C. Zufferey, D. Floreano, M. vanLeeuwen, and T. Merenda. Evolving vision-based flying robots. Proceedings of the2nd International Workshop on Biologi-cally Motivated Computer Vision (LNCS),2002.


http://moppi.inside.org/demopaja/

http://moppi.inside.org/demopaja/

http://www.rococosoft.com



http://www.ktauber.com/formdesigner.html

http://www.ktauber.com/formdesigner.html

http://www.w3.org/DOM

http://www.w3.org/TR/xpath

http://www.w3.org/TR/xpath

http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=micro_blaze



http://www.zeevo.com


Index

µFR-II, 9Bluetooth

stack, 37

ACL, 12Adobe After Effecs, 23Aibo, 8ARM, 16ASL, 9

Bezier curve, 27Bisection method, 28Blimp, 9BlueOS, 16Bluetooth, 7, 11

btspp, 20Connect Without Cables, 7

Bluetooth packet, 13BlueZ, 20

C++, 19C#, 19Console, 24

Demopaja, 22Dengoro, 8DotGNU, 19

Ericsson, 11

F2 plane, 9FPGA, 42frequency hopping, 11

Hermite spline, 27humanoid robot, 8

I Bee, 8IBM, 11Intel, 11Interpolation, 26

Lagrange polynomials, 27Linear, 27Piecewise interpolation, 27Smooth, 27

Java

autoboxing, 21DOM, 29enhanced for loop, 21enums, 21generic types, 21J2SE, 37JAR, 38Java 1.5, 21javac, 21JSR-82, 8, 19, 20, 37log4j, 37Swing, 19, 25xalan, 29xerces, 29, 37

Java-Motion, 6, 22JBuilder, 22JTAG, 15, 16

KDDI, 8

L2CAP, 12

MAX1774, 15MicroBlaze, 16Module, 14

Bluetooth, 16charger, 14FPGA, 15Power, 14

Mono, 19Monsieur II-P, 10Morph, 10Motorola, 19

Nokia, 11, 19Nuvo, 10

OBEX, 12, 19operating system, 16

Persistence, 29piconet, 11pulse wide modulation, 6PWM, 6, 16

RFCOMM, 12, 19



Rococo, 37Impronto, 37license, 38

RS232, 6, 16

scatternet, 11SCO, 12SDP, 12, 19Seiko Epson Corporation, 9, 10Sony, 11System on Chip, 16

Timelines Manager, 25timelines manager, 23timescale, 24Toshiba, 8, 11

VHDL, 6, 16

XML, 29

YaMoR, 14

Zeevo, 16, 20Zerial, 16Zip, 29


Documents

Using Bluetooth to Control a YaMoR Modular Robotbiorob2.epfl.ch/pages/studproj/birg57460/report-final.pdf · Project description 1.1 Introduction The aim of the YaMoR (Yet another