Bluetooth Khepera robot control and communication

(1)

Bluetooth Khepera robot control and communication

HS–IKI–MD–04–002 Patrick Duchstein

Submitted by Patrick Duchstein to the University of Sk¨ovde as a dissertation towards the degree of Master of Science in computer science.

September 2004

I certify that all material in this dissertation which is not my own work has been identified and that no material is included for which a degree has already be

conferred upon me.

Patrick Duchstein

(2)

Master’s Dissertation

Bluetooth Khepera robot control and communication

Patrick Duchstein 10th November 2004

supervised by Nicklas Bergfeldt

(3)

I would like to thank my supervisor Nicklas Bergfeldt for his supportive work and his very motivating comments. I would also

like to thank Jens Auer for many constructive ideas and discussions, and my family for giving me mental and financial

support during my stay in Sweden.

(4)

This thesis aims to provide a solution for wireless control of, and communication with and among Khepera robots, making use of the Bluetooth wireless technology, to allow wireless control of multiple robots in real time. It is based on the foregoing work of other students who constructed a module for wireless control of Khepera robots over Bluetooth, but they were not able to control more than one physical robot at a time.

Khepera robots, as well as many wireless solutions to control those, are closely investigated, and an introduction to Bluetooth is given. An implementation of a Bluetooth protocol stack, which was carried out in the context of this dissertation, and constitutes one of the main parts of this project, is described in detail. The performance of the work discussed throughout this dissertation is evaluated w. r. t. transmission times of data over the wireless link, and afterwards compared to other solutions for real-time control of Khepera robots, e. g. a solution to control a Khepera robot over a wireless radio link. Furthermore, previously simulated experiments with autonomous agents are carried out on physical robots, to test the quality of the wireless solution. It is shown that the solution presented here operates much more efficient than any other existing solution, thus provides a very useful aid for the research community that is experimenting with physical robots in general, and real Khepera robots in particular, in order to simplify research, and allows for a broader spectrum of experiments.

Keywords Khepera, robots, Bluetooth, wireless, radio, multiple robots, control, communication

(5)

List of Figures

2.1 The Khepera robot . . . 4

2.2 Schematic illustration of the Khepera robot . . . 5

2.3 The Khepera robot equipped with a KBU . . . 7

4.1 Bluetooth layers compared to the OSI model . . . 16

4.2 Bluetooth connection types . . . 17

4.3 Communication between the lower protocol layers . . . 20

4.4 HCI command packet format . . . 21

4.5 HCI event packet format . . . 22

4.6 HCI ACL data packet format . . . 22

4.7 Packet format for connection-oriented channels . . . 24

4.8 Packet format for connection-less channels . . . 24

4.9 Signal packet format . . . 25

4.10 RFCOMM device types . . . 25

4.11 RFCOMM connection- and channel establishment . . . 26

4.12 RFCOMM packet structure . . . 26

6.1 Baudrate comparison . . . 33

6.2 Comparison of ACL packet types to the KBU . . . 34

6.3 Comparison of ACL packet types to the Khepera . . . 35

6.4 Switched master/slave roles . . . 36

6.5 Packet transmission with two Khepera robots running . . . 37

6.6 Comparison of the KBU to the Radio Turret and a wired serial connection 40 6.7 ANN of a Braitenberg vehicle . . . 40

6.8 Runtime before having to recharge the batteries . . . 41

(8)

4.1 ACL packet types . . . 18

4.2 SCO packet types . . . 19

5.1 HCI Initialization . . . 31

6.1 Bluetooth transmission times . . . 38

6.2 Radio turret transmission times . . . 39

6.3 Direct serial transmission times . . . 39

(9)

1 Introduction

Autonomous agents gather an increasing importance in today’s society and research.

Among the major topics of interest is communication with and between agents, which puts an agent into a position to perform even more complicated tasks than it would be able to do on its own. Billard & Dautenhahn (1997), for example, study a teacher- learner situation where a robot communicates information about the inclination it senses to another robot; Billard, Ijspeert & Martinoli (1999) describe experiments carried out in simulation and on physical robots, where robots learn the locations of objects in an environment and communicate those to other robots. The impact of implicit and explicit communication between autonomous agents on their performance was investigated by Balch & Arkin (1994), coming to the conclusion that explicit communication offers a significant benefit to the performance in tasks where little implicit communication is offered. Easton & Martinoli (2002) study different communication schemes and the collaboration of robots on a task where two agents have to cooperate on pulling a stick out of the ground, observing that the use of explicit communication offers significant advantages in terms of performance.

Carrying out research on physical robots very often requires a complicated and expensive setup. The requirement of a constant power source and cables to have a permanent connection to a separate computer which analyzes sensor data and controls the robot might be a challenging task to fulfill. Whilst several solutions for a constant power supply exist (see Martinoli, 1999), robots in many cases still have to be wired to a control station, as long as they are not controlled by an on-board computer. Wiring is difficult, especially in scenarios with multiple robots, since rotary and flexible cable connections have to be used in most cases, apart from the fact that cables may influence an agent’s movements. Hence, physical robots need some form of wireless communication to simplify setting up scenarios in the real world, and to make efficient use of them.

This thesis deals with the problem of wireless communication between mobile and autonomously acting agents. Small mobile robots, called Khepera robots, are equipped with a communication module which performs wireless communication over Bluetooth.

Several problems arise when trying to fulfill this task:

Performance To control an autonomous agent throughout time, it is indispensable to enable the controlling solution to control the agent in real time. Thus, the latency between sending data to the agent and the agent receiving this data has to be as low as possible.

Bandwidth To be able to control multiple agents at the same time, the bandwidth on the controlling host has to be broad enough to support this task.

(10)

These factors matter especially in the case that global communication is used, i. e.

communication to or among multiple agents at the same point in time.

1.1 Motivation

The motivation for this project stems from the lack of an efficient and reliable wireless communication module for Khepera robots. The standard solution that is used by the majority of researchers for wireless communication among these robots, the K-Team Ra- dio Turret, was observed to have a long transmission latency, and to exhibit transmission errors (e. g. Kub´ık, 2003). Furthermore, a lot of research that has been done with these autonomous agents was based on experiments carried out in simulation only (e. g. Bajaj

& Ang Jr., 2000; Gadanho, 2003), most probably due to too complicated or expensive setups for physical robots. This work tries to help making experiments with real robots easier for the research community.

Several solutions existed at the time this thesis was written, but none was able to control more than one robot equipped with additional modules in real time. A detailed analysis of some of the other solutions will be done in section 2.4 on page 8. This thesis is mainly based on the master’s dissertations of two former students at the University of Sk¨ovde, written in 2002 (Eriksson, 2002; Karvosenoja, 2002). Within these dissertations, the construction of a bluetooth module suited for the Khepera robots is discussed, and several prototypes were constructed. In Karvosenoja (2002), one of the aims declared as Possibility to control at least 4 robots at the same time via Bluetooth from the Radio Base Station was not fully met since the whole solution was too slow – hence it was only possible to control one robot at the same time. Several attempts were carried out to improve the overall speed of the Khepera Bluetooth Unit (KBU) (Karlsson, 2003;

Kostamo, 2003), but all of them failed for completion. Another attempt to improve the speed is described within this dissertation.

