Specifications document:

Muticore embedded robot

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

January 9, 2011
Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.4 Communication Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.5 Memory Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Product Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 User Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Software Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Date Version Description

20 december 2010 First draft A first draft of the document
27 december 2010 Second draft Further specification of sections 2.2 and 3.
29 december 2010 Third draft Correcting spelling and grammatical mistakes
6 january 2011 Fourth draft Added requirements requested by client (3.5)
8 january 2011 Fifth draft Adjustments requested by client (req. 5.2)
9 january 2011 Release candidate Changes to figures 4 and 5.
9 january 2011 Final version Changes to figure 2. Correct spelling.

Change Log

1
1 Introduction
1.1 Purpose
This document serves as a checklist for the client and the developer. It describes in detail all the
requirements for the project[5]. At the end of the project development, the client can see if all
requirements are implemented as described in this document. The developer will use this document
as a list of all items requested by the customer for the final product.
First an introduction will be given, complete with scope, definitions and references. After that, all
required components for the project will be described. It will provide a general setting for the third
part that will describe every requirement in detail.

1.2 Scope
With this project we will implement a robot, using a multicore embedded device. 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 [1].

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.

XMOS A manufacturer of multicore embedded devices. More information is available on their

website [7].

ZigBee An open wireless connection standard. It is an addition to Bluetooth and Wi-Fi.

1.4 References
[1] Arduino. Arduino. http://www.arduino.cc, December 2010.

[2] The Eclipse Foundation. SWT. http://www.eclipse.org/swt/, January 2011.

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

desktop/, 2010.

[4] Nokia. Qt. http://qt.nokia.com/products, December 2010.

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

ProjectProposal.html, October 2010.

[6] XMOS. XC-1A Hardware Manual. XMOS, April 2010.

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

2
2 General Description
2.1 Product Perspective
2.1.1 User Interface
The project consists of two major parts. The first is the robot and its embedded application. This
is explained in section 2.1.2. The second is a graphical user interface. This should allow the user
to control the robot and set different options. Such as setting how close the robot will move to a
wall before it stops. A more complete description of the user interface can be found in section 2.2.

2.1.2 Hardware Interfaces

The core of this project uses a multicore embedded device, manufactured by XMOS. This board
allows the user to develop embedded multicore applications. You can also control different sensors,
actuators and other input and output devices using an XMOS board. This board will control all
sensors and actuators added to the robot.
The communication between the computer and the XMOS board will be made possible using a
ZigBee module, named XBee. One XBee will be connected to the XMOS board, the other will be
connected to an Arduino board. This Arduino board will then be connected to the computer and
serve as an adaptor for the XBee. Figure 1 shows a diagram of these connections.

2.1.3 Software Interfaces

For the graphical user interface, cross-platform libraries are to be used. For example, the Swing or
SWT libraries for Java or the QT libraries. These libraries allow developing for multiple platforms
simultaneously. As one of the requirements is a cross-platform application, these libraries are a
good point to start. More information on these libraries can be found on their website [3], [2] and
[4].

2.1.4 Communication Interfaces

As explained earlier in section 2.1.2, the communication between the robot and the computer will
use a ZigBee network. The communication from the computer to the ZigBee module connected to
an Arduino board uses a serial interface on the computer. When the microcontroller is removed
from an Arduino board, it allows us to directly send messages over the ZigBee network. In figure 1
a diagram is showed that illustrates how every device is connected to the other.
The communication between the XMOS board and the different sensors will be either serial or
parallel depending on the device. For example, the screen uses a parallel interface where XBee
module uses a serial interface. The screen will be used to display the status of the robot.

2.1.5 Memory Restrictions

Embedded devices are very limited when it comes to memory. An XMOS board only has 4 Mbits
of memory. That is about 512 kilobytes. As the memory from the board cannot be extended, this
limit has to be respected. Thus the program must be kept as lightweight as possible.

3
 Figure 1: Communication diagram

The Arduino board is used as an adaptor for the ZigBee module. It allows us to use it from the
computer. Therefore it doesn’t require any memory.

2.2 Product Functions

The user will be able to control and watch the value of all sensors in the graphical user interface
(requirement section 3.5). The robot has to be able to measure the distance between itself and an
object (req. 1.1) and measure the room temperature and the light intensity (req. 1.3).
When the user is driving the robot around, the robot could come close to an object such as a wall
or a table. It continuously registers the distance to objects in front of itself. If this value is to small,
when the robot is too close to the object, it has to stop even if the user wants it to move closer.
The robot thus must be able to override commands given by the user (req. 1.2).
The graphical interface should also allow the user to set various values for the sensors. If a sensor
reaches this value, the robot will respond for example by stopping. It can also ignore the value and
just show a message on the screen.
In figure 2, a use case diagram is shown that illustrates all the features of the graphical user interface.

The robot itself measures the distance it has driven (req. 1.4). Based on this distance and the time
elapsed, the speed can be calculated (req. 1.5). The speed can also be used to keep both motors
running at the same speed. Two motor are never exactly the same so there is always one turning
faster than the other. This has to be corrected.
All values that are registered will be sent to the computer and displayed in the graphical interface.
To reach the biggest number of users, the graphical interface will be cross-platform. The program
must at least work on various Linux flavors and the Mac OSX platform (req. 4.1).
Figure 3 on page 6 shows a use case diagram on which commands the computer is allowed to give
to the robot.

2.3 User Characteristics

