Technical document:

Muticore embedded robot

Jasper Maes
3rd Bachelor Computer Science
Enrollment: 89619
jasper.maes@vub.ac.be

March 7, 2011
Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Robot controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Robot controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Detailed design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Robot controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 UML class diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Date Version Description

25 february 2011 First draft A first draft of the document
27 february 2011 Second draft Corrected spelling and dependency diagrams
1 march 2011 Third draft Applied the MVC design pattern to the project
4 march 2011 Fourth draft Added UML class diagrams, introduced data store entity
6 march 2011 Release candidate Updated UML diagrams and added sequence diagrams
7 march 2011 Final version Added conclusion as requested by the customer

Change Log

1
1 Introduction
1.1 Purpose
This document shows how all components or entities in the project will be implemented. These
entities are determined by the requirements from the specifications document[4]. Throughout the
document all requirements will be identified by their number. A requirement will be indicated by
’req.’ followed by the number that corresponds to a requirement in the specification document.
In the first section, all components are described. We will present what each component does and
why it is necessary for the project. The next section describes how all entities are related to each
other. In the third section, an in depth explanation is given on how we will implement the system.
UML class diagrams of each entity should make the text more understandable. At the end of this
document the complete UML diagrams are shown.

1.2 Scope
With this project we will implement a robot, using a multicore embedded device[6]. The user will
be able to control and steer the robot using a remote control. The robot will use sensors to be
aware of its environment and respond appropriately. For example, if the user wants to drive the
robot into a wall, it will stop before hitting the wall.

1.3 Definitions and Acronyms

Arduino An open source embedded device. More information on Arduino devices can be found
on their website [2].
Canvas A widget in the Swing[5] library on which different types of data such as strings and
pictures can be drawn.
Channel A channel is added in the XC programming language to support communication between
2 threads. These threads can run on different cores.
Observer One object, the observer keeps a list of all subjects that should be notified if a certain
event occurs.
Widget A control that is displayed in a window of a GUI. Examples are buttons, textboxes,
progress bars, ...
XBee A device that implements the ZigBee standard and uses it to create a wireless network. It
can be compared to a usb stick that allows a computer to connect to a Wi-Fi network.
XC The programming language used to develop programs for the XMOS devices. It is the same
as the C programming language but there are new features implemented to support multicore
computing.
XMOS A manufacturer of multicore embedded devices. More information is available on their
website [8].
ZigBee An open wireless connection standard. It is an addition to Bluetooth and Wi-Fi.

2
1.4 References
[1] Anonymous. Bug #4153069. http://bugs.sun.com/view_bug.do?bug_id=4153069, June
1998.

[2] Arduino. Arduino. http://www.arduino.cc, 2010.

[3] Eric J. Braude and Michael E. Bernstein. Software Engineering: Modern Approaches. Wiley,
second edition, 2011. ISBN 978-0-471-69208-9.

[4] Jasper Maes. Specifications document: Multicore embedded robot. http://artoo.rave.org/

public/specifications.pdf, January 2011.

[5] Sun Microsystems. Java SE desktop overview. http://java.sun.com/javase/technologies/

desktop/, 2010.

[6] Christophe Scholliers. Multicore embedded robot. http://artoo.rave.org/public/

ProjectProposal.html, October 2010.

[7] Tjarvi. RXTX wiki. http://rxtx.qbang.org, January 2010.

[8] XMOS. XMOS. http://www.xmos.com, December 2010.

2 Decomposition
The project can be divided in two major parts, the graphical user interface and the program that
will control the robot. These two parts will be described more extensively in the two subsections
below.

2.1 Graphical user interface

This part consists of three components that each play a major role in the graphical user interface.

2.1.1 Serial connection

This entity opens a serial connection on the port to which the Arduino/XBee is connected. When
the connection is open, it reads all data that is sent by the robot. It also writes all the commands
given by the user to this port.
All communication between the computer and the robot consists of byte codes followed by zero or
more numbers. These numbers can be, for example the value from the sensor. In section 4.3, a
more in depth explanation of these bytecodes is given.

2.1.2 Input parser

All data that is received over the serial connection goes through to the parser who will select the
action that corresponds to that bytecode. This action is nearly always a function that stores the
value that was sent along with the command in the data store. But as explained later in the
document, there are commands that are not displayed.

3
2.1.3 Data store
When data is read, it has to be stored for the other parts of the program. The data store keeps all
values that are received. It provides the rest of the program with a central point where the data is
located.

2.1.4 Interface
The interface itself will display all values that are received (req. 5.2). It will allow the user to see
what the robot ‘sees‘. From this interface the user will control the robot either by pressing keys on
the keyboard or buttons in the interface (req. 5.1). All entities work together to give this interface
its functionality.

