Académique Documents
Professionnel Documents
Culture Documents
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
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.
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.
1.4 References
[1] Arduino. Arduino. http://www.arduino.cc, 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.
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.
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.
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.
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.
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.
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.
10
Figure 5: Connecion lost message
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