1.2 Aims and Objectives

1.2.1 Aims

The project described in this thesis is basically composed of two aims. The first one is to find out whether the bluetooth system is able to control more than one Khepera robot at a time. If it is not, try to find causales for this. The second aim consists of providing a basis for Khepera robots to directly communicate with each other over Bluetooth, without the need for a separate controlling base station.

The expected outcome of the project is to have a solution for wireless real time control of multiple Khepera robots, being controlled exactly the same way as wired robots, without the need for software adaptations, thus making further research using these robots easier w. r. t. verification of simulated scenarios on physical robots. Furthermore, a step towards direct robot-to-robot communication over Bluetooth will be done, allowing for fully autonomous, communicating robots.

(11)

1 Introduction 1.2.2 Objectives

The objectives of this thesis stem from a more detailed analysis of the aims, including an evaluation of the foregoing work, and some basic ideas on the approach that is to be applied.

To meet the aims mentioned in section 1.2.1 on the page before, several objectives have to be achieved.

• Study and understand the bluetooth specification. Since the specification is a document comprising of more than 1000 pages with a lot of cross-references, a good understanding of what Bluetooth is and how it works is a basic requirement.

• Partially reimplement and extend the bluetooth communication unit on the robots, make it conform to standards and controllable by a bluetooth dongle. To enable wireless communication over Bluetooth with the Khepera robots without com- plication, and to enable direct robot-to-robot communication at all, the software running on the KBU has to be reimplemented.

• Evaluate the performance of the implementation. Timing measurements of transmission rates have to be performed to verify that the solution works as expected.

• Check how the simulator YAKS performs on real robots by applying simulated soccer-playing robots to real robots. Do some empirical tests on how previously simulated robots work in reality.

1.3 Thesis outline

The remaining part of this dissertation is structured as follows. In chapter 2, the background of this thesis is presented, along with some samples of previous work. In chapter 3, different approaches for achieving the aims are compared. Chapter 4 focuses on a detailed explanation of what Bluetooth is and how it works, and in chapter 5 the results are presented. Chapter 6 then sums up the outcome and the main contribution of this thesis, and contains suggestions for further work.

(12)

2.1 Khepera robots

Stemming from Brooks (1991) claim for situatedness and embodiment of autonomous agents, and the fact that carrying out robot experiments in a simulated environment offers many advantages w. r. t. simplicity of setting up experiments and the time needed to carry them out, there is a need for the existence of a robot which is easily adaptable to a simulated scenario. The alternative, to carry out robot experiments in simulation only and not evaluating them in reality, typically involves plenty of simplifications of the real world, for the sake of performance. Furthermore, the postulations mentioned above are violated in this case. Brooks (1992) points out the danger of trying to solve problems in simulation which never appear in the real world with a physical robot; he also states that experiments which work very well on simulated robots in many cases fail when carried out in the real world, due to differences in real world sensing and actuation.

Therefore, and due to the fact that no general, and robust miniature-sized robot architecture was available at low cost, the Khepera robot was introduced (Mondada, Franzi & Ienne, 1994). Compared to other physical robot architectures, it is available at an affordable price, and much more convenient to use. Its general and extendible, but for a potential user still simple architecture makes it suitable for a lot of different demands when experimenting with robots. Thus, Khepera robots provide a good base for doing research with physical robots, giving more research groups the possibility to use real robots for their manifold experiments.

Figure 2.1: The Khepera robot

2.1.1 Khepera robot architecture

The Khepera robot, shown in figure 2.1, has a cylindrical shape, measures 55 mm in

(13)

2 Background

or by four on-board recheargable batteries which allow it a maximum lifetime of 40 minutes before having to be recharged.

The robot itself is equipped with two motors and wheels, eight sensors which allow proximity- as well as ambient light measurements. Furthermore it offers two extension busses, a serial and a parallel one, which allow additional turrets to get connected to it.

Figure 2.2 illustrates the layout of the robot.

Figure 2.2: Schematic illustration of the Khepera robot with its eight integrated sensors (light gray), two motors (black) and the connections for extension turrets (dark gray).

The CPU of the Khepera robot is a Motorola MC68331 with 256 kB RAM and 128 kB EEPROM, running a minimal operating system implemented by K-Team, the man- ufacturers of the robot, offering features as multiprocessing, or uploading programs.

The serial connection to the robot can be used to control it by issueing simple control commands, e. g. to read data from the integrated sensors or to send speed commands to the motors. In addition, it is possible to upload small control programs to the robot which are in turn executed by the robot itself, so that no connection to it, be it over a serial cable or wireless, is necessary.

Khepera extensions

Several extensions, so-called turrets, are available for the Khepera robot. These can be plugged on top of a robot to enhance its functionality. Most turrets allow stacking of even more turrets on top. What follows is a description of some turrets, which were in part used within the evaluation of this project:

K213 vision turret The K213 vision turret (K213VT) allows for linear gray level vision. At maximum rates, a 64-pixel 8-bit grayscale image is provided every 50ms.

Furthermore, light intensity measurements are possible. No other turret may be stacked on top of this one.

Gripper turret Using this turret, objects in the environment of the robot can be ma- nipulated. It contains an arm that allows to be lifted, and a gripper at the end, including an optical barrier indicating whether an object is inside the gripper.

When an object is gripped, it is possible to measure its electrical resistivity. The

(14)

Gripper Turret offers connections of the Khepera extension bus towards the top of it, to allow for other turrets to be used at the same time.

Radio turret The Radio Turret provides a Khepera robot with communication options;

the robot can be controlled by a Radio Base Station or directly communicate with other Radio Turrets. The maximum transmission rate offered by the turret is 9600 baud. Due to the fact that only a very low baudrate is offered, the turret is unusable for real time sensor evaluation and control of Khepera robots. Other extension units may be stacked on top of the Radio Turret.

K2D video turret If enhanced video acquisition is required, this turret offers a 2D picture of the environment at high quality. A separate cable connection to the turret is necessary to view the pictures. This turret is a top turret, i. e. no other turrets may be stacked on top of it.

Wireless camera vision turret More possibilities w. r. t. video and sound are provided by this turret, which allows wireless transmission of video and audio data directly from the turret to an external receiver, which in case may be connected to a video grabber and an audio input on a separate computer. In contrast to the K2D Video Turret, it allows a robot to move autonomously without the need for rotating, wired contacts. This turret is a top turret.

2.1.2 Experiments with Khepera robots

A lot of researchers make heavy use of the robot described here. One example are the experiments described by Nolfi & Parisi (1995), where a Khepera robot equipped with a gripper module was trained, using the genetic algorithm technique (Holland, 1975) and Artificial Neural Networks (ANNs) (McCulloch & Pitts, 1943), to explore an environment avoiding walls, pick up objects with the gripper module, and drop them outside of the arena. This experiment was carried out in simulation in the first place, and then downloaded and evaluated on a physical Khepera robot.

