CSC560 Project 5 Report

Henry Lien, Hong-Yi Wang

August 14, 2009
Table of Contents

Chapter 1: Introduction 1

1.1 Major Challenges and Changes 2

1.2 Simplified Problem 4

Chapter 2: Overall Design 5

Chapter 3: Modified Sonar Module 7

Chapter 4: Beacon Station Subsystem Design and Implementation 11

4.1 Beacon Station Block Diagram 12

4.2 Beacon Station Schematic 13

4.2.1 Power supply and related issues 13

4.2.2 Schematic 14

4.2.3 Power ground and logic ground 15

4.3 Beacon Station Software Modules 16

4.3.1 Overview 16

4.4 Beacon Station Behaviours and Implementation 19

Chapter 5: Explorer Roomba Subsystem Design and Implementation 20

5.1 Explorer Roomba Subsystem Block Diagram 21

5.2 Explorer Roomba Subsystem Schematic 22

i
 5.3 Explorer Roomba Subsystem Software Modules 23

5.3.1 Overview 23

5.3.2 nRF24L01 driver 24

5.3.3 SRF04 driver 24

5.3.4 Roomba SCI API 24

5.3.5 RTOS tasks 25

5.3.6 Packet format 25

5.4 Explorer Roomba Subsystem Behaviours and Implementation 26

5.4.1 Approaching 27

5.4.2 SOS, Waiting-for-Rescue, and Comfirm Rescue behaviour 29

Chapter 6: Rescuer Roomba Subsystem Design and Implementation 30

6.1 Rescuer Roomba Subsystem Block Diagram 31

6.2 Rescuer Roomba Subsystem Schematic 32

6.3 Rescuer Roomba Subsystem Software Modules 33

6.3.1 Overview 33

6.3.2 nRF24L01 driver 33

6.3.3 SRF04 driver 33

6.3.4 Roomba SCI API 33

6.3.5 RTOS tasks 33

6.3.6 Packet format 34

6.4 Rescuer Roomba Subsystem Behaviours and Implementation 34

6.4.1 Stand-By 35

ii
 6.4.2 Rescue 35

6.4.3 Confirm Rescue 35

Chapter 7: Final Result and Futurework 36

iii
Chapter 1: Introduction
This project is to implement a system utilizing multiple Roomba robots and base stations similar to the ones in Project 1
to solve a problem. We have proposed a problem and a design in the previous report. However there are many aspect of
the design that require investigation. In order to implement a solution in the future, we simplified the problem, redesigned
the system, and implemented a system as a proof of concept. The major goals of this project are:

1. Reassess the issues of the original design

2. Simplify the problem such that the solution provides sufficient ground work
for the original problem.

3. Redesign the system to solve the simplified problem.

4. Implement the system.

This report will re-define our problem and sketch a simpler design that utilizes multiple Roombas and multiple base
stations which we will call “beacon stations” in the following chapters of this report. The Roombas are designated as the
explorer and the rescuer. Initially, the explorer roams in a pre-specified area. In our design, we assume there is no
obstacle in the area. Whenever the explorer Roomba detects a human, it sends its location information to the rescuer
Roomba. The rescuer Roomba then uses the location information as a guide and approaches the explorer Roomba.

In the later sections of this chapter, the simplified problem is presented and we will discuss the major challenges of our
previous design and major changes made.

The remainder of this report is organized as follows:

• Chapter 2 Overall Design

• Chapter 3 Modified Sonar module

• Chapter 4 Beacon Station Design and Implementation

• Chapter 5 Explorer Roomba Subsystem Design and Implementation

• Chapter 6 Rescuer Roomba Subsystem Design and Implementation

• Chapter 7 Conclusion and Future work

In the following section, the challenges of the original problem and design will be presented.

1
1.1 Major Challenges and Changes
There are unsolved issues and challenges from both hardware and software in the original design. We will list these and
challenges and changes made. A brief discussion is given after each of them.

Power supply

Power supply is a critical aspect of our design. From data sheets of the hardware modules, we know that the sonar
requires +5 Volt. Both a sonar listener (ultrasound wave transducer removed) and a sonar emitter (echo ignored in
software) require +5 Volt in order to function properly. However, each unit of our system that consists of AT90USB,
SRF04 (sonar range finder), and radio module, either draws power from a +9V battery or draws +16 Volt from the
Roomba SCI interface. A new schematic and electrical parts are needed to accommodate the requirements of the sonar
module.

In addition, a lot of current is required when the sonar module charges and fires sonic waves. This behaviour may cause
the microprocessor to reset f they are sharing the power source. We redesigned the schematics in order to provide clean
power source for beacon stations that run on batteries. In a nutshell, we give sonar an additional battery to avoid the
situation.

The problem of signal ground and power ground is also taken into account. We will discuss this problem in further detail
in Chapter 2.

These challenges require a delicate design for the hardware of our units. From experiments, we have found a optimal
schematic that provides a consistent set of hardware modules and clean power source which we will present in Chapter
4, 5, and 6.

Roaming

Obstacles and inconsistency of Roomba’s intended movement and actual movement are the major issues for this aspect
of the project. We assume there will be no obstacle in the Roomba’s roaming area and therefore the software and
hardware for obstacle avoidance can be weaved from the design to simplify the implementation.

Moreover, moving toward a direction and rotating in the same place require precision control. For example, the Roomba
is given the command to move forward at speed of 100 mm/s for 10 seconds. The Roomba is supposed to move 1000
mm after 10 seconds, however, the physical interference may cause it move less or more then the desired distance. This
situation occurs for rotating as well.

Such error and inconsistency may propagate over time and causes the Roomba far away from the desired destination.
Thus, Proportional Integral Differential (PID) feedback control is needed. The PID control will be discussed in Chapter 4
and 5.

Distance calculation

The usage of the sonar module (SRF04) is quite different in our design. Instead of measuring the pulse width between
sonar trigger and echo pulse, the distance between a Roomba and a beacon is not calculated based on trigger-echo
pulse width. As a result, a different distance calculation formula is used in the implementation.

2
Furthermore, readings of the pulse width tend to fluctuate only slightly from our experiment. This indicates that
normalization of the readings and rejection of the outliers may not be required in our implementation.