2.1.5 Printer
Because of the low coupling principle and to make the code as extendable as possible (req. 3.1),
there will be a printer entity. This printer can draw values on the interface. If, later on, the
programmer wants to replace the interface with something else, he just has to change the methods
in this printer. He could create a commandline application with a textual representation of the
data.

2.2 Robot controller

The robot controller program is in structure very similar to the graphical user interface. This is
because both parts send commands to and receive commands from the other. These commands are
processed in the robot, the same way as in the interface.

2.2.1 Serial connection

All commands that are sent by the computer are received by this entity. Every sensor sends its
data to this entity that will send it to the computer. The functionality is quite similar to that of
its counterpart in the graphical user interface. Except for the fact that the connection is always
open, there is no serial port to open. If the device that sends the data, the XBee, is broken, the
robot would send data without knowing that it is actually transmitted. Because the XBee does not
provide any feedback if the data was sent or not, there must be an other way to determine this.
The solution is perform a ping on the robot, if it does not respond fast enough, the connection is
considered broken. This ping is explained in section 4.1.2.

2.2.2 Input parser

This entity resembles the input parser in the graphical user interface. The main difference is that
all commands, except the ’ping’ are unidirectional. Sensor data only goes from the robot to the
computer while move instructions only go the other way. The commands that are processed differ
on the robot and the computer but the technique to process them is similar.
Instead of communicating with the graphical interface, this entity communicates with the motor
controllers and all the sensors.

4
2.2.3 Sensors
All sensors are in fact the same. Every sensor must be able to read its value and send it to the
computer. How this is done is different for each sensor. If every sensor supports the same operations,
it will be very easy to add new sensors (req. 1.6). The programmer just has to implement these
operations and make sure its value is checked in the loop that will read the sensors and send the
value (req. 3.1).

2.2.4 Evaluator
The evaluator checks if the value read by the sensor is above the threshold or not. It is a necessary
part to implement all requirements (req. 1.2). If the value is above the threshold, it will trigger the
action that comes with that sensor.

2.2.5 Motor
The motor is different from all the sensors as it does not provide the robot with data. It just
performs the action that corresponds to the received command. There is no feedback.
This entity will control both motors to make the robot move. By activating the correct motor when
a command is received, the robot will turn, drive or stop.

3 Dependencies
This section shows how all entities described above are related to each other. Figure 2 and 3 are
the visual representation of each subsection.

3.1 Graphical user interface

The graphical user interface will be implemented using the Model-View-Controller or MVC design
pattern[3]. This design pattern is a based on the observer design pattern. The serial connection,
input parser and the data store entities serve as the model part of the design pattern, they provide
and process the data for the rest of the application. The printer will use this data to present the
user with a visual representation. It thus forms the view part. The window uses a keypresslistener
to capture the keys the user presses. Based on this keypress, a command is sent to the serial
connection. This listener is the controller in the design pattern.
Figure 1 shows a visual representation on how these three components are combined. A solid line
indicates a direct connection. For example the controller can write data to the serial connection
that is part of the model. A dashed line indicates an indirect connection for example by using an
observer. For example, if the model changes when new data becomes available, the view must be
updated. When the serial connection receives data from the robot, the data is sent to the input
parser. The input parser will then analyze this data and except for when the data is a ping request,
the data is stored in the data store entity. After that, the printer is notified of the new data that
has become available. The printer entity can access all private members from the interface so it can
display all values it receives.
The user uses key presses to control the robots movement. The interface listens for these key presses

5
Figure 1: Model-View-Controller design pattern

Figure 2: Dependency diagram for the GUI

6
and sends the corresponding command to the serial connection. The serial connection will then send
these to the robot.

3.2 Robot controller

The program that controls the robot is very similar to the one on the computer. The serial connec-
tion communicates with the computer. When it receives a command, it is sent to the input parser.
This will then either set the threshold value of the sensor, send the command to the motor to make
the robot move or respond to the ping request.
At fixed intervals, the sensors will send their value to an evaluator. This will check if the value has
reached the threshold or not. If so, it will call the action assigned to it. After checking the value,
the data is sent to the serial connection who will send it to the computer for displaying.

Figure 3: Dependency diagram for the Robot controller program

4 Detailed design
This section has all the details on how every entity will be implemented. The entities have all
been described briefly in section 2. Every entity contains an image of the UML class diagram
that describes this entity. Some of these diagrams are trivial but shown to be complete. The XC
programming language doesn’t support UML diagrams as there are no classes in this language. Yet,
classes are simulated by grouping operations and variables together.
In section 6, the whole class diagrams and all associations between them are shown. There are also

7
two sequence diagrams provided that illustrate how every entity communicates with the others. It
shows a few of the many possible types of communication. For the graphical user interface, the
diagram shows what is done when the serial connection receives sensor data from the robot. For
the robot, more diagrams were made. They show what the robot does when a motor command is
received, when the threshold of a sensor must be updated and the third shows how the sensor data
is collected and sent to the computer.

