Preliminary Study

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

November 5, 2010

1 Overview
1.1 Scope
For over 45 years, Moore’s law has stated that approximately every 24 months the number of
transistors in a processor would double[1]. But today it becomes more and more difficult to double
this number every 2 years[2]. This is where multicore processors step in. Instead of adding more
transistors and making them smaller, additional cores are added. The individual cores can each
process one instruction at a time. Combined, multiple instructions can be processed concurrently
resulting in faster processing. These processors now appear in all kinds of devices such as desktop
computers but also in embedded systems.
With this project[3] we will focus on these multicore embedded systems. Usually programming
embedded systems concurrently is difficult due to a collection of complex interrupts that have
to be handled. We will investigate if multicore processors are a solution to this complexity by
implementing a non trivial application, a robot. At the end of the project, we will have shown if
multicore processors have an advantage over interrupts when using an embedded system.
In the following two scenarios, the benefits of a multicore processor will be shown.
The robot could be programmed to drive around on a certain path. If an obstacle would appear on
its path, it could either collide with this object or it could stop and maybe avoid the object.
Using interrupts, it would be a very difficult task to implement this handling with interrupts and
drive around at the same time. Using a multicore processor, one core could be dedicated to driving

1
 Figure 1: R2D2 Robot

around. While an other core would take care of looking out for obstacles and make the robot stop
if an object is detected.
Another scenario in which a multicore processor could make implementing this robot easier is
overriding remote control signals. The robot could be equipped with a remote control that allows
a user to drive it around. This could be potentially dangerous. If the robot contains expensive or
fragile electronics, hitting a wall would be a catastrophe. Therefore, it should be able to override
the commands that are given if the situation requires this.
This also could be made easier using a multicore processor by spreading the tasks. Receiving signals
and driving the robot have to be spread over the different cores that are available.
The goal of this project is building a robot that can handle different external events concurrently.
It will consist of 3 modules, each with a specific task. First there is the visions module. Using a
camera or a distance sensor allows the robot to see its environment and respond accordingly. In
the above scenarios, this sensor provides the robot with the ability to see an object and stop if
necessary. The second module will add remote control abilities to the robot so the user can choose
the path it will follow without programming it into the robot. The user could also see on the
computerscreen what the robot sees. It could show how close an object is in front of the robot. Or
in case a camera is installed, it could show a video feed allowing the user to steer better. The third
module will provide the robot with the ability to move. Actuators will be added to make the robot
respond to the signals received from the remote control module and the visions module. Without
these actuators, the robot wouldn’t be able to move. The visions module wouldn’t be very usefull
as the robot can’t move. The environmental sensors would remain in the same state. So it wouldn’t
be necessary to override commands or check if an object poses a threat to the robot.
The goal of this project is thus to see whether multicore processors make concurrent programming
on an embedded device easier.

2
1.2 Definitions and acronyms
• Datasheet: A document that contains information about a piece of hardware. For example
what pins are input and output, what sequence of bits has to be sent to perform a certain
action, etc.

• Integrated circuit: An electronic circuit that has been minimized to fit inside a microchip.

• Stepper motor: This is a type of motor that takes a step when power is supplied. To make
it spin around, a sequence of pulses must be send. This amount varies from motor to motor.