From our experiments, we have discovered the distance calculated differs from the actual distance by roughly 3 cm, of
which the precision is acceptable.

Beacon station coverage

The sonar module only provides a certain coverage for the distance calculation to work. This is illustrated in the following
Figure (Figure. 1).

!"#$%
&'(&

!"#$% !"#$%
&'(& &'(&

!"#$%
&)*+(&,*-&..('
a. Beam Pattern &'(&

!)*/01('&2(
Figure. 1: Sonar Beam Pattern and Blind Areas

The sonar module emits ultrasonic bursts which cover a cone-like space for up to 10 feet (3 meters). Blind areas exist
and will be a major difficulty for localization. By chaining multiple SRF04s or connecting multiple transducers to one
module can increase the coverage of the beacon stations. However, this requires even more investigation and
experiments. Therefore, we have decided to simplify our problem by making the Roomba move along a “path” consists
of multiple beacons (shown in Figure. 2) instead of triangulating the Roomba in an “area”. By taking the path approach,
the implementation only needs to address the calculation of the distance between Roomba and a beacon, and the
orientation of the Roomba. With this design, its implementation can serve as a proof of concept and thus provides
ground work in designing and realizing the solution to the localization problem we’ve proposed in the previous project.

Figure. 2: Path formed by Beacon Stations

3
Due to these challenges and changes, we will propose and define the simplified problem and design. The simplified
problem will be presented in detail in the next section. The design will be presented and discussed in Chapter 2.

1.2 Simplified Problem

According to the challenges and issues describe in the previous section, we simplified our problem. Instead of roaming in
a pre-defined area and use multiple beacons to triangulate the Roomba, we use beacon stations to form a path as
illustrated in Figure. 2.

Two Roombas are designated as explorer and rescuer. Initially, the explorer Roomba will follow the path formed by
beacon stations. While moving along the path, the explorer detects human. If human is detected, the explorer Roomba
will stop moving and inform the rescuer Roomba its location related to the according beacon in the path. The rescuer
Roomba then moves towards the explorer Roomba following the path.

In this problem, sufficient coverage of beacon stations for triangulation and blind area are no longer an issue since the
Roombas only follow one beacon station at a time. Only one distance from the Roomba to the corresponding beacon
station is required. Furthermore, roaming in a pre-defined are is simplified to following the path. Potential issues from PID
control that can propagate and cause the Roomba to move out of the pre-defined area is translated to the question of
how precise the Roomba can move across a beacon station without running into it.

However, many challenges described in the previous section such as power supply and distance calculation remain
crucial for our project. We will discuss further on how we tackle these problems in the design and implementation in the
later chapters.

We will first present the overall system design in the following chapter.

4
Chapter 2: Overall Design
According to the simplified problem, a slightly different design is proposed.

The overall system design is illustrated in the following block diagram (Figure. 3).

Beacon station

5. Radio
Message

6. Ultrasonic
Waves

2. Ultrasonic 1. Radio
Waves message

Roomba 4. Radio Roomba

Explorer Message Rescuer

3. Human
detected

Figure. 3: Overall System Block Diagram

As shown in the figure, where the number denotes the sequence of the messages, the Roomba repeatedly perform
operation 1 to 3 as it approaches one beacon station at a time. If human is detected, the behaviour of performing
operations 4 to 6 will occur. While the Roomba is moving toward a beacon station, the orientation of the Roomba may
not be exactly aligned to the beacon’s location. Therefore, the Roomba will rotate to align itself to roughly move towards
the beacon station. The Roomba movement is shown in Figure. 4.

Beacon Station

Roomba

Figure. 4: Roomba Movement

5
This also suggest that the Roomba should not move too far between each distance acquisition that is used to adjust its
direction as well as the total distance it will move to reach the beacon. This is to avoid the possibility of the situation
shown in Figure 5. where Roomba moves out of the coverage of the sonar beam.

Beacon Station

Roomba

Roomba

Figure. 5: Roomba in blind area

We could, however, make the Roomba moves randomly or back track the movement to regain the coverage. But more
updates of the distance is more feasible and require less implementation effort.

In addition, the sonar module modifications proposed in the previous project is proven to be working properly after some
experiments. We will discuss the modification and the experiment result in the following chapter as the sonar modification
is the key factor that determines whether or not our project is feasible.

6
Chapter 3: Modified Sonar Module
As mentioned in the previous project report, the usage of the sonar module (SRF04) is different from its usual usage as
we are not measuring the distance to objects but measure the distance to a specific instance of the beacon stations.

In order to do so, the radio module is used to trigger the sonar module. Moreover, the sonar module must align to the
beacon station as shown in Figure. 6.

Figure. 6: Sonar Alignment

In our approach, the sub system on the Roomba will request a beacon station to trigger the sonar and listen for it. Hence
the Roomba will be a passive listener for the ultrasonic waves.

The distance is calculated based on the pulse width between the accomplish of sonic bursts and the receive of the
echoes as suggests in Figure. 7, the timing diagram for the SRF04.

Figure. 7: SRF04 Timing Diagram

7
However, triggering and listening operations are tied together on SRF04. In other words, we have to trigger the sonar in
order to switch SRF04 into listening mode. The ultrasonic wave emitted from the Roomba will interfere the ultrasonic
waves from the beacon stations thus giving us incorrect results.

The only way to work around this problem is to desolder the transducer on SRF04 as shown in Figure 8. The SRF04 on
the right is the original, and the one on the left is the one that will only listen for ultrasonic waves and will be placed on
Roomba. The distance calculation is changed to measure the distance by one-way time of flight times speed of sound
instead of echoes.

Figure. 8: Original SRF04 and Modified SRF04

Another issue here is the timing of the triggering which is shown in the Figure. 9. The radio tx function in our driver will not
return until an auto-ack is received. Similar for the radio receiving, we trigger the sonar as soon as an interrupt fires upon
the receiving of a packet. As a result, both end can call sonar_trigger function from which the Roomba goes into listening
mode and the beacon emits ultrasonic waves after returning from tx/rx function of the radio driver. Slight delays is
introduced from the auto-ack mechanism. However, such delay is just enough for the Roomba end to get into listening
mode (10 us + 200 us from 8 cycle sonic bursts). If the physical distance prolongs the auto-ack delay, we simply ignore it
since the radio travels at speed of light and the result is affected significantly.

Roomba Beacon

radio tx request sonar trigger

radio ISR
radio auto-ack
sonar_trigger()
sonar_trigger() ultrasonic bursts

Figure. 9: MSC for distance calculation

8
In our experiment, the time unit is the clock cycle from input capture timer and the timer is running on 1MHz frequency. A
formula is then applied by hand for the distance value. The results in clock cycles are shown in Figure. 10.

3.5 m

Figure. 10: Measurement results

9
The top row picture in Figure. 10 is the distance calculation result printed to terminal. The messages showed that the
distance values were roughly around 10 cm, 50 cm, and 100 cm. The middle row of the Figure. 10 shows the actual
positions of the beacon station and roomba subsystem when the results were generated. We have discovered that the
distance measurements are accurate up to about 3.5 meters.

Based on the results, we considered that the readings are fairly accurate thus the project is feasible.

It is also worth mentioning that the MIT cricket system (http://cricket.csail.mit.edu/) has proved the possibility of this
approach. However, to build a complete indoor localization system is not in the scope of this project. The contribution of
this project is to provide ground work and research background for building such systems.

Power supply is another critical issue when interfacing with the sonar module. We will present our design and schematics
in later chapters, in which this issue is addressed.

In the next chapter, we will start with presenting our high level design, schematics, and software design for beacon
stations.

10
Chapter 4: Beacon Station Subsystem Design and Implementation
The design and implementation that will show our approach to tackle the given problem is presented in this chapter.
Issues such as power supply, and the robustness and the easiness of hardware assembling will be discussed as creating
multiple instances of beacon stations is of our major concern in this project.

As a proof of concept, we will need at least two beacon stations. However, we will have three beacon station in order to
refine project and weight the scalability of our design. Obviously, the Roomba will need to maneuver to avoid bumping
into the beacon stations in order to move into another beacon station’s coverage. An alternative would be to place the
beacon stations high above the path of Roombas thus the vertical angle of the sonar modules on both Roomba and
beacon stations need to be adjust respectively. We will not discuss further about the alternative, and the maneuver
behaviour of the Roombas will be addressed in Chapter 5 and 6.

In this Chapter, the presentation of the design and the implementation approach of the beacon station are broken down
into the following parts:

1. Block Diagram

2. Schematic

3. Software Modules

4. Behavoiur State Diagrams

These information will provide a general idea to the readers on specifications and components of the beacon stations.
But our implementation is only one way to implement the design.

The power supply issue is most critical for beacon stations as it does not have a clean DC power source from the
Roombas. The issue about power ground and signal ground is also a concern as we ran into this problem during
experiment. Discussion of these issues will help the readers to reproduce our project result.

In addition, accommodation for the SRF04’s require voltage also plays an important role when implementing the beacon
station. This will be discussed in this chapter as well.

Lastly, an working RTOS with preemptive priority scheduling (discussed in previous projects) is provided and will be used
for the project thus we will discuss how the behaviours of the beacon station are implemented as an RTOS application.

11
4.1 Beacon Station Block Diagram
The Beacon station subsystem has the following major hardware components:

• AT90USB1287 microcontroller

• SRF04 Ultrasonic Range Finder

• nRF24L01 2.4GHz transceiver

• FT232R USB-UART (optional)

Note that the electrical components for addressing power supply issues are discussed in the schematic section. The
logical linkage and messages between each components are the focus in this section. In addition, the USB-UART
interface (FT232R) is an option for the subsystem for debugging purpose.

Below is the block diagram of the beacon station subsystem (Figure. 11).

nRF24L01

PC

SPI
USB

FT232R AT90USB1287 pin signal SRF04

UART

Figure. 11: Beacon Station Block Diagram

AT90USB1287 microcontroller communicates to the radio chip using SPI interface, and to UART-USB via UART
interface. The FT232R can be used to output debugging messages to PC. Since these are optional and for debugging
purpose, the linkages between AT90USB1287, FT232R, and PC are dash lines.

Interfacing with SRF04 is special in this case. Normally, the SRF04 communication is two way meaning that the
microcontroller can trigger the sonar and detects pin changes (falling edge, we will talk about this in chapter 5) on the
echo line from SRF04. However, the beacon stations are in charge of emitting ultrasonic bursts only and ignore the sonic
echo signals from the physical world thus it is just an one-way communication between SRF04 and the AT90USB1287.

Increasing the coverage of the beacon stations is a possible optimization for the system. Since the beacon stations only
emits the ultrasonic bursts, it is possible to chain multiple SRF04 facing different angles to increase the coverage.
However, this optimization may introduce power supply issues. Hence this possible enhancement will not be
implemented in this project.

The software drivers for the hardware interfaces are discussed in more details in later sections.

12
4.2 Beacon Station Schematic
The following additional electronic components are required to build the beacon station hardware system.

• 10 uF capacitor

• 0.1 uF capacitor

• 7805C 5V regulator

• 7404 Hex Inverter

• Two +9V batteries

4.2.1 Power supply and related issues

The SRF04 sonar module requires a +5V power source. AT90USB1287 provides 3.3V which is not enough to power
SRF04, which also makes the output pins to produce a 3.3V logical 1.

In our experiments, we discovered that the SRF04 can actually be powered and measure the distance to objects without
+5V. However, the range is not optimal. Therefore, a +5V is needed which introduces even more issues. Without the
optimal sonar range, our system may not work smoothly. As a result, we decided to provide +5V power source to the
subsystem.

If +5V is used but the AT90USB1287 output pins only produce a 3.3V signal, the SRF04 may not recognize the 3.3V
signal as a logical 1 thus the output pin signals needs to be processed before asserted into the SRF04. This is illustrated
in Figure. 11.

Desired
Voltage

logical 1 for SRF04

+5V

+3V

0
time

Figure. 12: Desired voltage for logical 1 for SRF04

A Hex inverter is used here for buffering the 3.3V signal from AT90USB and outputs a 5V signal to SRF04 for sonar
triggering.

Sharing the same power source between the microcontroller and SRF04 can create problem as well. As the sonar
charges and fires ultrasonic bursts, it draws a lot of current which may cause the microcontroller to reset. This is called
“brown-out”. To avoid this situation, which may introduce difficulties during implementation and debugging, two separate

13
power sources are included. Using separate power sources introduces grounding problem, of which a dedicated section
will discuss this issue.

4.2.2 Schematic
The following is the schematic of the beacon station subsystem (Figure. 13).

10uF
capacitor
+9V 5V
Battery
regulator

0.1uF
power
capacitor
and signal
ground

SRF04
nRF24L01 AT90USB +5V

GND GND vcc

IRQ PE7
echo
MISO PB3 (don't care)
MOSI PB2 vcc

SCK PB1 PC6 NOT NOT trigger

CSN PE6
CE PB4
7404 GND
Hex Inverter
VCC VCC (+3.3V)
+ +9V
- Battery

Figure. 13: Beacon Station Schematic

The capacitors are used to smooth out the current, and a standard +5V regulator (Input, Ground, Output) is used to
regulate +9V input from battery down to +5V for the SRF04 and the hex inverter. The nRF24L01, however, draws power
from AT90USB1287 as it requires less voltage (see nRF24L01 data sheet).

The trigger signal from AT90 goes into the hex inverter and double-negated. After this buffering, the signal remains 1 but
is a +5V logical 1 which in terms will recognized by the SRF04.

During our experiment, we found out that the power ground and signal ground need to be connected together or the
circuitry will not function properly. Therefore, the ground connection is denoted as the thinker black line in the schematic.

The issue of power ground and signal ground will be discuss briefly in the next section.

14
4.2.3 Power ground and logic ground
Grounding in control system is complex and can be a science on its own. We will not cover all the theories behind this
but provide a general idea when wiring the hardware components in the similar systems.

Signal grounding provides a reference for a data signal. Every signal, whether power or data or voice must be referenced
to something. It must have a point that the signal can return to. A signal ground, the starting point, is usually a wire that
connects the logic ground in the components. It eventually connects to the power ground of the components. This is
called single-point grounding.

The ground network is an organized system of ground wiring that terminates in a single, dedicated point to the
components. With single-point grounding, a clean reference for the control signal in the control system can be achieved.

In our case, the design of such grounding system is much simpler. We simply connect the 5V ground to the
AT90USB1287, thus the trigger signal is referenced to the 5V ground and can produce logical 1 for the SRF04. This is
illustrated in Figure. 14.

3.3V GND

5V GND
3.3V GND

Figure. 14: Connecting power ground and signal ground.

During our experiments, we discovered that the sonar will not fire if this connection between signal ground and power
ground is removed. From this experience, we have learned that when debugging the control system if the wiring are
correct and the system is still not working, check the ground wires.

15
4.3 Beacon Station Software Modules

4.3.1 Overview
The major software modules of the beacon station subsystem include:

• nRF24L01 driver

• SRF04 driver

• Priority preemptive based scheduling RTOS

• Packet format for radio commands

We will provide a brief discussion on how each of them is implemented and its highlights for this subsystem in particular.

nRF24L01 Driver

This particular 2.4GHz radio chip has the advantages of low power consumption, reliable packet handling, and uses fast
and robust SPI which is easy to implemented for interfacing with the microcontroller. These advantages would greatly
reduce the implementation effort and increases the robustness of our system. Its driver was implemented by following
the state diagram provided in the product specification (page 20).

The driver also consist of an SPI driver, which the radio driver will use to communicate with the chip. The radio driver
provides the following API:

• void radio_init(RADIO_CONFIG* config)

• uint8_t radio_transmit(radio_t* packet)

• uint8_t radio_receive(radiopacket_t* packet)

• void radio_set_tx_addr(uint8_t* addr)

These functions would provide sufficient functionalities that a beacon station requires. However, we’ve discovered a
particular flaw in our driver implementation that is the radio chip is not left in the receiving mode after initialization. This is
especially important for the beacon station since it is essentially an server listening for the requests from Roomba
subsystems and make responses using ultrasonic bursts. This is illustrated in Figure. 15.

Request/Radio

roomba Beacon
subsystem Station

Response/8 cycles of ultrasonic bursts

Figure. 15: Beacon Station as an server.

16
The modifications for this issue is being done as this report is being written. For our experiments, we have made the
beacon station sending a dummy packet before listening every time.

SRF04 Driver

This particular component was chosen since its receiver and transducer are physically separated parts as described in
Chapter 3. Implementation of this driver, particularly for the beacon stations, is fairly straight forward as the beacon
stations will only emit ultrasonic bursts.

According to the timing diagram of SRF04, the trigger signal need to be raised for at least 10 us so the SRF04 will fire 8
cycles of sonic bursts. An additional 10 ms is required between sonar firings so its internal state can be readied up for
the next firing.

Of particular, the distance measuring of the SRF04 which the driver should implement will be discussed in further detail in
Chapter 5 since the Roomba subsystems will listen for sonic bursts to measure its distance to a specific beacon station.

RTOS

The provided RTOS has three task priority levels available and they are SYSTEM, PERIODIC, and BRR. Their
characteristics are discussed in detail in the previous projects. So we will not iterate through them here.

There will be three tasks that are coordinated using EVENTS:

• Initialization task (SYSTEM)

• Radio receive task (PERIODIC)

• Sonar triggering task (SYSTEM)

The sonar triggering task will be created and waiting on an EVENT signaled by the radio receive task. The radio receive
task, in terms, processes the received packet and decide whether or not the sonar triggering task should be signaled.

The following Gantt chart(Figure.16) and MSC (Figure. 17) illustrates a typical scenario where these three tasks interact to
each other upon receiving of a request from the Roomba subsystem.

Note that an implementation alternative is to signal the EVENT in the radio interrupt handler, and let the sonar_trigger task
to process the packet and decide whether or not to fire the sonar. This would optimize the strict timing requirement for
the distance measurements.

If the alternative is to be implemented for optimization purpose, the radio receive task is no longer needed.

17
 Priority

SYSTEM Initialization sonar_trigger

Event_Signal()

radio_re
PERIODIC
ceive

BRR

Time
(Ticks)

Figure. 16: Gantt Chart for Beacon Station tasks.

Radio RX Task Sonar Trigger Task

Event_Wait(s)

Process_packet()

Event_Signal(s)

sonar_trigger()

Figure. 17: MSC for interactions between Radio task and Sonar task.

18
Radio Message Packet Format

The beacon station will take “sonar trigger” requests from Roomba subsystems. Each beacon station and Roomba
subsystem should have an unique identifier. In addition, it is assumed that the radio modules on all presented
subsystems are assigned a unique link layer address (5 bytes long, see nRF24L01 data sheet).

Below is the packet format (Figure. 18) that will be used by beacon stations, and Roomba subsystems. The Sender and
Receiver fields are one byte unique identifier assigned to each subsystem offline.

Sender Receiver
Type (uint8_t) Command (uint8_t)
(uint8_t) (uint8_t)

Figure. 18: Packet format

There are currently one message Type which is COMMAND. There are two kinds of Command, and they are REQUEST,
ACK. The absence of REPLY is because the actual reply is done in ultrasonic bursts.

The beacon stations will receive packets from Roomba subsystem, process them, and act according to the data value in
the fields. We will present the hand-shake in next Chapter.

4.4 Beacon Station Behaviours and Implementation

In our original design, the behaviour of the beacon station are fairly simple and it can be expressed in the following FSM
diagram (Figure. 19).

Init Receive radio

ping request
Finish one ping
operation

IDLE PING

Receve ACK for the ping

OR
10 pings done/timed-out

Figure. 19: Beacon Station FSM

After initialization, the beacon station is in the IDLE state waiting for a radio message from the Roomba requesting a
sonar ping. Then the beacon station will enter the PING state and keep performing sonar pinging until the Roomba
confirms the distance acquisition is finished. Note that between each sonar trigger, a 10 ms gap is required.

However, the beacon station can go back to IDLE state right after it finishes a sonar triggering operation since we found
that the measurements taken from Roomba subsystems are fairly accurate and consecutive sonar firing may even
interfere the readings.

To simplify the problem, we assume the beacon stations will only react to one ping request at a time thus no queueing
system is included.

19
Chapter 5: Explorer Roomba Subsystem Design and Implementation
In the previous Chapters, we have not distinguish the difference between Roomba subsystem. As mentioned in Chapter
1, there are explorer Roomba and rescuer Roomba that will have different behaviours. Their hardware components are
similar except for the hardware and software components used for human detection.

In this chapter, we will present the specific design and implementation for the explorer Roomba subsystem.

The design and implementation of the Explorer Roomba subsystem require major functionalities as follows:

1. Ability to communicate to beacon stations and the rescuer Roomba.

2. Ability to acquire distance readings from a specific beacon station.

3. Ability to drive the Roomba.

4. Ability to maneuver into another beacon station’s coverage.

5. Ability to detect human (optional).

As described in Chapter 1, the Explorer Roomba will follow the path formed by multiple beacon station. To simplify the
problem, the list of beacon stations are hard-coded into the Explorer Roomba as well as the Rescuer Roomba in this
project.

In addition, the ability to detect human is optional since PIR hardware available to us does not satisfy the timing
constraint of the system. This requires further investigation, and can be replaced by polling the Roomba’s bump sensor.
However, we will cover how to interface with PIR briefly in this chapter.

Throughout this chapter, we will describe the design that addresses above abilities and schematics that overcome certain
hardware issues that we encountered during the implementation.

This chapter is broken down into the following sections:

1. Explorer Roomba Subsystem Block Diagram.

2. Explorer Roomba Subsystem Schematic.

3. Explorer Roomba Subsystem Software Modules.

4. Explorer Roomba Subsystem Behaviour and Implementation.

The block diagram and schematic sections will provide detailed information and discussion on the hardware components
of the subsystem. The software modules, and behaviours and implementation sections, on the other hand, provide
information on the implementation approach that instruments the the hardware components to fulfill the specifications of
the Explorer Roomba Subsystem.

The related issues such as power supply, grounding, and RTOS scheduling are discussed in their corresponding
sections.

20
5.1 Explorer Roomba Subsystem Block Diagram
The explorer Roomba subsystem consists of the following hardware components:

• AT90USB1287 microcontroller

• SRF04 Ultrasonic Range Finder

• nRF24L01 2.4GHz radio chip

• Roomba

• KC7783R PIR Module (movement detection, optional)

• FT232R USB-UART interface (debugging purpose, optional)

Note that the PIR module is optional during the implementation as we have not yet operated it to meet the specification.
The reasons for its inability to meet the specifications are:

• delay between triggering are indeterministic.

• sensitive to strong shock or vibration.

• detection range might be varied in different temperature.

Furthermore, the FT232R is optional since the only available UART interface will be used for controlling Roomba thus it is
optional. Connecting FT232R, however. is very useful during implementation and debugging as the results gathered in
Chapter 2 are from using FT232R.

Below is the block diagram for the explorer Roomba subsystem (Figure. 20).

s
urst
ic b
son
PIR Sonar

assert signal lines (pins) assert signal lines (pins)

AT90 SPI Radio

UART
(Roomba SCI commands)

Roomba

Figure. 20: Explorer Roomba Block Diagram

21
The power supply issues, such as high current is drawn when sonar charges, is no longer a problem for the explorer
Roomba since the transducer on the sonar module is removed. However, providing +5V Vcc and signal ground is still an
issue that needs to be addressed. The next section will discuss this in further detail.

5.2 Explorer Roomba Subsystem Schematic

5V Regulator
10uF capacitor
I
Roomba
SCI G
GND
GND
O
RX TX

GND
0.1 uF capacitor
+5V
single-point +5V
ground
GND USB

PD2 VCC
Hex invertor
PD3
VCC
GND GND
PC6 NOT NOT Trigger
ISR PE7
MISO PB3 GND
MOSI PB2
SCK PB1
CSN PE6 PC7 Echo

CE PB4 GND

VCC VCC (+3.3V) SRF04

nRF24L01 AT90USB1287

Figure. 21: Explorer Roomba Subsystem Schematic

Note that the PIR module is not included in the schematic, however, it requires +5V and will occupy one pin on AT90.

The capacitors are used to smooth out the voltage. In addition, the AT90USB is not powered by external battery. Instead,
it draws power from Roomba’s DC battery, which provides clean power source. The power source from Roomba is
regulated down to +5V and AT90USB’s USB port takes +5V. As a result, we modified a standard 5 pins mini USB cable
so AT90USB can draw power from the +5V use this cable.

The hex inverter is used again to acquire 5V logical 1 for the SRF04 module. Furthermore, we do not use another
external 9V battery to power the SRF04. This is because the transducer on SRF04 is removed thus we are free of the
“brown-out” problem.

In order to control the Roomba, the UART interface on the AT90USB is used to send/receive Roomba’s SCI commands.

Furthermore, the Roomba approaches one beacon station at a time, and it must stop at certain distance and start to
avoid bumping into the beacon station. As a result another sonar module is required.

22
In order to connect an extra sonar module for obstacle avoidance, an extra output pin on AT90 is required to pulse the
sonar and diodes are needed to connect the echo lines of the sonar modules.

Diodes can prevent the current from going into the other sonar module circuitry. The diodes connection is shown in
Figure. 22.

AT90

Sonar_1 echo
(emitter disabled)

input capture
timer

Sonar_2 echo

Figure. 22: Sonar modules connecting to AT90 with diodes.

The diodes can prevent the current from flowing into the other sonar module thus ensuring the correctness of signal on
the input capture timer. Some modifications of the sonar driver is also required and we will discuss it in the following
section.

5.3 Explorer Roomba Subsystem Software Modules

5.3.1 Overview
The explorer Roomba Subsystem consists of the following software modules:

• nRF24L01 driver

• SRF04 driver

• Roomba SCI API

• Priority preemptive based scheduling RTOS

• Packet format for radio commands

We will give a brief discussion on each of these modules with respect to their specific issues for the explorer Roomba
subsystem in the remainder of this section.

23
5.3.2 nRF24L01 driver
The distance acquisition depends mainly on the short delay of nRF24L01 driver so the delay can be ignore.

However, we have found a flaw in our radio driver implementation by observation. Considering the following scenario.
The Roomba moves towards the beacon station as shown in Figure 23.

Beacon Station

Roomba

Figure 23: Roomba Movement.

The Roomba starts rotating until it roughly align its sonar listener to face the beacon station, and then it move straight for
some period of time. This amount of time moving forward should be proportion to the distance between Roomba and
the beacon station. As the Roomba gets closer and closer, more frequent it will send requests to the beacon station, in
which case, the radio will stop working. This particular behaviour is under investigated.

5.3.3 SRF04 driver

In order to avoid bumping into a beacon station, an extra sonar module is required thus the sonar driver needs to be
modified.

First we will need to initialize the pulse pin for the additional sonar module as an output pin. The trigger function in the
driver API takes an parameter to specify which sonar to fire. sonar_get_distance function is then called under the
assumption that the distance required is the previously fired sonar.

The distance calculation in the driver is done by keeping two time stamps, trigger time and echo time. According to the
timing diagram of SRF04, the trigger time is recorded when input capture timer interrupt fires on an rising edge on the
echo line, and the echo time is recorded on falling edge.

These two time stamps are unsigned 16 bit integers thus subtracting each other would not produce a negative number,
and gives us the time difference in clock ticks.

5.3.4 Roomba SCI API

According to iRobot’s Roomba SCI documentation, the API contains a mapping of the known commands of Roomba.

The API provides the following access functions:

• void Roomba_Init()

• void Roomba_UpdateSensorPacket(ROOMBA_SENSOR_GROUP group, roomba_sensor_data_t*

sensor_packet)

• void Roomba_Drive(int16_t velocity, int16_t radius)

24
The most important function for our project is the Roomba_Drive function. It takes the parameters and translate them
into SCI specified format. UART interface is then used to transmit the translated commands to Roomba.

5.3.5 RTOS tasks

Since most of the Roomba movements take more 1 tick (5 ms), and the frequency of sonar updates are dynamic,
SYSTEM tasks seemed to be the most useful in this case. However, the radio transmit and receive functions can be
made into two separate BRR tasks. The tasks are coordinated by using events.

The behaviour of the Explorer Roomba can be implemented using tasks and events as well, and we will address this in
the next section.

5.3.6 Packet format

There are two major types of messages that the Explorer Roomba uses. The first kind is the message between the
roomba and beacon stations. The second type of message is for the communication between the Explorer Roomba and
Rescuer Roomba. They are shown in Figure. 23.

Message with beacon

Command
Type (uint8_t) Sender(uint8_t) Receiver(uint8_t)
(uint_8)

Message with rescuer Roomba

Command parameter
Type (uint8_t) Sender(uint8_t) Receiver(uint8_t)
(uint_8) (uint16_t)

Figure. 23: Message packet format.

The first packet type has two command types: request sent from Roomba and ack sent from beacon station as
mentioned in the previous sections.

The second packet type is used to passed distance information to the rescuer Roomba therefore it has a parameter field
which can contain a 16-bit unsigned integer for distance value and the Sender field will be interpreted by the Rescuer
Roomba as the index into the list of beacon station thus indicating where the Rescuer Roomba should go. We will
address this further more in Chapter 6.

In order to process these packets, a task may be implement to process and signal Roomba to act accordingly. Thus a
header file that maps the command and packet format is shared by the software running on beacon stations, explorer
Roomba and Rescuer Roomba.

25
5.4 Explorer Roomba Subsystem Behaviours and Implementation
The explorer Roomba will have the following behaviours:

1. Approaching

2. SOS (requesting for rescue),

3. Waiting for rescue, and

4. Confirm rescue.

The overall behaviours transition is illustrated in the following diagram (Figure. 24):

Init No human
detected/ bumper not triggered

Human detected
Approaching SOS

Finished sending request

Rescue Conrmed for rescue

Comrm Waiting for

Rescue rescue
Rescuer informs
that it has arrived

Figure. 24: Behaviour State Chart

A state diagram is presented for each behaviour in the later sections. Basically, each behaviour can be implemented as a
task that waits for a signal. Thus the transition between states can be implemented using EVENTS and SIGNAL.

We will iterate through the discussion of each behaviour of the Explorer Roomba.

26
5.4.1 Approaching
The Explorer Roomba will following the list of beacon stations and approach one at a time until it gets into a certain
distance to a beacon where is also in the coverage of the next beacon.

There are two sub behaviours in the Approaching behaviour: Approach and Avoid. After Approach sub behaviour has put
the Roomba in a certain distance to a beacon station, the Avoid sub behaviour will become active and maneuver the
Roomba from the beacon station into the next beacon station’s coverage as shown in Figure. 25.

Beacon Roomba

Possible Roomba path

Figure. 25: Avoiding running into a beacon.

In the Avoid sub behaviour, the regular sonar module will be fired in order to perform obstacle avoidance as the beacon
station is considered the only “obstacle” in our project.

An alternative would be using the distance acquired from the beacon station and then maneuver the Roomba. However,
the orientation of the Roomba after it reaches the beacon station is not deterministic thus this simpler alternative is not
feasible.

The transition of the sub behaviour is illustrated in the following figure (Figure. 26).

No human detected and have not

reach the current beacon
No human detected and have not
reach the current beacon
reached the beacon

Approach Avoid

beacon avoided

Figure. 26: transitions between Approach and Avoid sub behaviours.

27
The following is the state diagram for the Approach sub behaviour (Figure. 27).

Approach
distance <= 50 cm Avoid sub behaviour

Finished rotating

Rotate right Request for

for 200ms distance

Does not receive

sonic bursts from the
beacon station distance
acquired
distance < 50cm

Move forward
for 1 second

Figure. 27: Approach sub behaviour state diagram.

The following diagram illustrates the Avoid sub behaviour (Figure. 28).

Approach

distance <= 50cm

Fire
Sonar_2
and Rotate right
measure for 100ms
distance to
obstacle
Done rotating

Approach
distance > 50cm
done rotating

Forward for Rotate left

2 seconds for 100ms

done forward

Figure. 28: Avoid sub behaviour state diagram.

Before going back to Approach sub behaviour the index to the list of beacon station should be incremented hence the
Roomba will start approaching the next beacon station.

Note that in both sub behaviour, if the PIR/bumper is triggered, subsumption will occur and cause the Roomba to
perform SOS behaviour. This can be done using interrupt, EVENTS, and preemption.

28
5.4.2 SOS, Waiting-for-Rescue, and Comfirm Rescue behaviour
For simplicity, SOS behaviour Waiting-for-Rescue behaviour can be combined since they occur consecutively.

The following is the state diagram for the behaviours (Figure. 29).

SOS
Done sending
Send WAIT for
distance info conrmed
to the from the
Rescuer rescuer
Roomba Roomba

Received radio
message from rescue Roomba
Approaching behaviour
Approach to
next beacon

Figure. 29: SOS and Waiting-for-Rescue state diagram.

The SOS behaviour is activated by triggering PIR or the bumper sensor on the Roomba. The task implements this
behaviour will subsumes other behaviours of the Explorer Roomba until the Rescuer Roomba has reach it.

29
Chapter 6: Rescuer Roomba Subsystem Design and Implementation
Finally, the design of the rescuer Roomba is addressed in this chapter. Basically, the Rescuer Roomba has identical
hardware components and software modules of the explorer Roomba except the absence of PIR module (the motion
detector). On the other hand, its behaviours differ from the explorer Roomba’s.

In this Chapter, the presentation of the design and the implementation approach of the beacon station are broken down
into the following parts:

1. Block Diagram

2. Schematic

3. Software Modules

4. Behavoiur State Diagrams

These information will provide a general idea to the readers on specifications and components of the beacon stations.
But our implementation is only one way to implement the design.

The design and implementation of the Rescuer Roomba subsystem require major functionalities as follows:

1. Ability to communicate to beacon stations and the explorer Roomba.

2. Ability to acquire distance readings from a specific beacon station.

3. Ability to drive the Roomba.

4. Ability to maneuver into another beacon station’s coverage.

This set of functionalities is basically a subset of the explorer Roomba.

This chapter is broken down into the following sections:

1. Rescuer Roomba Subsystem Block Diagram.

2. Rescuer Roomba Subsystem Schematic.

3. Rescuer Roomba Subsystem Software Modules.

4. Rescuer Roomba Subsystem Behaviour and Implementation.

The block diagram and schematic sections will provide detailed information and discussion on the hardware components
of the subsystem. The software modules, and behaviours and implementation sections provide information on the
implementation approach that instruments the the hardware components to fulfill the specifications of the Rescuer
Roomba Subsystem.

Since the hardware of the Rescuer Roomba is identical to the Explorer Roomba and the power supply issue had been
addressed in the previous chapter, we will not discuss them further in this chapter unless special approach or care is
required during the implementation.

30
6.1 Rescuer Roomba Subsystem Block Diagram
The Rescuer Roomba subsystem consists of the following hardware components:

• AT90USB1287 microcontroller

• SRF04 Ultrasonic Range Finder

• nRF24L01 2.4GHz radio chip

• Roomba

• FT232R USB-UART interface (debugging purpose, optional)

The FT232R is optional since the only available UART interface will be used for controlling Roomba. Connecting FT232R,
however. is very useful during implementation and debugging,

Below is the block diagram for the explorer Roomba subsystem (Figure. 30).

signal line
Sonic bursts
(pin)

Sonar

Roomba UART AT90 SPI Radio

Figure. 30: Rescuer Roomba Block Diagram

Similar to the explorer Roomba, the sonar module is modified so it only listens for sonar pings. In addition, an extra
regular sonar module (not modified) can be added for obstacle avoidance during approaching the explorer Roomba.
Connecting two sonar modules to the AT90 using diodes to prevent unwanted current flow is addressed in the previous
chapter.

31
6.2 Rescuer Roomba Subsystem Schematic
The following (Figure. 31) is the schematic for the Rescuer Roomba subsystem. The connection of an additional sonar
module for obstacle avoidance with diodes is included.

5V Regulator
10uF capacitor
I
Roomba
SCI G
GND
GND
O
RX TX

GND
0.1 uF capacitor
+5V
single-point +5V SRF04 Emitter disabled
ground
GND USB

PD2 VCC
Hex invertor
PD3
VCC
GND GND PC6 NOT NOT
Trigger
ISR PE7
PC5 NOT NOT
MISO PB3 GND
MOSI PB2
SCK PB1
CSN PE6 PC7 Echo

CE PB4 GND

VCC VCC (+3.3V)

nRF24L01 AT90USB1287
VCC

trigger

echo

GND

Regular SRF04

Figure. 31: Rescuer Roomba Schematic.

The issue of single point ground is addressed in the Chapter 5, hence we will not discuss it further here.

In addition, one more instance of the hex inverter is not required since the hex inverter has 8 pair of input-output.

We will discuss the software modules that instrument the hardware to achieve the goal of the Rescuer Roomba in the
next section.

32
6.3 Rescuer Roomba Subsystem Software Modules

6.3.1 Overview
The rescuer Roomba Subsystem consists of the following software modules:

• nRF24L01 driver

• SRF04 driver

• Roomba SCI API

• Priority preemptive based scheduling RTOS

• Packet format for radio commands

We will give a brief discussion on each of these modules with respect to their specific issues for the explorer Roomba
subsystem in the remainder of this section.

6.3.2 nRF24L01 driver

Similar to the Explorer Roomba subsystem, the driver must be able to change the transmitting address during runtime,
and starts receiving without sending out a dummy packet before hand.

We have attempted to modify our driver to satisfy these requirements, however, we have not yet succeeded.

The implementation result and future work of this project will be discussed in Chapter 7 where this will be discussed in
further detail.

6.3.3 SRF04 driver

In order to avoid bumping into a beacon station, an extra sonar module is required thus the sonar driver needs to be
modified.

First we will need to initialize the pulse pin for the additional sonar module as an output pin. The trigger function in the
driver API takes an parameter to specify which sonar to fire. sonar_get_distance function is then called under the
assumption that the distance required is the previously fired sonar.

However, we have discover that without the diodes connecting to the echo lines from the sonar modules, the readings
are not usable and no mentioning of working solution.

6.3.4 Roomba SCI API

The same SCI API is used in the rescuer Roomba subsystem as we need to drive the rescuer Roomba to the explorer
Roomba. Therefore, we will not discuss any further here as it is already addressed in the previous chapter.

6.3.5 RTOS tasks

The major tasks implements the Rescuer Roomba’s behaviour, however, there is no critical subsumption required for
Rescuer Roomba as it does not detect human presence or detect the bumper sensor on the Roomba. The only
subsumption occurs while in STAND-BY behaviour and receives a command from the explorer Roomba. We will discuss
this in further detail in section 6.4.

33
6.3.6 Packet format
There are two major types of messages that the Rescuer Roomba uses. The first kind is the message between the
roomba and beacon stations. The second type of message is for the communication between the Explorer Roomba and
Rescuer Roomba. They are shown in Figure. 32.

Message with beacon

Command
Type (uint8_t) Sender (uint8_t) Receiver(uint8_t)
(uint8_t)

Message with explorer Roomba

Command destination distance

Type (uint8_t) Receiver(uint8_t)
(uint8_t) beacon(uint8_t) (uint16_t)

Figure. 32: Rescuer Roomba Message packet format.

The first type of the message packet is the same with the one that the Explorer Roomba subsystem uses. Its purpose is
to communicate with the beacon stations.

The explorer Roomba will use the second packet format to inform the rescuer Roomba of its distance to a certain
beacon, thus the rescuer Roomba will approach to the specified beacon and stop at the given distance.

The rescue confirmation is done by sending the explorer Roomba a command type of CONFIRM. The explorer Roomba
will continue approaching to next beacon after receiving this command.

6.4 Rescuer Roomba Subsystem Behaviours and Implementation

The rescuer Roomba has three behaviours as the following:

1. Stand-By,

2. Rescue, and

3. Confirm Rescue.

The overall transitions between behviours are shown in Figure. 33.

INIT
Receives
"Not near the
rescue request &location data
explorer"
from the explorer

STAND-BY Rescue

Finish Conrm Rescuer determines it is

conrmation Rescue "Near the explorer"

Figure. 33: Behaviours State Chart

34
The STAND-BY behaviour is subsumed by Rescue behaviour when the rescuer Roomba receives a rescue request radio
message containing location information from the explorer Roomba.

The behaviours of the rescuer Roomba are illustrated in the following sections.

6.4.1 Stand-By
Init
No rescue request
from the explorer

Go to
STAND-BY "Rescue"
behaviour
Received rescue request
and location data

Figure. 34: Stand-By Behaviour

The rescue Roomba stays in the STAND-BY state after initialization until it receives a radio message from the explorer
Roomba requesting for rescue. The message also contains the location information of the explorer Roomba. With these
information, the rescuer Roomba enters “Rescue” behaviour.

6.4.2 Rescue
The rescue behaviour is essentially the same with the Approaching behaviour for the Explorer Roomba subsystem. There
are two sub behaviour as shown in Figure. 35. The only difference is that the transitions does not changed from PIR
triggering or bumper sensor as the Rescuer Roomba does not detects human.

Reached the specied beacon

at the given distance

Approach Avoid

beacon avoided

Figure. 35: Rescue Behaviour

The state diagrams for the sub behaviours are shown in Chapter 5 already, hence we will not present it again here.

6.4.3 Confirm Rescue

Once the rescuer Roomba have reached destination beacon station at a given distance from the message from the
explorer Roomba, it will then sends out a radio message thus the explorer Roomba will continue approaching to the last
beacon station.

This behavious can be implemented by using a BRR task that waits on an EVENT signal signaled upon the finish of the
Rescue behaviour explained before.

35
Chapter 7: Final Result and Futurework
Due to the given timeframe and hardware issues that we have encountered during the implementation, we were only able
to implement a subset of the proposed project design.

However, we believed that the current result can serve as a proof of concept as the it already provides the fundamental
components for the complete implementation.

Our result contributes the following areas:

• resolve the hardware issues so the major ground work can be done for the indoor localization.

• software modules instrument the hardware components that enable the possibility for indoor localization using
passive approach.

• accurate distance measurement between beacons and roomba.

• concrete schematic for connecting hardware components.

The future work that be done includes the following:

• implements the all the behaviours for the Roomba subsystems.

• algorithms for rejecting outlier distance readings.

• triangulation algorithms.

• building more beacon stations for better testing hardness.

• automatic beacon station registering.

The final code and result demonstration videos are available on

http://webhome.uvic.ca/~lienh/rtos/project5/

36