4.1 Graphical user interface

4.1.1 Serial connection
To start the serial connection, an external library must be used. The best option is the library that
is provided with the Arduino IDE. This is the RXTX library[7]. It is also the one that is used in
the examples on the Arduino website. This library is the recommended and most used library for
connecting with an Arduino from a Java program.
The user interface initializes the connection by providing the location to where the Arduino is
connected. On a Windows computer this is a COM -port, on Linux this is a file in /dev. When the
connection is made, a listener is started on the port. When data is available on the serial port, a
jump table will be used to determine how much additional information is required. When all data
is acquired, it is sent to the input parser.

Figure 4: UML Class diagram for the serial connection

4.1.2 Input parser

When data is received by the input parser, the type of command is checked. If it is sensor data,
it is put into the data store, if it is a ping request, the parser responds to this request. In our
application only two types are used but different functionality can be imagined. After the data has
been stored, the printer is notified of the new data.
If the robot were to send its information without taking into account that two commands could

8
be mixed up, this system would fail. By allowing only one command to be sent at every moment,
the data won’t be mixed up. The function will be defined with the synchronised keyword. This is
a keyword that locks the function when it is called. When the function is called again before the
previous call is finished, it is put into a queue until all calls before the new one are finished.
There is a second problem with this type of communication. If the connection between the robot and
the computer is interrupted, it should stop performing the current action. If not, the robot would
for example keep on moving which could result in a dangerous situation. Therefore, the computer
will send a signal to the robot at fixed intervals. If the robot does not receive the command on
time, it will stop moving. If the robot does not respond fast enough, the connection is considered
to be broken. This process of sending a request at fixed intervals and measuring the time passed
since sending the request, is similar to a ping request.
The input parser will keep an array of all printers that have to be notified when new data is available.
The notify method loops over all printers in the array and calls their update method.

Figure 5: UML Class diagram for the input parser

4.1.3 Data store

The data store is an abstraction of a system to store data. This can be a file, a database or
something else. We don’t have to save every value received from the robot. We just need the most
up to date value. Therefore we will store only this value. The data store keeps an array of all these
values. This array is indexed with the number of sensor.

Figure 6: UML Class diagram for the data store

9
4.1.4 Interface
The interface is a canvas in a window. This canvas will be the target of the printer described in
detail further in this document.
All information is drawn on that canvas and not on the window itself. This allows us to take the
canvas and put it in a different application without changing any code. This new application can
be an extended version of the application we will create in this project.
On the canvas, all data is visualized using either text, a shape or an image. There is also a button
that when clicked, shows a dialog where the user can select the port. The serial connection will be
started on that location. This button will also indicate the status of the connection (req. 5.3). It
becomes red when the ping request times out, otherwise it is green to indicate everything is good.
After the serial connection has been initialized, a key-listener is started. Depending on which key
the user has pressed, it sends the right command to the serial connection who will write the value
to the serial port.
If we do not take into account that a key that is pushed keeps sending the key-pressed signal, the
connection with the robot would be flooded with commands. This can be seen for example in a
word processing application. If you keep pressing a key, that character keeps appearing at a fast
rate. The computer would send so much messages, the robot can’t respond to the ping requests or
send the data from the sensors.
Therefore, we will save the last key that has been pressed. If the next key that is pressed is equal to
that saved key, it is ignored. This way, we do not send enormous amounts of commands and keep
the connection fast (req. 2.2).
There is a known bug in the X11 system[1]. When a key is pressed, the signal keypressed should
be sent but in X11 also the keyreleased signal is broadcasted. Therefor we need to check if the key
was really released or not. The fix for this bug also works in OSX and Windows so there is no
checking needed to know which keylistener to use, the timedkeylistener or the regular one. There
is a workaround proposed by a user called Ekipur which will be used in our program.

4.1.5 Printer
The printer provides a number of functions to display values on the canvas. By using this extra
layer of abstraction, the canvas can easily be replaced with some other type of container that can
be drawn on.
When the input parser has stored new values in the data store, it notifies the printer by using the
update method. This method will then read the new values from the data store and draw them on
the canvas. As the printer is an inner class of the interface, it can access this canvas to draw the
values on.

4.2 Robot controller

4.2.1 Serial connection
All commands that are received are returned as a bytecode that is casted to a character except for
the additional data. This makes the programming easier as characters speak more for themselves
than numbers. When the data is received, it is sent to the input parser for further actions.

10
Figure 7: UML Class diagram for the interface

Figure 8: UML Class diagram for the printer

11
When a command is to be sent to the computer, it is converted into bytes first. After that, it
is broken down in separate bits that are sent over the zigbee network. These bits are sent at a
specified rate. The computer and robot must communicate at the same rate. If not, data would
not be received by the other.