2 External interfaces
The VUB assistant, Christophe Scholliers (cfscholl@vub.ac.be) can be contacted for questions, de-
tails and meetings about the requirements.
The XMOS support helpdesk (https://www.xmos.com/support/contact) can be contacted if there
are questions related to the embedded device we will be working with.

3 Work plan
3.1 Decomposition of tasks
The project can be divided into 5 major parts.

• Experimenting with the hardware

• Implementing the sensors

• Implementing the actuators

• Creating the client-server program

• Making the connection between the computer and the robot wireless.

The experimenting consists of writing small applications and tests. To achieve a better understand-
ing of the hardware and how it can be combined with the robot. In this phase, the datasheets play
a big role in the understanding of the device.
After a sensor or actuator has been analyzed, it can be integrated with the rest of the robot. This
stage follows immediately from the experimenting phase as test code can be abstracted and reused
in the final implementation of the sensor or actuator.
After all sensors and actuators have been implemented, a client-server program will be implemented.
This program will show the state of all sensors and it will allow the user to control the robots move-
ments.
To set the robot free, the usb connection between the robot and the computer will be replaced by
a wireless connection. There are many possibilities for this connection such as bluetooth, wifi or
zigbee.

3
 Figure 2: Xmos embedded board

All these parts will be combined on an XMOS multicore embedded system[4].

The schematic on how the individual tasks and milestones are related is shown in the PERT chart
(figure 3).

Figure 3: PERT chart

3.2 Schedule
Before any programming can be done, the hardware must be analyzed and tested. After the docu-
mentation has been read and tests performed. The actual implementing can begin. This implemen-
tation will be based on the test code that will be abstracted, cleaned up and documented. Part of
this implementation will already be made in the experimentation phase allowing the experimenting
and implementing phase to overlap.
After the sensors and actuators, the client-server program will be made. To be able to start working
on this program, some sensors or actuators have to be implemented. To finish this task, all of them
must be working.
The last part of the project consists of replacing the usb connection by a wireless connection. This

4
shouldn’t provide many problems as the wireless module encodes and decodes the data itself.
During all tasks, work will be done on the next document or presentation that has to be delivered.
Closer to the deadline, work on the task will slow down and more work will be done for the deliv-
erable.
Figure 4 shows the Gantt chart for this project. It contains the 3 categories of tasks, the project
itself and the 2 deliverables, documents and presentations. Red rectangles indicate tasks on the
critical path of the PERT chart. These cannot be delayed if the project has to be finished on time.

Figure 4: Gantt chart

3.3 Risk management

3.3.1 Incomplete or unclear datasheets
Description: Without a clear datasheet it is very difficult to use a sensor or actuator. There are
many in- or output pins available on a device, when an incorrect signal is applied to a certain pin,
it could break internal circuits.
Probability: Likely.
Minimization: Check for the availability of a datasheet before purchase.
Solution: Searching the web for a similar device that has a better datasheet.

3.3.2 Failing hardware

Description: Hardware could break down at any time due to incorrect use or production errors.
Probability: Unlikely.
Minimization: Reading datasheets carefully.
Solution: Adjust the planning so the necessary parts can be replaced and work will be done on

5
another part of the project.

3.3.3 Unknown programming language

Description: Using a programming language that is unknown to the developer
Probability: Likely.
Minimization: Do research if an other language can be used.
Solution: Experiment and read tutorials about the programming language in order to become
familiar with the language.

3.3.4 Vague requirements

Description: One or more requirements are too vague.
Probability: Unlikely
Minimization: Read background material on the subject
Solution: Ask for enough information when the requirements are specified

3.3.5 Complexity is too high

Description: The complexity of one or more of the requirements is too high.
Probability: Likely.
Minimization: Analyze the requirements thoroughly.
Solution: Break the affected requirements down in smaller pieces of lower complexity.

4 Control plans
4.1 Requirements control plan
The requirements will be divided into categories which are numbered. These categories represent
the different parts in the project. All the individual requirements will have 2 numbers, the first one
indicates the category, the second one is an index number.
New requirements or changes to existing requirements are always first discussed with the assistant
for the project. If they are approved, the planning will adjusted, the design and risks will also be
checked with this new requirement and if necessary updated.
When new requirements are added, they will be added to the correct category and they will be
given the next index number.

4.2 Schedule control plan

After completing a milestone, that corresponds to a task in the implementation category on the
Gantt chart, the planning will be evaluated with the assistant and if necessary updated. These

6
changes will be made to the Gantt chart. Every version Gantt chart is available under an online
repository.
After each milestone, the Gantt chart will be updated with the progress that has been made to the
individual tasks.

4.3 Reporting plan

Every week, a progress meeting is planned with the assistant. During this meeting, that weeks
progress will be discussed and issues will be addressed. The work for next week will also be
determined with corresponding problems or points of interest.
The required documents will be delivered by email for review at least one week before the deadline.

References
[1] Gordon E. Moore. Cramming more components onto integrated circuits. ftp:
//download.intel.com/museum/Moores_Law/Articles-Press_Releases/Gordon_Moore_
1965_Article.pdf, April 1965.

[2] BBC. Moore’s law on chips marks 40th. http://news.bbc.co.uk/2/hi/technology/4446285.

stm, April 2005.

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

ProjectProposal.html, October 2010.

[4] XMOS. XC-1A hardware manual. https://www.xmos.com/download/public/

XM-000192-HM-1.pdf, April 2010.