Floreano & Mondada (1998) carried out a series of experiments to test ANNs in terms of its adaptation capabilities to new conditions. In the first set of experiments, a Khepera robot is trained to move around in a maze, avoiding walls, using techniques of evolutionary robotics (Cliff, Harvey & Husbands, 1993); the underlying ANN is then tested on a bigger robot with similar features, the Koala robot, and re-trained to adapt to the new circumstances, e. g. the different size of the robot, and a differing, but similar, sensor placement. In the second set of experiments, a Khepera robot with a discharging battery is placed inside an arena containing a light tower and a recharging area; the task of the robot consists in moving within the arena – to achieve that it had to recharge its batteries periodically. The environment was then re-arranged and the robot had to adapt to the new circumstances. These experiments were entirely carried out on physical robots.

(15)

2 Background

2.2 Bluetooth on Khepera robots

This section describes the foregoing work on the KBU. The motivation of the whole project was to produce a general Bluetooth turret which can be used on all different kinds of robots, as long as they are controlled by a RS232, Universal Asynchronous Receiver/Transmitter (UART) or Universal Serial Bus (USB) interface. Therefore two students described the design of such a turret within their Master dissertation (Eriksson, 2002; Karvosenoja, 2002); furthermore, throughout their projects, the hardware was constructed, and several prototypes were built. This turret, the Bluetooth General Board (BTGB), which was also used for the project this dissertation is about, offers an external RS232-, as well as a USB-connection to directly connect the Bluetooth host controller to a host, e. g. a PC, to use the turret as a type-1 device. Furthermore, a microcontroller is integrated to allow using the BTGB as a type-2 device (see section 4.6 on page 24 for a description of the different device types).

The KBU, that is, the BTGB connected to a Khepera robot (see figure 2.3), connects one of the UART controllers of the integrated Microcontroller Unit (MCU) to the serial pins of a Khepera robot. Thus, the KBU is a type-2 device, which receives Khepera commands transmitted over the Bluetooth wireless link from a computer and transfers those over the serial connection to the robot. In turn, it receives answers from the Khep- era and transmits them back to the computer. Connections for the Khepera extension bus are offered towards the top of the turret to allow for other turrets to be stacked on top of the KBU.

Figure 2.3: The Khepera robot equipped with a KBU

The KBU’s main part consists of an ATMEL ATMega128L MCU, which is able to act as a Bluetooth host. One of its UART controllers is connected to an Ericsson ROK 101 007 Bluetooth device, which forms the Bluetooth host controller and is physically placed on top of the MCU. Of the UART-pins offered by both ICs, only the serial input- and

(16)

output-pins are connected to each other, control pins, which are mandatory to enable flow control between the devices, are not connected.

Although the KBU prototypes worked very well w. r. t. connecting to a robot and controlling it, the transfer rate between the controlling PC and the Khepera robot was very low, i. e. it was impossible to control more than one robot in real time; no clear reason for this was found at first.

Several attempts were carried out to improve the data throughput, based on the suggestions of the constructors. The Bluetooth-stack was replaced by a self-implemented, very specific and efficient one, directly integrated in Yet Another Khepera Simulator (YAKS) (Carlsson & Ziemke, 2001), carried out by a student in his spare time; this slightly improved the transmission rate, but did not provide a final solution. In a further step, the RS232 connection to the BTGB was replaced by a USB connection (Karlsson, 2003; Kostamo, 2003); this project was not finalized due to problems with the USB driver, discovered in a late stage of the project. The next step consisted in changing the Bluetooth link type, using an Synchronous Connection-Oriented (SCO) link instead of an Asynchronous Connection-Less (ACL) link to make use of a high synchronous data transmission rate in both directions; the implementation was never completed.

2.3 YAKS

Yet Another Khepera Simulator (YAKS) is a simulation environment for Khepera robots, developed by members of the school of Humanities and Informatics at the University of Sk¨ovde. Its main advantages lie in efficiency, and the focus on Evolutionary Algorithms and ANNs. It is easy to adapt to new scenarios, and therefore used by many researchers for simulation of their own experiments, mainly within the area of evolutionary robotics (Cliff et al., 1993). The simulator runs on several operating systems, and provides either 2- or 3-dimensional visualization capabilities, as well as a non-visual simulation mode to carry out experiments very fast. Control of physical robots to verify simulated experiments is integrated, originally implemented to make use of wired physical robots and the K-Team Radio Turret.

2.4 Related Work

2.4.1 Wireless robot control

Feng, Borenstein & Wehe (1996) present a Wireless Development System for mobile robots, consisting of three main components: a joystick interface to allow remote control over a robot’s components while it is running; a low-cost radio control system, usually used in model aircrafts, was used for the wireless transmission of the joystick signals. A wireless computer connection, provided by a radio modem, which operates at a serial transmission rate of 19200 baud, to allow software updates on the robot and external computerized control. Finally, the system offers a video transmitter on the robot, as

(17)

2 Background

well as an adequate receiver on the other end. The publication also discusses a wired alternative for remote robot control.

A robot equipped with an Institute of Electrical and Electronics Engineers (IEEE) 802.11b interface (wireless LAN) was developed by Nguyen, Pezeshkian, Raymond, Gupta & Spector (2003), given the task to explore and map an environment. To maintain a connection to an operator’s console, several relay robots were following the lead robot and stopped at certain positions where the quality of the wireless link dropped below a predefined threshold, i. e. the communication channel was about to get disconnected due to far distances.

2.4.2 Khepera wireless interfaces

Besides the Radio Turret for Khepera robots, engineered and manufactured by K-Team, there exists another solution for wireless Khepera control and communication, developed during a student research project at the University of Paderborn, and introduced by Rüping, Löffler, Odenbach & Rückert (1999), which based on infrared communication using the fieldbus system CAN between the Khepera robots and a master device, mounted on top of an arena. The master device also acts as a repeater, to enable direct communication between Khepera robots. The system allows transmission rates of up to 100kbps. Since the master device’ serial interface only could be connected to a controlling computer at a transmission rate of 9600bps, it was not suited to control more than one Khepera robot in real time.

An extension turret for the Khepera robot allowing it to be controlled over Bluetooth was engineered at the Fachhochschule Regensburg, Germany¹. A general Bluetooth controller board manufactured by INSYS Microelectronics was modified to plug onto a Khepera robot’s extension bus. The module does not offer connections for further extension turrets to be plugged on top of it, and is thus unusable for more than bare control and sensor evaluation of a Khepera robot equipped only with its integrated sensors. The KBU, in contrast, offers the possibility to plug further extension turrets on top of it.

Another infrared communication module for the Khepera robot is proposed in (Mar- tinoli, Franzi & Matthey, 1997). It allows selective and explicit communication among multiple robots in real time, at a transmission rate of almost 20 kb/s. The main drawback of the module is a very low range of coverage in practice, around 15cm. Furthermore, it does not allow controlling a Khepera robot from an external controlling computer.

2.4.3 Mobile Bluetooth controller

A distributed multi-robot system designed to solve a team-based search and destroy task is presented in (Barnhard, McClain, Wimpey & Potter, 2004; McClain, Wimpey, Barnhard & Potter, 2004). Two robots were given the ‘Honeybee task’, where one robot has to explore an environment to find an object, and then lead the other robot to its

1http://www.insys-tec.de/pdf/i-modul bluetooth.pdf (last visited July 2004). Regrettably, no further information was published on this module.

(18)