The end user is not required to have any specific technical knowledge. The graphical user interface
on the computer will be the only part of the project he has to work with.
This interface will be very intuitive and thus easy to use.

4
Figure 2: Use case diagram graphical user interface

5
Figure 3: Use case diagram interface with XMOS board

6
2.4 Restrictions
Next to the memory limitations of the XMOS board, the usable programming languages are limited
to just one. To enable the multicore features of the board, the manufacturers have developed a new
programming language, XC. It is an extended version of the C programming language introducing
new operators and data types to allow multicore programming for their devices.

3 Specific Requirements
All requirements can be divided into 5 categories, functional and performance requirements, software
attributes, portability and requirements for the graphical user interface.
Every requirement has a unique number that consists of 2 numbers. A first number indicates the
category. The second number is the serial number of the requirement in the category.
Next to a number, every requirement is marked as required, desirable or optional.
An in depth description of the requirement completes the item.

3.1 Functional Requirements

3.1.1 Detect how far an object is
Number: 1.1
Priority: Required
Description:
To prevent the robot from hitting an object, the distance to an object in front of the robot
must be measured. This value can be used for overriding commands as described in req. 1.2.

3.1.2 Override commands

Number: 1.2
Priority: Required
Description:
The robot will measure different environmental factors. If a measured value poses a threat to
the robot, it must be able to override the commands given by the user.

3.1.3 Measure temperature and light intensity

Number: 1.3
Priority: Required
Description:
To provide the user with environmental information, the temperature and light intensity will
be measured.

7
3.1.4 Measure driven distance
Number: 1.4
Priority: Desirable
Description:
A sensor will measure the driven distance. Two motors aren’t the same. There is always
one faster. This distance measurement can be used to correct this difference by speeding one
motor up.

3.1.5 Calculate speed

Number: 1.5
Priority: Desirable
Description:
Based on the distance moved in a certain amount of time, the speed can be calculated. This
speed will then be displayed in the graphical interface.

3.1.6 Add extra sensors and actuators

Number: 1.6
Priority: Optional
Description:
Many other sensors, such as humidity and GPS, exist and can be added to the robot. If there
is enough time left, the robot will be extended with other sensors. Which sensors will be
added has to be discussed with the client.

3.2 Performance Requirements

3.2.1 High responsiveness
Number: 2.1
Priority: Required
Description:
The robot must respond fast. Therefore the program must be lightweight. Due to the limited
computational power of the XMOS board, this will have to be kept in mind when developing
the application.

3.2.2 Fast communication between computer and XMOS board

Number: 2.2
Priority: Desirable
Description:
This requirement is connected closely to req. 2.1. To be able to respond fast, the connection
between the computer and the XMOS board has to be fast too.

8
3.3 Software Attributes
3.3.1 Extendable code
Number: 3.1
Priority: Required
Description:
This is always a requirement as modularity is an aspect of good code. But in this project, it
should be easy to remove or add new sensors and actuators. Other, later developers should
be able to set the robot up very easily and extend it. They can extend the robot itself or add
new features to the client program.

3.4 Portability
3.4.1 Graphical interface works with Linux and Mac OSX
Number: 4.1
Priority: Required
Description:
The user has to be able to choose his favorite platform and run the graphical user interface
from there. It can’t be limited to one platform only. Selecting cross-platform libraries for the
graphical interface allows us to create the cross-platform application.

3.4.2 Port graphical user interface to Windows

Number: 4.2
Priority: Optional
Description:
When there is enough time left at the end of the project, the Linux or Mac OSX application
will be ported to the Windows platform.

3.5 Graphical User Interface

3.5.1 Steering
Number: 5.1
Priority: Required
Description:
The user of the application should be able to drive the robot and steer using the arrow keys.
The image of the robot will rotate as the robot rotates. This way, it displays in which direction
the robot is driving. This is shown in figure 4 by the 3 slightly rotated images.

9
3.5.2 Visualise sensor data
Number: 5.2
Priority: Required
Description:
The sensor data must be displayed in the interface. If the robot comes too close to an object,
the user should be warned. It could be displayed in the same way, a parking sensor informs
the driver. The distance driven and current speed should also be shown. For other sensors
such as the temperature and light sensor, a scale will be used to visualise the data. A possible
visualisation is shown in figure 4.

Figure 4: Possible visualisation of the sensor data

3.5.3 Show connection status

Number: 5.3
Priority: Required
Description:
The user has to be able to see whether the robot is receiving the commands. If the robot
would move out of range, the controls should be disabled until the robot is within range again.
In figure 4 the status is indicated by the antenna in the bottom right corner. Figure 5 shows
how the user can be informed that the connection isn’t working. This message will stay on
the screen until the connection is restored.

10
 Figure 5: Connecion lost message

3.5.4 Setting trigger values

Number: 5.4
Priority: Desirable
Description:
The user can set his own values which trigger an action. If he wants to be able to drive closer
or stay further away from an object, he can change this value.

3.5.5 Record and playback routes

Number: 5.5
Priority: Optional
Description:
A feature that can be added in the end is recording and playing tracks the robot has made.
The user drives the robot around and while moving, the robot records its movements. When
the user is finished, he can instruct the robot to make the same movements again. The
robot will then move in the same way it did before but but the user doesn’t have to give the
commands.

11
3.5.6 Show battery status
Number: 5.6
Priority: Optional
Description:
If the robots batteries are running low, the user should be warned so that he can replace the
batteries. When the connection is lost, the user can check if the batteries are empty or if there
is some other problem.

12