11 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
Project R2D2
DISTRIBUTION
Steering group:
Frank Lüders
Aneta Vulgarakis
Farhang Nemati
Project group:
Vasilis Odontidis VO
Thomas Sörensen TS
Jesper Söderlund JSD
Sreedhar Danturthi SD
Ricky Stanley D’Cruze RD
Quang Tien Le QL
Jesper Simos JS
21 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
CONTENTS
1
2
Introduction .......................................................................................................... 5
1.1
Background ................................................................................................. 5
1.2
Definitions .................................................................................................. 5
1.3
Related Documents ..................................................................................... 5
Functional Description ........................................................................................ 6
2.1
2.2
2.3
2.4
2.5
Use Case Model .......................................................................................... 6
2.1.1
Actors
6
2.1.2
Use Cases
7
Start Robot ................................................................................................ 7
2.2.1
Requirements Reference
7
2.2.2
Participating Actors
7
2.2.3
Related Use Cases
7
2.2.4
Precondition
7
2.2.5
Main Flow of Events
7
2.2.6
Alternative: None
7
Reset Robot................................................................................................ 7
2.3.1
Requirements Reference
7
2.3.2
Participating Actors
8
2.3.3
Related Use Cases
8
2.3.4
Precondition
8
2.3.5
Main Flow of Events
8
2.3.6
Alternative: None
8
Turn off Robot .......................................................................................... 8
2.4.1
Requirements Reference
8
2.4.2
Participating Actors
8
2.4.3
Related Use Cases
8
2.4.4
Precondition
8
2.4.5
Main Flow of Events
8
2.4.6
Alternative: None
9
Provide data .............................................................................................. 9
31 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.6
2.7
2.8
2.9
2.10
2.5.1
Requirements Reference
9
2.5.2
Participating Actors
9
2.5.3
Related Use Cases
9
2.5.4
Precondition
9
2.5.5
Main Flow of Events
9
2.5.6
Alternative: None
9
Get Information ........................................................................................ 9
2.6.1
Requirements Reference
9
2.6.2
Participating Actors
10
2.6.3
Related Use Cases
10
2.6.4
Precondition
10
2.6.5
Main Flow of Events
10
2.6.6
Alternative: None
10
Ultrasonic Task ....................................................................................... 10
2.7.1
Requirements Reference
10
2.7.2
Participating Actors
10
2.7.3
Related Use Cases
10
2.7.4
Precondition
10
2.7.5
Main Flow of Events
11
Reads Sensors .......................................................................................... 11
2.8.1
Requirements Reference
11
2.8.2
Participating Actors
11
2.8.3
Related Use Cases
11
2.8.4
Precondition
11
2.8.5
Main Flow of Events
11
2.8.6
Alternative:
11
Update World View ................................................................................ 12
2.9.1
Requirements Reference
12
2.9.2
Participating Actors
12
2.9.3
Related Use Cases
12
2.9.4
Precondition
12
2.9.5
Main Flow of Events
12
2.9.6
Alternative:
12
Receiver Task .......................................................................................... 12
41 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.11
2.10.1
Requirements Reference
12
2.10.2
Participating Actors
13
2.10.3
Related Use Cases
13
2.10.4
Precondition
13
2.10.5
Main Flow of Events
13
2.10.6
Alternative:
13
Sender Task ............................................................................................. 13
2.11.1
Requirements Reference
13
2.11.2
Participating Actors
13
2.11.3
Related Use Cases
13
2.11.4
Precondition
13
2.11.5
Main Flow of Events
14
2.11.6
Alternative:
14
3
External Interfaces ............................................................................................. 14
4
Software Architecture........................................................................................ 14
5
4.1
Overview and Rationale............................................................................ 14
4.2
System Decomposition ............................................................................. 15
4.3
Hardware/Software Mapping .................................................................... 15
4.4
Persistent Data .......................................................................................... 15
4.5
Access Control .......................................................................................... 15
4.6
Synchronization and Timing ..................................................................... 15
4.7
Start-Up and Shut-Down .......................................................................... 15
4.8
Error Handling .......................................................................................... 15
Detailed Software Design................................................................................... 16
5.1
5.2
Data_Handler ............................................................................................ 17
5.1.1
Static Structure
17
5.1.2
Dynamic Behaviour
18
Kalman_Filter ........................................................................................... 19
5.2.1
5.3
Dynamic Behaviour
19
World_View ............................................................................................. 20
5.3.1
Static Structure
20
5.3.2
Dynamic Behaviour
21
525 )
Group no. 1
Proj. mgr.
22/04/07
CourseOdontidis
CD5360, Software Engineerin
Vasilis
E-mail
Vos06001@student.mdh.se
Date
Design Description
1
Introduction
1.1
Background
This document provides information about project Sensor Fusion, which is also
known as R2D2. The goal of the group is to implement software that will control and
fuse the data provided by sensors embedded in robots. These robots are designed in
the Robotics Laboratory (Robolab) in Mälardalen University with the purpose of
participating in football matches and competing against other robot football teams. In
addition, the group should provide appropriate tests for the software that are going to
be used in further implementations of the robots. The software will be written in ADA
under real-time Linux.
This document is intended for people related with the Robotics Lab and everyone
that wants to have a better insight on the design description of R2D2 project.
1.2
1.3
Definitions
Terms
Definitions
None
None
Document identity
PD
RD
ArosXLS
Document title
Doc/Final Documents/ProjectDesription.doc
Doc/Final Documents/RequirementsDefinition.doc
Doc/Final Documents/Aros_Msg_List_2007.xls
Related Documents
61 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2
Functional Description
2.1
Use Case Model
2.1.1
Actors
1. Command Center is responsible for setting up the robots and provides initial data
of the field.
2. The sensors of the robot provide the external readings they receive to the system
so that they are used for calculating and updating the robot’s and other objects’
position in the field.
3. Strategy is a client of sensor fusion system.
4. Task Manager manages the Ultrasonic, Read Sensor, Update WorldView,
Receiver and Sender tasks.
71 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.1.2
Use Cases
Each use case is described in a separate section in the remainder of this chapter.
2.2
Start Robot
Robot is started by the command center to start playing football.
2.2.1
Requirements Reference
None
2.2.2
Participating Actors
Command Center (Initiator)
2.2.3
Related Use Cases
None
2.2.4
Precondition
Robots are placed in the field.
2.2.5
Main Flow of Events
1. Command Center starts the robot.
x. When robot is reset or turned off
2.2.6
Alternative: None
2.3
Reset Robot
Robot appears to be malfunctioning in the football field and has to be reset.
2.3.1
Requirements Reference
None
81 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.3.2
Participating Actors
Command Center (Initiator)
2.3.3
Related Use Cases
None
2.3.4
Precondition
Robot has to be reset for some reason.
2.3.5
Main Flow of Events
1. Command Center resets the robot.
x. When robot is reset or turned off
2.3.6
Alternative: None
2.4
Turn off Robot
Robot needs to operate no more.
2.4.1
Requirements Reference
None
2.4.2
Participating Actors
Command Center (Initiator)
2.4.3
Related Use Cases
None
2.4.4
Precondition
Robot is up and running.
2.4.5
Main Flow of Events
x. Robot is shut down through the command center.
91 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.4.6
Alternative: None
2.5
Provide data
Robot read data from the sensors
2.5.1
Requirements Reference
R2D2_1.09
2.5.2
Participating Actors
Sensor
Task Manager (Initiator)
2.5.3
Related Use Cases
Reads sensors
2.5.4
Precondition
Robot is up and running.
2.5.5
Main Flow of Events
1. Task Manager asks for data.
2. Data is gathered through the sensors
x. Robot is reset or turned off
2.5.6
Alternative: None
2.6
Get Information
Sensor fusion provides the necessary data to the parts of the software that are
responsible for defensive and attacking strategy.
2.6.1
Requirements Reference
R2D2_1.01 - R2D2_1.06, R2D2_1.09
101 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.6.2
Participating Actors
Strategy (Initiator)
Task Manager
2.6.3
Related Use Cases
Update World View
2.6.4
Precondition
Robot is up and running.
2.6.5
Main Flow of Events
1. Strategy asks for information
2. Strategy gets information from buffer
x. Robot is reset or turned off
2.6.6
Alternative: None
2.7
Ultrasonic Task
Ultrasonic Task is used to find obstacles in a close by area so that the pathfinder could
calculate a way out of the area.
2.7.1
Requirements Reference
R2D2_1.07
2.7.2
Participating Actors
Task Manager (Initiator)
Sensor
2.7.3
Related Use Cases
Read Sensors
2.7.4
Precondition
Robot is up and running.
111 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.7.5
Main Flow of Events
1.
2.
3.
x.
2.8
Task Manager schedule task
Gather information from the 8 ultrasonic sensors.
Update matrix map.
Robot is reset or turned off
Reads Sensors
System reads the data from sensors data and then transforms the data to a more
readable format.
2.8.1
Requirements Reference
R2D2_1.09
2.8.2
Participating Actors
Task Manager (Initiator)
Sensor
2.8.3
Related Use Cases
Provide Data.
2.8.4
Precondition
Robot is up and running.
2.8.5
Main Flow of Events
1. Read from sensors.
2. Update protected Buffer 1
x. Robot is reset or turned off
2.8.6
Alternative:
None.
121 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.9
Update World View
Take the latest data from the buffer, run it through kalman filter and then update the
world view.
2.9.1
Requirements Reference
R2D2_1.07 - R2D2_1.09
2.9.2
Participating Actors
Task Manager (Initiator)
2.9.3
Related Use Cases
Read sensors.
2.9.4
Precondition
Robot is up and running.
2.9.5
Main Flow of Events
1.
2.
3.
4.
x.
2.9.6
Get data from Data handler, Protected Buffer 1
Update kalman filter with latest data
Receive new data from kalman filter
Update World View
Robot is reset or turned off
Alternative:
None.
2.10
Receiver Task
Receiver task takes care of incoming messages and updates the buffer with
information
2.10.1 Requirements Reference
None
131 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.10.2 Participating Actors
Task Manager (Inititator)
2.10.3 Related Use Cases
None
2.10.4 Precondition
Robot is up and running.
2.10.5 Main Flow of Events
1.
2.
3.
x.
Receive message from command center.
Update protected buffer 2
Repeat for every message received
Robot is reset or turned off
2.10.6 Alternative:
None.
2.11
Sender Task
Sender task is responsible for sending Robot and Ball position to command center
which will send it to the rest of the team.
2.11.1 Requirements Reference
None
2.11.2 Participating Actors
Task Manager
2.11.3 Related Use Cases
None
2.11.4 Precondition
Robot is up and running.
141 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
2.11.5 Main Flow of Events
1.
2.
3.
x
Get ball position and Robot position
Update protected buffer 2
Send message
Robot is reset or turned off
2.11.6 Alternative:
None.
3
External Interfaces
Sensor Fusion will provide a world-view interface, so that the other groups can use
the functionality that we provide. The interface provides the functions required to
know the current position and speed of the robots and the ball in the field.
4
4.1
Software Architecture
Overview and Rationale
The software’s architecture includes two tiers. The internal tier includes 3
packages namely data_handler, kalman_filter and world_view which are responsible
for all the internal functions of the software. The external tier is the interface which
provides all the necessary functionality that allows interaction with the software. The
uml design of the architecture is presented in Figure 1.
World View Interface
World
View
Data
Handler
Sensors
Kalman
Filter
151 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
-Figure 1 -
4.2
System Decomposition
Data_Handler: Reads the sensor data and provides more readable data.
Kalman_Filter: Provides the necessary function to the world_view to filter the data
and provide a more accurate result.
World_View: Provides the filtered position of the robots, ball and referee in the field
through its interface.
4.3
Hardware/Software Mapping
Data_handler is responsible for interaction with the hardware. All the needed
references are included in the file ArosXLS.
Task_Manager is responsible for managing the tasks that run inside the Sensor Fusion
software.
4.4
Persistent Data
None
4.5
Access Control
None
4.6
Synchronization and Timing
Sensor Fusion should provide data in real-time with a 0,5 – 1 sec frequency. This is
done through the Task_Manager.
4.7
Start-Up and Shut-Down
Sensor Fusion is a part of software that starts and shuts-down according to the
command center.
4.8
Error Handling
Exceptions will be used to catch erroneous behaviour and react accordingly. Tests will
be written for the code provided so that errors can be identified and removed.
161 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
5
Detailed Software Design
This is the overall design.
171 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
5.1
Data_Handler
Reads the sensor data and provides more readable data.
5.1.1
Static Structure
181 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
5.1.2
Dynamic Behaviour
Data_Handler
Ultrasonic
191 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
5.2
Kalman_Filter
Takes the data from Data_handler and filters them to provide a more accurate
result.Static Structure
5.2.1
Dynamic Behaviour
Kalman filter has no initiator. Its dynamical behaviour can be seen in the world view and task_manager
sequence diagram.
201 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
5.3
World_View
Provides the filtered position of the robots, ball and referee in the field.
5.3.1
Static Structure
211 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
5.3.2
Dynamic Behaviour
World View
Receiver Task
221 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
Sender Task
Strategy World View Interface
REVISION
Rev.
Ind.
v0.1
v0.9
Page (P)
Chapt.(C)
P9,C5
Incomplete version
P12,C5 Beta Version
Description
Date
Initials
07/04/22
07/05/2
231 )
Group
no.
1
Date
1/5/2007
Course CD5360, Software Engine
v1.0
V1.1
V1.1
P15,C5
P14, P15
DesignDescription1.0
Worldview class and detailed software design changed
Section 2 and 5 updated
07/05/7
07/05/8
07/05/31