location solely by communicating its location. The robots were equipped with handheld PCs which exhibited Bluetooth functionality. Using the Bluetooth serial port emulation RFCOMM, the first robot transmitted its coordinates within the environment to the other robot. In a second phase of the project, multiple robots were given the task to locate an object, and the first robot to find it communicates its position to all other robots, which should then also move there.

The following work is referenced in this dissertation since the underlying hardware used complies in part with the hardware used throughout this project; the task consisted in evaluating Bluetooth for sensor networks (Leopold, Dydensborg & Bonnet, 2003). Sen- sor networks provide wireless distributed network access to intelligent sensors, controls, and processors that are embedded in equipment, facilities, and the environment. The publication discusses how far the Bluetooth wireless technology is suited to meet the needs of sensor networks, e. g. the ability of inter-communication among sensors for col- laborative processing of signals, or routing issues. For evaluating the technology, an Atmega128L was used as MCU, to connect the Bluetooth device, an Ericsson ROK 101 007, to a sensor. A minimal Bluetooth stack had to be implemented on the MCU, on the higher protocol layers also providing for routing and (re-)connection issues within larger networks. The performance of the implementation was evaluated w. r. t. maximum data throughput and energy consumption.

(19)

3 Method

This chapter deals with different steps to meet the objectives mentioned earlier.

The main idea behind this project consists in the replacement of the BTGB on the side of the controlling computer with a Bluetooth dongle, connected over a USB interface, and to utilize a Bluetooth stack on the computer that comes with the dongle or the operating system, which in all cases should previously have been verified to run stable and efficient. Hence, to eliminate one bottleneck of the Bluetooth wireless connection w. r. t. transmission speed.

3.1 Study and understand the bluetooth specification

The Bluetooth specification (Bluetooth SIG, 2001), that is, the standard definition of what Bluetooth is and how it works, is a document comprising of more than 1000 pages;

plus further standard descriptions for RFCOMM in ETSI (1997). To accomplish a good general understanding of it, and all the details necessary to proceed with the other objectives, three methods may be applied.

Read the specification only Since the Bluetooth specification provides the definition of Bluetooth, including all details, attentively reading it is one way of understanding what Bluetooth is.

Secondary literature A lot of secondary literature has been written about Bluetooth (e. g. Bray & Sturman, 2001; Miller, Bisdikian & Siep, 2001), partly by the people who helped developing the Bluetooth standards documents. These publications provide a deeper insight into Bluetooth functionalities and additional facts that are not mentioned in the standard.

Consult other people Many researchers and programmers are actively working with the Bluetooth wireless technology and thus have a good understanding of it. So deeper insights may be gained by consulting them.

Throughout this project, the method used for gaining knowledge about Bluetooth was mainly a combination of intensively studying the Bluetooth specification and consulting other people. The standard document was used as main reference, whilst other people were consulted when questions arose, such as unclear terms in the specification. Sec- ondary literature was not consulted very frequently, due to the fact that it does in most cases not contain more information that is of use for the implementation; this probably stems from the fact that all secondary literature concerning Bluetooth is based on the primary literature, i. e. the standard specification documents.

(20)

3.2 Reimplement the Bluetooth communication unit

Two main questions arise when doing a reimplementation of the Bluetooth stack that is to be used on the BTGB.

1. Several Bluetooth stacks were developed by other people for to be used on embedded devices, so it has to be deliberated about adapting those to the specific needs for this project, or do a completely new implementation from scratch.

2. The choice between a minimal implementation and a fully standards compliant Bluetooth stack has to be made.

3.2.1 Bluetooth Stack

Since Bluetooth is a fully standardized technology, including the transport layer that is used for communication between the Bluetooth host and the host controller, it is possible to port the stack, one of the main software components within a Bluetooth device, between differing platforms. One of the main prerequisites for porting is the availability of the source code. Some of these stacks were closer investigated for porting capabilities within this project.

BlueZ¹ BlueZ, the official Linux Bluetooth protocol stack, been implemented for the kernel of the free operating system linux, thus, also the stack is freely available including the source code. The stack is stable, well-structured and efficient, but due to its code size, its very huge memory requirements, and its close relation to the Linux kernel, it is not suited to run on the MCU of the BTGB.

BTnode² BTnode is a project which offers a freely available general Bluetooth controller, which uses the hardware identically to the BTGB w. r. t. the MCU and the Bluetooth device; the only exception is a larger amount of memory supplied with it.

Furthermore, the MCU is connected to the Bluetooth device in a different way, flow control between the devices is enabled, in contrast to the BTGB. A Bluetooth stack including the source code is also provided by the project. The two differences mentioned above form the limiting factors for the use of the stack within the BTGB: the amount of memory available is smaller, and no flow control between the modules is available; thus, deep going changes within the source code of the stack of BTnode would be necessary to make use of it on the BTGB.

Since no Bluetooth stack could be found best suiting the needs for this project, the decision was taken to implement it from scratch. The reimplementation is based on the source code provided by the foregoing work on the KBU, which already provided basic functionalities.

1http://www.bluez.org (last visited August 2004)

(21)

3 Method 3.2.2 Minimal or full implementation

A minimal implementation of a Bluetooth stack offers the capabilities to do basic communication with other Bluetooth entities also offering a minimal stack, specifically adapted to fulfill certain needs; it follows the standards specification only as little as minimally required. A full implementation in contrast follows the standards and is able to interact with other Bluetooth entities without further adaptations.

Implementing a minimal Bluetooth stack can be attained in a very small amount of time; a very small and, due to it’s problem-specific style, efficient solution is achievable.

Problematic within a minimal implementation for the BTGB is the requirement for an adapted Bluetooth stack on the end of the controlling computer. Hence, no stack provided with Bluetooth hardware or an operating system could be used; all applications that make use of the BTGB would have to be changed as well. Furthermore, to make use of a USB Bluetooth dongle to communicate with the BTGB instead of another BTGB, and to allow for the serial emulation to take place without the need for application-side adaptations, a fully standards compliant Bluetooth stack is a requirement for the success of this project, to provide a Bluetooth communication module which is suited for use in other research projects on real robots.

3.3 Performance evaluation

The performance of the KBU can be evaluated in different ways. One way is to measure the time for round-trips of data packets of different size, originating from a controlling computer, being sent to the Khepera, and transmitted back. This way, one gets a global view on the whole solution’s performance. A drawback is that only long transmission paths with transmission channels of different types can be measured; no detailed data for each transmission channel on its own can be acquired. Though, the acquired data is very easy to get in touch with real data that is being sent to and received from the robot when using it for research purposes. Furthermore, influence of the baudrate applied at all serial connections can be measured.

Another way of evaluating the performance of the KBU consists of measuring the time packets of different sizes needed for a round-trip from a controlling computer to the KBU and back. More detailed insight into the performance of the BTGB itself can be gained this way; the Khepera robot is then completely left out of the evaluation, which is unproblematic since it is not in the hand of the programmer to increase the transmission speed of the serial channel besides predefined values.

A third way of performance evaluation is to use engineering tools, such as an oscillo- scope, for detailed measuring of packet transmission times on all transmission channels.

A very detailed picture of the KBU and all used equipment is acquired by applying this method, however, the effort needed to carry it out is very high.

To compare different controlling solutions for the Khepera robot and get a picture of how fast the KBU is, timing comparisons can be carried out for different connection types, such as the KBU and a direct serial connection to the robot.