Figure 9: UML Class diagram for the serial connection in the robot

4.2.2 Input parser

Here the use of some sort of numbers as the codes for the commands is the best option. Due to the
limitations of the XMOS device, the code must be as fast as possible (req. 2.1). In the C and XC
programming language, integer or some other type of number are the only data types that can be
used in a switch statement or jump table. This way, the correct action can be easily found.

Figure 10: UML Class diagram for the input parser in the robot

4.2.3 Sensors
Every sensor has four functions and two private variables. The functions take care of reading the
value from the sensor, getting and setting the trigger value and an action. This action is called
when the threshold is reached. The private variables contain the threshold and the port to which
the robot is connected. In some cases, the sensor requires more than one port. These are then
added to the derived classes. Because the C and XC programming language do not support classes,
function pointers have to be used for the functions that the sensor requires.
To keep everything uniform, every sensor will provide a function that sets the threshold. If there is
no need for such a function, there will be an empty implementation. This is the same for the action
that is triggered after reaching that value.
All sensors are combined in what is called a sensormanager. This data structure keeps track of all

12
the sensors that are available. We will implement this sensormanager as an augmented array. Next
to the array, we save other data about the array such as the number of sensors that are contained.

Figure 11: UML Class diagram for the sensors

4.2.4 Evaluator
The evaluator is an infinite loop that will check all sensors. The sensors are contained in an
sensormanager. First the value is requested, then that value is sent to the serial connection through
a channel. After that, if the value is above the threshold, the action that belongs to that sensor is
called. The value is sent before calling the action. Data can be sent to a channel at any time. But
it isn’t guaranteed to be received by the serial connection immediately. There can be other data
waiting to be sent before the new data. By sending the data first, the user will be alerted as fast
as possible. The action that is called could take a while to perform.

4.2.5 Motor
The input parser sends the commands for the motor to a function that will activate the correct port
of the board. That will activate the motor controller and make the robot move. If one controller is
activated, the robot will turn. If both are activated, he will drive forward or backward.

13
 Figure 12: UML Class diagram for the evaluator

Figure 13: UML Class diagram for the motor

4.3 Protocol
This section will explain how the commands are formatted to be sent over the zigbee network.
First the type of command will be indicated by a bytecode. This uniquely identifies the command,
it can be seen as an id number. If the command requires more information such as a value, it is
sent right after the command. For example, to make the robot move forward, just the command is
required. The robot can understand the command ’move forward’ without more information. But
a sensor must send its value along with the byte-code that identifies the command.
In the application itself, a more visual representation of these byte-codes will be used. Each com-
mand is assigned a character and that character is converted to a byte-code before sending it. This
makes the programming easier but keeps the data to be sent short and thus the communication
fast.
Table 1 shows a list of all commands that can be sent either by the computer or the robot. The
character codes are represented by their hexadecimal values. The table also contains what data is
sent along with the command. A brief description of what each command does completes the table.

14
 Table 1: Commands

Command (hex) Additional data Description

42 none Drive backwards
46 none Move forward
4C none Turn left
Computer 52 none Turn right
53 none Stop moving
50 none Ping request
54 sensor number, new value Set trigger value
50 none Response to ping request
Robot
54 sensor number, value Send the sensor value

5 Conclusion
For this project we will create a robot that is aware of its environment using sensors and can be
controlled from a graphical user interface.
There are two individual programs that, when combined, form this robot. On the computer side
there is the grapical user interface and on the other side is the program that controls the robot. It
is this second part that provides us with the most challenges due to the fact that it is programmed
on the multicore architecture of the embedded device. To make the program as performant and
extensible as possible, we have to use the XC programming language. This language allows us to
create performant programs that use the multicore architecture of the device. While it provides us
with functions that allow multicore programming, it prohibits us to program in an object oriented
way as it does not support classes. Therefore we will use well structured abstract data types to
implement all the entities in this program. Using abstract data types makes the program more
extensible.
Where the program that runs on the embedded device uses abstract data types, the graphical
interface has been built around the model view controller design pattern. This divides the program
into three separate parts making it more extensible.
While implementing this project, performance and extensibility must be kept in mind at all times.
Not only on the robot side of the project but also while implementing the graphical user interface.

6 UML class diagrams

Below are the complete UML class diagrams of both parts of the project. Every part of these
diagrams has been described in detail in section 4.

15
16
Figure 14: UML class diagram for the graphical user interface

17
Figure 15: UML class diagram for the robot

18
Figure 16: UML sequence diagram for when the computer receives sensor data

19
Figure 17: UML sequence diagram for when the robot receives a motor command (1), a command
to update the threshold (2) and the loop that sends the sensor values to the computer (3)

20