(22)

Within this project, a combination of the first two and the fourth method mentioned will be used for performance evaluation in the first place, since the most meaningful factor that matters when carrying out experiments on a physical robot is the transmission speed between a controlling computer and a Khepera robot. To adjust parameters that influence the performance, such as the packet type used for wireless communication, it is furthermore necessary to get a deeper insight into the transmission speed between the BTGB and a controlling computer. Furthermore, a comparison of transmission times for different connection types will be carried out. If it turns out that the KBU’s overall transmission times are too slow, more detailed measurements will be done for all transmission channels.

(23)

4 Bluetooth

This chapter gives an overview over the Bluetooth wireless technology; however, many details have been left out for to simplify and shorten these explanations.

Bluetooth wireless technology is a worldwide specification for a small-form factor, low-cost radio solution that provides links between mobile computers, mobile phones, other portable handheld devices, and connectivity to the Internet. Its main use lies in the replacement of cables over short distances. Bluetooth was invented in 1994 by L.M.

Ericsson. Its name stems from Harald Bl˚atand I, the king of Norway and Denmark in the middle 900s.

The contents of this section are primarily based on the Bluetooth specification standard (Bluetooth SIG, 2001) and, the standard for emulation of serial ports in GSM TS 07.10 (ETSI, 1997).

The Bluetooth wireless technology has several main properties:

Wireless Bluetooth is a wireless technology, i. e. providing the opportunity to communicate without cables.

Open standard The standard itself is open, i. e. available at no cost. It is developed, published and promoted by the Bluetooth SIG.

Certification Certification for devices stating that they are fully compliant to the standard is available, though not required by the Bluetooth Special Interest Group (SIG). This is important for companies selling Bluetooth-enabled products to be able to interact with other Bluetooth entities without complications.

Low cost Bluetooth communication modules are available at a very low cost. The frequency spectrum used for communication is free to use without licensing cost around the whole world.

Audio and data Different communication modes exist for transferring audio and data over the wireless link. This stems from different demands: when transferring audio signals, a constant data rate is required to suppress delays, whilst an error-free and guaranteed link has to be provided for data communication.

Security Basic cryptographic mechanisms for to send encrypted data over the wireless link are provided by the technology.

No transmission errors The Bluetooth wireless link for transmission of data can be configured to detect and even correct errors that occur during the wireless data transmission, thus provide a totally error-free link. The prerequisites for this are established in the baseband (see section 4.3 on page 17).

(24)

Low power The power consumption of a Bluetooth integrated circuit is usually very low, due to a very low transmitting power.

Robustness As a result of the physical channel definition by hopping through 79 Radio Frequency (RF) channels (see section 4.3 on the next page), the Bluetooth wireless link is quite robust concerning interferences with other wireless technologies.

4.1 The Bluetooth layered architecture

The Bluetooth wireless technology is layered according to the scheme shown in figure 4.1.

It is difficult to classify the Bluetooth layers into the OSI-model, since it was created to fulfill application specific needs, in contrast to the OSI-model, which is a strictly ordered stack – thus, only a loose comparison is possible.

Radio

Baseband / Link Controller Link Manager Protocol

HCI L2CAP Applications Application

Presentation

Session

Transport

Network

Data Link

SDP RFCOMM

Physical

OSI Reference stack

Bluetooth

Figure 4.1: Bluetooth layers compared to the OSI model The following sections describe the layers in more detail.

4.2 Radio

According to the Bluetooth SIG (2001), the Bluetooth transceiver is operating in the 2.4 GHz Industrial, Scientific, and Medicine (ISM) band. This band is free, i. e. no license fees have to be paid for using it worldwide.

Three power classes are offered, allowing for different Bluetooth devices with different areas of coverage: an embedded device that runs on batteries does not have the need

(25)

4 Bluetooth

for long-range transmissions, but low power consumption, and vice versa for equipment that is line-powered.

4.3 Baseband – Link Controller and Link Manager

The Bluetooth link controller operates to carry out the baseband protocols and other low-level link routines. The link manager sets up and controls the link.

A connection between two or more Bluetooth devices is always characterized by one master device and up to seven active slave devices. Thus, it allows either point-to- point or point-to-multipoint connections; a group of one master device and several slave devices connected to it is called a piconet. Multiple piconets may be connected to form a scatternet – in this constellation, a device can be the master in one piconet and at the same time act as a slave in another piconet; or, devices may be slave in multiple piconets. Figure 4.2 illustrates this. Data can only be transmitted from the master to one or all slaves in the piconet, or from a slave to the master; no direct data transmission between slaves is possible; this implicates for direct robot-to-robot communication that packets might have to be routed over the master device, depending on the number of piconets the host controller is able to be a member of. Slave devices in a piconet may enter a parked state while they are not active in the channel; in this state, they can not send or receive any data, but still remain synchronized to the network.

Piconet 1 Piconet 2

M

M S

S

S S S

S

Figure 4.2: Bluetooth connection types. Two piconets that together form a scatternet.

The highlighted nodes form the master devices.

A physical channel in Bluetooth is charaterized by a hopping sequence through the 79 RF channels defined in the 2.4 GHz ISM band. The hopping sequence is determined by the master device of a piconet. The physical channel is subdivided into timeslots: every 625 microseconds the RF channel is switched pseudo-randomly. If a data packet contains more data than can be transferred within one timeslot, the same RF channel as where

(26)

the packet transmission started is kept for another timeslot. Packet transmissions from the master to a slave device starts in even-numbered time slots, whilst transmissions in the other direction only starts in odd-numbered time slots.

Two different link types are defined for a Bluetooth connection: Asynchronous Con- nection-Less (ACL) and Synchronous Connection-Oriented (SCO) links. They differ in the assignment of time slots to the slave devices, as well as in the type of data they are suited for.

ACL link type Within an ACL link, the master transmits data to one or all of the slaves within a piconet and assigns timeslots to the slaves for data transmission. Forward Error Correction (FEC), a dedicated mechanisms for error detection and error correction are offered, though the packet payload decreases when using these mechanisms, for the benefit of an error-free link. Only one ACL link may exist at a time between a master and each of its slaves. This link type is commonly used for transmission of pure data packets. It allows transmission of payload sized 17 to 339 bytes per packet; packet transmission may consume one, three or five timeslots. Table 4.1 gives an overview over the different ACL packet types.

Payload [bytes] Max. Rate [kb/s]

Type Header Data FEC CRC Symm. Asymm.

Forward

Asymm.

Reverse

DM1 1 0-17 2/3 yes 108.8 108.8 108.8

DH1 1 0-27 no yes 172.8 172.8 172.8

DM3 2 0-121 2/3 yes 258.1 387.2 54.4

DH3 2 0-183 no yes 390.4 585.6 86.4

DM5 2 0-224 2/3 yes 286.7 477.8 36.3

DH5 2 0-339 no yes 433.9 723.2 57.6

AUX1 1 0-29 no no 185.6 185.6 185.6

Table 4.1: ACL packet types

SCO link type This link type offers a constant data transmission rate by reserving fixed time slots for packet transmission from the master to one of its slaves; time slots for transmission in the other direction are assigned by the master to a slave on a per- packet basis. Up to three SCO links may exist between a master and a slave. This link type is commonly used for transmission of packets which contain voice data; SCO links are created on top of a previously created ACL link. Each packet transmission lasts exactly one timeslot, packets may contain a payload ranging from 10 to 30 bytes, depending on whether FEC is enabled for the link or not. All possible SCO packet types are compared in table 4.2 on the next page.

Several mechanisms are offered by the Bluetooth baseband to cope with transmission

(27)

4 Bluetooth Payload [bytes]

Type Header Data FEC CRC Symm. Max.

Rate [kb/s]

HV1 na 10 1/3 no 64.0

HV2 na 20 2/3 no 64.0

HV3 na 30 no no 64.0

DV 1 10+(0-9) 2/3 yes 64.0+57.6

Table 4.2: SCO packet types

Header-error-check (HEC), to ensure save transmission of the packet. Error detection for the payload is provided by a 16-bit Cyclic Redundancy Check (CRC), being present in all ACL packet types except AUX1. Furthermore, two different mechanisms exist for error correction: 1/3 FEC, where the payload is protected by repeating each bit three times, and 2/3 FEC, adding Hamming codes to the packets, allowing for correction of single errors and detection of double errors within each 15-bit codeword. If an error cannot be recovered using these methods, a packet has to be retransmitted. According to Krassi (2001), Bluetooth exhibits a raw Bit Error Rate (BER) of 10⁻³, that is, one bit in every 1000 bits is corrupted, and a Packet Error Rate (PER) of 9%; this makes clear why effective mechanisms coping with errors are necessary.

Each Bluetooth device is uniquely identified by its 48-bit Bluetooth Device Address (BD ADDR). The upper 24 bit of these addresses are assigned by the IEEE Registration Authority to the company which manufactures the device; the lower 24 bit are assigned by the company itself, uniquely to each device produced. Within a piconet, every active device gets assigned a 3-bit Active Member Address (AM ADDR) which gets added to the header of every data packet from or to the device. In contrast to this, the device name that is visible to the user may be set by an application programmer using the Host Controller Interface (HCI), which in turn sets the device name for transmission using the Link Manager Protocol (LMP).

Bluetooth offers four different types of security mechanisms at the link layer: a unique BD ADDR, which is known to all other devices; a private, 128 bit user key used for authentication; a private user key, sized 8 to 128 bit, used for encryption; and a random number generator, which might generate pseudo-random numbers in practice. Option- ally, a PIN code might be entered by a user, which is not only used to allow or disallow connections, but also for key initialization.

The Link Manager (LM) offers control and set-up mechanisms for the link layer. LMP messages are exchanged between Bluetooth devices to adjust connection parameters, such as PIN codes which might be required by a user for connection establishment, requests to change the master/slave roles within a piconet, or requests to set a device into special connection modes. If information from a higher Bluetooth layer is needed to proceed further, HCI events are triggered. LMP messages are also used to adjust Quality of Service (QoS) settings such as the master device’s poll interval Tpoll, that is,

(28)

the interval in which a slave device is queried by the master to transmit outstanding data.

4.4 HCI

The HCI provides the interface to the lower layers of the Bluetooth wireless technology.

It offers full control over the link manager, and gives access to information concerning the hardware status. HCI commands are sent from a Bluetooth host, i. e. the part of the Bluetooth stack that has to be implemented on a computer, to the Bluetooth host controller, i. e. the module that is plugged to a computer, over another physical link:

either a PC Card, USB, RS232, or UART. Besides those four, no other physical link types for controlling a Bluetooth host controller are specified in the Bluetooth standard.

Figure 4.3 gives an overview over the lower Bluetooth protocol layers. HCI commands and data packets are transmitted over a wired connection, e. g. UART or USB from the Bluetooth host to the host controller, which in turn determines the type of packet received; afterwards either the packet gets transferred to the Baseband Controller and transmitted over the wireless link, or the Link Manager (LM) configures the Baseband Controller.

HCI Driver

Link Manager Firmware HCI Firmware

Baseband Controller Logical link control and adaptation protocol

(USB, UART, . . . ) Physical Bus

Bluetooth Host Controller Bluetooth Host

Figure 4.3: Communication between the lower protocol layers

Besides transmission of data including payload to be sent over the wireless link, the host, e. g. a Bluetooth stack running on a PC, is able to send HCI commands to the host

(29)

4 Bluetooth

controller, i. e. the Bluetooth module; the host controller may in turn send events to the host.

4.4.1 HCI command packets

The available HCI commands offered by the host controller can be categorized as follows:

Link control commands These commands allow setting up the Link Manager (LM) and give full control over connection management to other Bluetooth devices, such as connection creation and disconnection for ACL as well as SCO connections, inquiry, PIN setup, reading remote device names, and setting of the packet types allowed for sending out packets (see table 4.1 on page 18 and table 4.2 on page 19).

Link policy commands This group of commands is used to change the policy rules of the Link Manager (LM), i. e. the link policy. Previously set up ACL links can be altered and special modes, such as the park mode, the hold mode where no data may be sent over the wireless link within a specified amount of time, or the sniff mode that is used to notify a slave device of only having to listen for incoming data on certain time slots, may be entered. Furthermore, the roles of which device forms the master and slave within a piconet can be changed.

Host controller and baseband commands The behavior of the host controller towards the host and towards remote devices may be altered using these commands.

The layout of an HCI command packet is shown in figure 4.4. The OpCode is composed by the OpCode Group Field (OGF), which has a size of 6 bits and specifies the category of commands defined above, and the OpCode Command Field (OCF), sized 10 bits and specifying the concrete command to be executed. It is followed by a 2 byte field describing the total length of the parameters, and by the command parameters.

Parameter N - 1

4 8 12 16 20 24 28 32

0

Parameter 0 OpCode

OCF OGF

Parameter Total Length

Parameter N

Figure 4.4: HCI command packet format

4.4.2 HCI Event Packets

HCI Event Packets, which are issued by the host controller, fulfill the purpose of notifying the host of incidents, such as completion of commands execution, incoming connections

(30)

and disconnections, errors, and changes in the link policy. These packets, shown in figure 4.5, begin with an event code specific to the type of event that happened, followed by the length of additional event parameters and the parameters themselves. The number of parameters depends on the event and on the foregoing HCI command.

4 8 12 16 20 24 28 32

0

Event Code Parameter Total

Length Event Parameter 0

Event Parameter N Parameter N - 1

Event

Figure 4.5: HCI event packet format

4.4.3 HCI ACL Data Packets

Payload which shall be transmitted over a previously established ACL link to remote Bluetooth devices is encapsulated within HCI ACL data packets. The host controller interprets these packets and substitutes the HCI ACL data header by a baseband header before the data is sent over the wireless link. The structure of the packets, sent from a host to a host controller, is illustrated in figure 4.6 begins with a 12 bit connection handle, which is unique for each ACL link between two Bluetooth devices, followed by the packet boundary (PB) flag signifying whether the packet is a fragment, and the broadcast (BC) flag, declaring the remote devices which shall receive the packet. The next fields contain the length of the payload and the payload itself.

4 8 12 16 20 24 28 32

0

Connection Handle

Flag PB

Flag

BC Data Total Length

Data

Figure 4.6: HCI ACL data packet format

HCI SCO data packets are not further explained since they are of no relevance for the implementation.

(31)

4 Bluetooth

4.5 L2CAP

The Bluetooth logical link control and adaptation protocol (L2CAP) is layered above the Baseband, encapsulated in HCI ACL Data Packets, and handles the segmentation of packets, as well as QoS setup in order to prioritize data originating on certain links; above all, it provides a multiplexed interface to the upper protocol layers, such as RFCOMM (see section 4.6 on the following page) and SDP (see section 4.7 on page 26). L2CAP packets may only be sent on top of HCI ACL data packets and are not defined for HCI SCO data packets, since data integrity has to be ensured.

Multiple L2CAP channels may exist between two Bluetooth devices, due to its multiplexing capability. Each upper layer protocol that is defined has a standardized Proto- col Service Multiplexor (PSM) value. All L2CAP channels are uniquely identified by a Channel ID (CID), which is dynamically assigned by the host for each open channel.

4.5.1 State machine

L2CAP is constituted as a state machine, interfacing with the lower and the upper layers.

Actions are performed from L2CAP to the interfacing layers, whilst events are received in the other direction.

The state machine is an integral part of L2CAP, used for channel establishment, parameter negotiation, and disconnection; furthermore, offering a transparent interface to the adjacent layers.

The state machine is exemplified on channel establishment for an incoming connection request. Before a channel is associated with the CID, the state machine is in the Closed state. Though a baseband connection may exist, this is no requirement. As soon as a connection request comes in from another host, it is forwarded to the upper layer, waiting for confirmation. If the upper layer accepts the connection, the state is changed to Config, allowing for exchange of L2CAP configuration parameters between the devices. As soon as both devices have exchanged configuration requests and responses, which might have to be repeated several times to adjust the parameters of the remote end, the state is changed to Open, and further data processing with the upper layers may proceed. As long as the channel is in the state Open, payload may be transmitted to the remote Bluetooth device.

4.5.2 Packet format

L2CAP packets can be categorized as follows:

L2CAP data packets These packets contain payload which is to be transmitted to or has been received from remote Bluetooth units. Two different kinds of data packets are defined: connection-oriented packets with only one recipient, and broadcast packets which have multiple recipients, i. e. a logical group that was previously set up by a higher layer protocol; these packets are referred to as connection-less packets. Illustrations of those two packet formats are shown in figure 4.7 on the following page and figure 4.8 on

(32)

the next page. Connection-oriented packets have a 4 byte header containing the packet length and the CID assigned during the connection setup, whilst connection-less packets have a header of 6 bytes in length with a fixed CID and additionally containing the PSM value signifying the service on the remote end.

8

Length Channel ID

Payload

16 24 32

Figure 4.7: Packet format for connection-oriented channels

8 16 24 32

Channel ID (0x0002)

Payload

Payload (cont.) PSM

Length

Figure 4.8: Packet format for connection-less channels

L2CAP signal packets Signal packets are used to notify a remote device of new connections, as well as to negotiate channel parameters, e. g. the Maximum Transmission Unit (MTU) or QoS parameters. The format of such packets, shown in figure 4.9 on the following page, contains a length field, a fixed CID, followed by one or more commands containing a command code, e. g. for a connection request, an identifier that is increased on each request and sent back unchanged in responses to help associating a signal response with a foregoing request. Furthermore, it contains the length of the command parameters in bytes and the command parameters themselves.

4.6 RFCOMM

RFCOMM provides a multiplexed interface for serial port emulation over the Bluetooth wireless link. It is based on ETSI (1997), the serial emulation used in TS 07.10, with some adaptations for the Bluetooth system. Only one RFCOMM channel may exist per Bluetooth link; multiplexing for up to 64 serial ports is implemented by the RFCOMM protocol.

Figure 4.10 on the next page visualizes the two different kinds of RFCOMM device

(33)

4 Bluetooth

8 16 24 32

Channel ID (0x0002)

Payload

Payload (cont.) PSM

Length

Figure 4.9: Signal packet format

ers and printers; thus, endpoints of a connection. Type-2 devices, in contrast, have a wired (serial) connection to the connection endpoint, e. g. to a modem or a mouse. No difference between these device types is made within the RFCOMM protocol.

Device with Bluetooth

(Type-1)

Device with Bluetooth

(Type-2)

Bluetooth Wire

Device without Bluetooth with serial port

Figure 4.10: RFCOMM device types

RFCOMM provides the serial link with flow control mechanisms. Besides Modem Status Command (MSC) packets which may be exchanged between two devices to specify the control signals known from RS232, such as Ready To Communicate (RTC) and Ready To Receive (RTR), a scheme for Credit Based Flow Control (CBFC) is offered. This scheme allows a host to specify how many packets it is able to receive before the local buffers are full. Each packet containing payload decreases a CBFC counter by one, whilst it may contain an extra field specifying how many more packets the remote side is allowed to send.

Each RFCOMM channel is uniquely identified by a Data Link Connection Identifier (DLCI), which gets assigned to the channel by the host initiating it. A connection is initialized by sending a Set Asynchronous Balanced Mode (SABM) frame with the general DLCI 0, replied by an Unnumbered Acknowledgement (UA) frame, also with DLCI 0 (cf. figure 4.11 on the following page). Channel establishment for each channel that is to be opened then works quite similar: a SABM frame is sent containing a newly assigned DLCI, answered with an UA frame with the same DLCI. In the next step, Data Link Connection (DLC) Parameter Negotiation (PN) is done in both directions;

this includes exchanging the mutual Maximum Frame Size (MFS), and initial credits for CBFC, besides other information. After this, MSC packets are exchanged to set initial values containing the RS232 control signals.

RFCOMM packets are structured the following way. Each packet begins with an address field containing the DLCI and a flag indicating whether the packet is sent from the initiator of the connection, i. e. the host that sent the SABM frame on DLCI 0, to

(34)

RFCOMM entity A RFCOMM entity A

PN

MSC MSC

SABM on DLCI 0

SABM on DLCI 2 UA on DLCI 0

UA on DLCI 2

PN

Figure 4.11: RFCOMM connection- and channel establishment. Entity A connects to entity B and establishes a channel with DLCI 2 for data interchange.

the remote end or vice versa. The following field is the frame type, followed by a length indicator, sized either 1 or 2 bytes. If CBFC is enabled for the channel, a field containing an additive number of new credits may follow. The next fields are filled with the payload to be sent over the link. The last field of an RFCOMM frame is the Frame Checking Sequence (FCS), a checksum which is calculated over the packet header. Though the FCS is not really needed on Bluetooth links with FEC enabled, since that mechanism provides an error-free link, it is added to the packet in all cases. An exemplary RFCOMM packet is shown in figure 4.12.

Address Control

Credits

FCS

8 16 24 32

Length

Data

Data (cont.)

Figure 4.12: Exemplary RFCOMM packet structure. The length field may span 1 or 2 bytes, the credit field is optional.

4.7 SDP

The Service Discovery Protocol (SDP) applications the possibility to discover which

(35)

4 Bluetooth

of those services. Service classes are defined to differentiate between services, such as printers, or modems, as well as the mechanisms to access them. Service Discovery Pro- tocol (SDP) is based on a request/response model to keep the number of transmissions low. Services may be arranged hierarchically, to cope with huge numbers of different services that may be offered by devices.

(36)

This chapter sums up the implementation of the Bluetooth stack, which constituted one of the integral and most time-consuming parts of this project. All parts of the Bluetooth protocol stack which were implemented are described within the following chapter, as well as some additional programs which run on the Khepera robot.

The following part describes some of the main constraints that had to be considered throughout the whole implementation.

Memory limitations Since the MCU which is used on the KBU only offers a very limited amount of memory, no dynamic memory allocation could be used. All variables had to be defined either in a global or in a local context, i. e. statically below the heap or dynamically on the stack.

Clean programming/debugging Due to the fact that the KBU only offers three LEDs for direct output, and the debugging interface pins of the MCU are not connected to the circuit board, debugging the implementation showed to be a challenge. There- fore, special care for code cleanliness had to be taken, manifested in meaningful comments and a clean and readable coding style.

Flow control Since flow control between the MCU and the Khepera robot, as well as between the MCU and the Bluetooth chip was not available due to missing connections, buffers large enough for handling of huge packets had to be declared in the low amount of memory that is offered by the MCU.

Two Bluetooth stacks were implemented throughout this project: a minimal one consisting of a bootloader for easy software updates, further described in section 5.1, and a fully standards compliant one, described in more detail in section 5.2 on the next page.

Since the source code was well documented throughout the implementation phase, using the doxygen syntax¹, no code fragments are included here. The source files are named according to the implemented protocol layer, which makes it easy to find the relevant parts in case of changes and additions.

5.1 Bootloader

During the first programming stages, it came clear that updating the MCUs flash memory always takes a long time, since DIP switches mounted on the KBU have to be set in different ways for programming and for testing. Furthermore, these switches suffered

(37)

5 Implementation

from being physically switched too often, and their replacement would have been necessary after a short amount of time. Therefore, the decision was taken to program a bootloader, residing in the upmost part of the MCUs flash memory, which is never to be replaced during normal flash updates.

The main bootloader code consists of a minimal Bluetooth stack, being able to receive compiled code in Intel’s hex-format, and code to program and verify the update of flash pages. One constraint while programming was a small code size, since the amount of flash memory available for the bootloader was very low. Therefore the implementation is not standard conform in all cases. For the same reason, it was impossible to use interrupts for receiving and sending packets; the buffers constantly had to get polled instead. The bootloader operates in the following steps:

1. Check whether the 8th DIP switch on the top side of the KBU is set. If not, continue loading the regular code.

2. Initialize the Bluetooth host controller.

3. Wait for an incoming connection. If a connection is detected, set up L2CAP link properly, i. e. negotiate parameters.

4. Wait for incoming data on the L2CAP channel; if the data packet is not prefixed by a magic number, or if an end of file record is detected, quit the bootloader and do regular boot-up process.

5. Write the data into the corresponding flash ROM page and verify whether it has been written properly. If not, go into an endless loop with blinking LEDs.

6. Send the characters OK over the L2CAP channel, continue with step 4.

If the flash process was successful, the new software gets directly executed.

5.2 Implementation of the Bluetooth stack

The buffers for incoming data from both the Khepera robot and the Bluetooth host controller were declared as ringbuffers to ensure that packets incoming at any time can be stored. Due to the fact that no flow control could be used from the KBU towards the robot and the host controller, they have to be very huge, and thus take up half of the MCUs internal memory.

The main function of the implementation consists of calling initialization routines of the different Bluetooth layers, and an endless loop permanently checking whether unprocessed packets are residing in the buffers. If no packets are to be handled, the MCU goes into standby mode until an interrupt occurs.

What follows is a summary of the layers of the Bluetooth stack that were implemented within this project.

(38)

5.2.1 USART

Basic interrupt handling routines, initial setup of the serial Universal Synchronous/Asyn- chronous Receiver/Transmitter (USART) connections, such as baudrate settings, the number of data and stop bits, and parity setting are implemented on this layer. The interface offered from this layer to the upper layers consists of functions for sending out a number of bytes which reside in the ringbuffers to either the Khepera robot or the Bluetooth host controller. If an interrupt occurs, the incoming byte is checked for validity if possible, and written into the corresponding ringbuffer. When a full packet has been received from the host controller, and it is classified as an HCI event packet, the HCI layer is directly called from within the interrupt routine to handle that event. If a data packet has been received, a counter for the number of unprocessed data packets in the ringbuffer gets increased.

On incoming packets from the Khepera robot, a fixed number of bytes gets reserved in the ringbuffer for writing back the Bluetooth headers during further packet processing.

If a full data packet has been received, i. e. a carriage return and a line feed have been detected, a counter for the number of unprocessed packets residing inside the ringbuffer gets increased.

5.2.2 HCI

The HCI layer consists of code handling HCI events, as well as HCI ACL data packets.

Furthermore, functions for initialization of the host controller are included.

After resetting or powering up the KBU, the folling HCI commands are sent from the Bluetooth host to the host controller:

Depending on the packet type detected on the USART layer, i. e. event-, or data- packet, the corresponding function on the HCI layer is called. Event handlers are called from within the interrupt routine, to ensure that events get directly processed, without any latency. Due to the fact that transmissions from the host controller can occur at any time, the event handler functions have to be very efficient.

When HCI commands have to be executed, the implementation waits until the transmission of a packet to the host controller is completed. Afterwards, interrupts from the Khepera become disabled, and the command is transferred. Normal processing of data continues as soon as a certain HCI event has been received, i. e. a Command Complete event in reaction to the change of the local device name.

Incoming ACL data packets get processed by looking up the internal connection record, identified by the matching connection handle. It becomes then forwarded to the upper layer, i. e. L2CAP. Outgoing ACL data packets, in contrast, get the ACL header added;

afterwards, the USART layer is called to transmit the packet to the host controller.

5.2.3 L2CAP

As mentioned in section 4.5.1 on page 23, the L2CAP connection- and disconnection process, as well as the parameter negotiation, is constitued as a state machine. For

Bluetooth Khepera robot control and communication

Bluetooth Khepera robot control and communication

Master’s Dissertation

Bluetooth Khepera robot control and communication

Patrick Duchstein 10th November 2004

supervised by Nicklas Bergfeldt

I would like to thank my supervisor Nicklas Bergfeldt for his supportive work and his very motivating comments. I would also

like to thank Jens Auer for many constructive ideas and discussions, and my family for giving me mental and financial

support during my stay in Sweden.

Contents

List of Figures

1 Introduction

1.1 Motivation

1.2 Aims and Objectives

1.3 Thesis outline

2.1 Khepera robots

2.2 Bluetooth on Khepera robots

2.3 YAKS

2.4 Related Work

3 Method

3.1 Study and understand the bluetooth specification

3.2 Reimplement the Bluetooth communication unit

3.3 Performance evaluation

4 Bluetooth

4.1 The Bluetooth layered architecture

4.2 Radio

4.3 Baseband – Link Controller and Link Manager

4.4 HCI

4.5 L2CAP

4.6 RFCOMM

4.7 SDP

5.1 Bootloader

5.2 Implementation of the Bluetooth stack