Project Plan
Remotely Operated Underwater Vehicle
Version 1.5
Author: Niklas Sundholm
Date: December 19, 2016
R V
Status
Reviewed
Approved
Isak Wiberg
Isak Nielsen
2016-11-14
2016-11-15
Project Identity
Group E-mail:
[email protected]
Homepage:
www.isy.liu.se/edu/projekt/tsrt10/2016/rov/
Client:
Isak Nielsen, Linköping University
Phone: +46 13 28 28 04 , E-mail: [email protected]
Customer:
Rikard Hagman, Combine Control Systems AB
Phone: +46 72 964 70 59 , E-mail: [email protected]
Contact at SAAB:
Nicklas Johansson, SAAB Dynamics AB
Phone: +46 13 18 63 65 , E-mail: [email protected]
Course Responsible:
Daniel Axehill, Linköping University
Phone: +46 13 28 40 42 , E-mail: [email protected]
Project Manager:
Isak Wiberg
Phone: +46 73 542 49 59 , E-mail: [email protected]
Advisors:
Kristoffer Bergman, Linköping University
Phone: +46 73 847 31 51 , E-mail: [email protected]
Group Members
Name
Responsibility
Phone
Elin Karlström
Klas Lindsten
Fredrik Ljungberg
Erik Sköld
Niklas Sundholm
Isak Wiberg
Filip Östman
Tests
Hardware
Simulation
Software
Documentation
Project manager
Design
+46
+46
+46
+46
+46
+46
+46
76
76
73
73
70
73
72
233
248
051
905
981
542
203
06
66
48
43
68
49
33
32
69
95
43
87
59
07
E-mail
(@student.liu.se)
elika149
klali296
frelj431
erisk214
niksu379
isawi527
filos433
Document History
Version
0.1
0.2
1.0
1.1
Date
2016-09-14
2016-09-19
2016-09-20
2016-10-10
1.2
2016-10-17
1.3
2016-10-27
1.4
1.5
2016-11-02
2016-11-14
Changes made
First draft.
First revision.
First version.
Second version. Project development phase started.
Removed some small GUI activities. Corrected time spent
on activities based on an error
in the time plan.
Removed visualization activities and milestones. Added
some activities regarding telegraph signal generation. Sadly,
two milestones also had to be
moved forward one week in
time.
Updated times for activities.
Updated times for activities.
Merged a number of activities for the control system. Removed BP4.
Sign
Reviewer(s)
NS
IW
IW
NS
IW
IW
IW
IW
IW
IW
IW
IW
IW
IW
Contents
1 Client
2
2 Introduction
2
3 Project Description
2
3.1
Purpose and Goal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3.2
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3.3
Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4 Project Phases
3
4.1
Before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4.2
During . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4.3
After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
5 Organization
4
5.1
Organization Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5.2
Definition of Project Member Roles and Responsibilities . . . . . . . . . . . . . . . . . . .
4
6 Document Plan
5
7 Development Methodology
7
8 Education Plan
7
8.1
Education of the Project Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8.2
Education of the Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
9 Report Plan
7
10 Meeting Plan
7
11 Resource Plan
8
11.1 Project Group
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
11.2 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
11.3 Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
11.4 Economy
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12 Milestones and Decision Points
9
12.1 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
12.2 Decision Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
13 Activities
11
13.1 General Activities During the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
13.2 Hardware Activities
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
13.3 Sensor Fusion Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13.4 Control System Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
13.5 Simulation and Modelling Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
13.6 Visualization Activities
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
13.7 Graphical User Interface Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
13.8 Administration Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
13.9 Documentation Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
14 Time Plan
21
15 Change Plan
21
16 Quality Plan
21
16.1 Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
16.2 Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
17 Risk Analysis
22
17.1 Indispensable Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.2 Hardware Malfunctions
22
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
17.3 Illness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
18 Priorities
22
19 Project Ending
22
R V
Remotely Operated Underwater Vehicle
Project Plan
Notations
GCS Global Coordinate System.
GUI Graphical User Interface.
HWIL Hardware in the Loop.
LCS Local Coordinate System.
MCS Marker Coordinate System.
PCS Pool Coordinate System.
ROS Robot Operating System.
ROV Remotely Operated Underwater Vehicle.
XBOX Video game console built by Microsoft.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
1
Remotely Operated Underwater Vehicle
Project Plan
R V
1
2
Client
The client is Isak Nielsen from the department of Electrical Engineering (ISY) at Linköping
University (LiU). The customer is Rikard Hagman from Combine Control Systems AB.
Saab Dynamics will contribute with competence via Kristoffer Bergman (ISY/Saab Dynamics) and diving possibilities through Nicklas Johansson (Saab Dynamics).
2
Introduction
In both civilian and military applications there is an increasing interest and need for
autonomous vehicles that can carry out missions at sea, in the air and on land without
contact with an operator. Examples of tasks are surveillance, rescue operations, surveying, mapping, repairs or tactical missions.
The purpose of this document is to specify what deliveries the project will contain and
to state the planed project activities. The document also contains details regarding
which responsibilities each group member has and in which activities each group member are involved in. A risk analysis and a quality plan has been established as well.
3
Project Description
During the spring of 2016, a MSc project[1] was carried out where a remotely operated
underwater vehicle (ROV) was assembled and tested. A thorough modelling of the ROV
and a basic control system was implemented during that project. This project will directly continue on their work and improve the system further.
The result of this project will be used for further development of the ROV.
3.1
Purpose and Goal
The purpose of this project is to develop a robust control system, a simulation environment for speeding up the development process, improve the existing model of the ROV
and introduce a positioning system that should work in a swimming pool. The findings from this project can be used in future development projects to further develop the
ROV.
The long term goal is to develop the ROV to become a fully autonomous under water
vehicle that can perform different types of missions on its own. The ROV will also be
used by Combine Control Systems AB for demonstration purposes.
3.2
Delivery
All documents and functionalities that are listed in the requirements specification should
be completed and ready for delivery, to the customer Rikard Hagman, by the end of this
project. Preliminary date for delivery is set to 2016-12-05. A technical report, poster,
web page and movie of the product will be delivered 2016-12-19.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Remotely Operated Underwater Vehicle
Project Plan
R V
3.3
3
Exclusions
The system currently under development is aimed as a test bed and demonstration tool
and is designed for use in a pool. The performance requirements are thus set for use
in a pool under good conditions, i.e. calm water with clear visibility. The ROV is not
expected to fulfil the performance requirements in turbulent water environments with
high disturbances and limited visibility.
4
Project Phases
This project follows the LIPS-model, which means that it is divided into three phases: a
before, a during and an after phase.
4.1
Before
In the before phase the plans for the project will be formed. This means that various
tasks and demands will be defined in a requirement specification document and a system overview (document) will be produced to describe how the system will be constructed to satisfy the requirements. Activities will be planned and evaluated based
on time and resources, and the plans for the execution of the project will be collected
in a project plan. The work will be divided between group members and the different
roles in the project are determined. The client decides if the before phase is approved at
BP2.
4.2
During
During the project the various activities are executed, documented and tested. In this
phase, the design of the ROV will be determined and collected into a design specification. How and when different tests are to be carried out will be described in a test plan.
The ROV is developed based on these two documents, and it will continuously be documented in a technical report. Communication with the client will be made with continuous meetings and status updates. The product will be delivered to the customer and
presented with a poster, a video and a web page.
4.3
After
A technical report, poster, web page and movie of the product will be compiled and delivered to the customer. When the items listed above are finished a post study and reflection document will be done. The material will be returned and the project group
dissolved.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
R V
5
Remotely Operated Underwater Vehicle
Project Plan
4
Organization
This section describes the organization structure of the project and defines the different
project member roles and their responsibilities.
5.1
Organization Structure
Figure 1 shows how the participants in the project are related. The project group will
be divided into teams that will focus on different components of the system. Each team
has one person who is responsible for that component. The person responsible for design coordinates the managers for each team during this work. It is important to highlight that the project members might work on multiple components even though they
have a role assigned to them. The project roles are presented and further explained in
the next section.
Figure 1: Relation between different participants in the project.
5.2
Definition of Project Member Roles and Responsibilities
The project roles and their main responsibilities are described below.
Project manager: Leads the project and plans the work. Responsible for making sure
that the project reaches its goals. Encourages and motivates the project group.
Document manager: Plans the writing and verification of documents. Responsible
for creating and delivering documents. Creates document templates and is responsible for versioning of documents.
Test manager: Plans and syncronizes tests. Responsible for the test plan and test
protocol. Makes sure that the requirements are fulfilled.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
R V
Remotely Operated Underwater Vehicle
Project Plan
5
Design manager: Responsible for creating guidelines for the technical design of the
product and coordinates the component managers towards fulfilling the requirement specification. This includes ensuring that the component teams are working
towards the same goals.
Software manager: Makes sure that the coding standard is followed, the code is well
structured and versioned as well as documented.
Hardware manager: Responsible for battery charging, pool condition and hardware
issues.
Simulation manager: Responsible for the models created and the simulator and HWIL
environment.
Component manager: Critical components/modules in the product could get a component manager assigned. This person is then responsible for coordinating the
work on this component.
6
Document Plan
Table 1 lists the documents and media that will be delivered during the project. Each
document/media has a short description, target audience and a delivery date. The delivery date for a document/media might be subject to change if its corresponding requirements are changed. All documents that will be distributed outside of the group
will be written in formal English, except for the meeting protocols that will be written
in Swedish. All group members will have access to the documents through Google Drive
and ShareLaTeX. When a document is delivered it will also be saved to the project
groups Google Drive in order to keep track of all document versions. When documents
are delivered or updated they will also be uploaded to the project groups GitLab repository.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Remotely Operated Underwater Vehicle
Project Plan
R V
6
Table 1: Requirements regarding documentation during the project.
Document
Group contract
Requirement
specification
Responsible
NS
System
overview
NS
A brief technical overview of the system.
Project and
time plan
IW
Design specification
NS
A time plan with the activities of the
project which also specifies which
group members that are involved in
each activity.
A detailed technical description of the
system and its interfaces.
Test plan
EK
Test protocol
EK
User manual
NS
Poster
NS
Technical
report
NS
Post study
and reflections
Web page
NS
Video presentation
NS
Meeting protocols
NS
NS
NS
Description
A contract stating the terms of the
execution of the project.
Specifies the requirements for the
project and the product.
Describes how the fulfillment of each
of the project requirements shall be
tested and verified.
A protocol of all the performed tests
and their results.
A manual describing how to operate
the ROV.
An appealing description of the
project and the ROV.
A report describing the project from a
technical point of view, i.e. describing
all integrated systems of the ROV and
the simulator.
A document reflecting on the execution of the project.
A web page where the project is presented and where project documents
are accessible.
Present the project and the ROV in a
video that also markets the education
at LiU.
Protocol from the weekly meeting held
throughout the project.
Target audience
Project group.
Date
2016-09-06
Project group,
Customer and
Client.
Project group,
Supervisor and
Client.
Project group and
Client.
2016-09-20
Project group,
Supervisor and
Client.
Project group,
Supervisor and
Client.
Project group,
Supervisor and
Client.
Customer and
Client.
Customer and general public.
Project group,
Supervisor and
Client.
2016-10-04
Examiner.
2016-12-19
Supervisor, Customer and general
public.
Supervisor, Customer and general
public.
Project group and
Client.
2016-12-19
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
2016-09-20
2016-09-20
2016-10-04
2016-11-30
2016-11-30
2016-12-12
2016-12-19
2016-12-19
Weekly
R V
7
Remotely Operated Underwater Vehicle
Project Plan
7
Development Methodology
The project is one part of a series of projects with the aim of, step by step, developing
a totally autonomous underwater vehicle which can carry out different tasks by itself.
The ROV is module based and needs to remain so for further development. The objective for each module needs to be clear and the communication between modules well
defined. To make sure that newly developed functionalities are robust tests will be performed and documented continuously through out the project.
8
Education Plan
All project members and the customer will require education during different phases of
the project. The project members will mostly need education in the early phases of the
project and the customer in the later stages when the project is done.
8.1
Education of the Project Members
For the project to progress well and avoid unnecessary errors it is essential that all project
members have read through the MSc project [1]. All project members will be given a
demonstration of the ROV to get a better feeling for the system and see what work has
been done so far.
8.2
Education of the Customer
The customer will be trained in operating the ROV during a demonstration at the final
delivery of the product. A user manual and documentation of the product will be delivered where all the details of the implemented functionalities and handling of the ROV
are described.
9
Report Plan
A time plan for the project will be established. Each project member will report their
working time every week. The project manager will update the time and project plan
based on the project progress.
Each week a status report will be sent to the client. This status report will summarise
the project progress during the previous week as well as problems encountered and
solved.
10
Meeting Plan
The project group will have meetings in the beginning of every week, preferably on
Mondays 13.15 - 14.00. The time for the next meeting will be decided during the meeting. The project manager or the person responsible for the meeting summons the project
group to the weekly meetings. The meeting protocols will be written in Swedish. The
client will attend the weekly meetings every second week and have a point on the agenda
for discussion with the project group.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Remotely Operated Underwater Vehicle
Project Plan
R V
11
Resource Plan
This section states the available resources for the project in terms of work time, material, facilities and economy. It is important to follow the resource plan in a project to
avoid conflicts with the customer and unexpected costs.
11.1
Project Group
The project will be performed by seven students at Linköping University, where each
student holds a BSc. The students in the project group will contribute with 240 hours
each, resulting in a total of 1680 hours. The project group will have access to 40 hours
of technical counselling from a supervisor at LiU/Saab Dynamics.
11.2
Material
Available material for the project includes the ROV from Blue Robotics and a PC running Linux as a workstation.
11.3
Facilities
The project group will have access to a project room, a small pool at the university for
tests and the possibility to visit a large pool at least three times during the project.
11.4
Economy
Necessary purchases, such as new hardware, will be discussed with the customer at
Combine Control Systems AB. All confirmed purchases are covered by the customer.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
8
Remotely Operated Underwater Vehicle
Project Plan
R V
12
9
Milestones and Decision Points
This section contains descriptions of milestones used to measure project progress. It
also contains a description of the project decision points.
12.1
Milestones
The milestones are intended to highlight events of high importance to the project progress.
M stands for Milestone.
Table 2: Milestones.
No
M1.
M2.
M3.
M4.
M5.
M6.
M7.
M8.
M9.
M10.
M11.
M12.
Description
First dive.
Camera hardware integrated, calibrated and tested.
Control strategy proposition finished.
The ROV can position itself in a pool oriented coordinate system.
Velocity estimates are calculated in real time in a
pool oriented coordinate system.
There exists HWIL functionality in the ROV.
Send ROS-topics with simulated data back to the
ROV.
All controllers are implemented.
The model is extended and new parameter values
have been estimated.
3D visualization of the ROV’s orientation in Matlab/Simulink.
All controllers are tuned and tested.
Ability to receive ROS-topics in Simulink, simulate
and visualize the result.
Date
2016-09-26
2016-10-14
2016-10-19
2016-10-21
2016-10-21
Removed
Removed
2016-11-11
2016-11-16
Removed
2016-11-23
Removed
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
R V
12.2
Remotely Operated Underwater Vehicle
Project Plan
10
Decision Points
Table 3 lists the decision points during the project. If a decision point is approved by
the client the project can proceed. BP (Beslutspunkt in swedish) stands for Decision
Point.
Table 3: Project decision points.
Decision
BP2.
BP3.
BP4.
BP5.
Delivery.
BP6.
Description
Requirements specification, system overview,
project plan and time plan shall be approved by
the client.
Design specification and test plan shall be approved
by the client.
The requirements on the simulation environment
shall be fulfilled and the relevant parts from the
test protocol shall be finished.
All requirements marked with priority one shall be
satisfied. User manual, test protocol and the presentation shall be approved by the client. Decision
about delivery takes place.
Project delivery to customer and a presentation to
demonstrate that the requirements are fulfilled.
The technical report, poster, presentation film and
web page shall be approved by the client and delivered. A reflection with a follow-up of result and
used time shall be finished.
Date
2016-09-20
2016-10-04
Removed
2016-11-30
Preliminary
2016-12-07
2016-12-19
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Remotely Operated Underwater Vehicle
Project Plan
R V
13
11
Activities
This section lists all activities together with a description, estimated time for the activity and the people responsible for performing the activity. Resources in terms of time
and persons will most certainly be changed during the project and the time plan and
project plan will be changed accordingly. The estimated time for each activity will be
given in hours (h). Activities that have been removed from the plan has been marked
with – in the estimated time column for that specific activity.
13.1
General Activities During the Project
The activities listed in Table 4 will be performed on a weekly basis during the entire
project. G stands for General.
Table 4: Continuous activities regarding all phases.
No
G1.
G2.
G3.
G4.
Activity
Setup a code documentation system.
Check portability
of existing software.
Make positioning
tags.
Lectures.
Description
Write comments in code in doxygen style in order
to create a structured code.
Examine the source code, overall structure and dependencies of the software previously used with the
ROV.
The positioning system based on vision uses numbered tags consisting of patterns in black-and-white
to setup a coordinate system. These tags need to
be printed and laminated.
During the project course, a series of lectures will
be given. Part of the project includes attending
these.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Time
10
4
3
28
Remotely Operated Underwater Vehicle
Project Plan
R V
13.2
12
Hardware Activities
Table 6 lists activities related to hardware.
Table 5: Activities related to hardware.
No
H1.
Activity
Plan and evaluate
possible camera
solutions.
H2.
Check current
hardware
H3.
Fixate camera.
H4.
Method to calibrate camera.
Create a test case
for camera calibration.
Integrate new camera.
H5.
H6.
Description
Determine if the Raspicam is appropriate for our
positioning problem or if we need more cameras.
Estimate if the processing power in the Raspberry
Pi 2 is sufficient to facilitate a USB-camera. Plan
component purchases.
Inspection of hardware to evaluate its current status. Repair or replace broken cables, connections,
parts etc.
An examination of the system hardware found the
camera to be slightly loose. It needs to be properly
fastened.
Find a method for camera calibration.
Time
6
The test case should ensure that the camera is
properly calibrated for the underwater environment
and lens properties.
Integrate the new Raspicam 2. This has as of week
42 proven to be more troublesome than estimated.
2
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
–
6
6
20
R V
13.3
Remotely Operated Underwater Vehicle
Project Plan
13
Sensor Fusion Activities
Table 6 lists activities related to sensor fusion. SF stands for Sensor Fusion. In activity
SF4, names for different coordinate systems are mentioned. These stand for: Marker
Coordinate System (MCS), Pool Coordinate System (PCS), Global Coordinate System
(GCS) and Local Coordinate System (LCS). These are discussed further in the system
overview [2] and the design specification [3].
Table 6: Activities regarding sensor fusion.
No
Activity
Description
SF1.
Evaluation of existing sensor fusion
module.
Vision based position and orientation estimates.
Implement a motion model estimate in the marker
coordinate system.
Alignment of coordinate systems.
Fusion of yaw estimates from vision
with current yaw
measurements.
Investigate position estimate quality.
Test sensor fusion
module.
Verify that all sensor fusion module
requirements are
fulfilled.
Separate sensor fusion EKF into two
separate filters.
Understand existing sensor fusion module. What
are the current estimates produced by it and how is
it done etc.
Setup the ROS package aruco mapping to give position and orientation estimates in the MCS.
SF2.
SF3.
SF4.
SF5.
SF6.
SF7.
SF8.
SF9.
Time
(h)
16
45
The motion model and the position estimates are
used to get estimates for linear velocities and orientation.
87
Estimate rotational transforms from MCS to PCS
and PCS to GCS.
Improve current yaw estimates with additional data
from vision system.
40
Perform test to determine the performance of the
vision based positioning system and document it.
1
Perform tests to validate the sensor fusion module
against the requirements specification.
Verify that the control module fulfils the requirements specified in the requirement specification.
40
Separate position- and velocity estimates into one
EKF since they depend on position measurements.
The other part of the filter should contain orientation states and possibly use orientation measurements to reduce covariance of states.
46
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
4
6
R V
13.4
Remotely Operated Underwater Vehicle
Project Plan
14
Control System Activities
Table 7 and Table 8 lists activities related to the control system of the ROV. C stands
for Control.
Table 7: Activities regarding control. (1/2)
No
C1.
C2.
C3.
C4.
C5.
C6.
C7.
C8.
C9.
C10.
Activity
Research of control
methods.
Proposition for
control strategy.
Read, comment
and restructure
current code to
suit new implementations.
Implementation of
combined velocity
controller.
Evaluation of angular velocity control.
Evaluation of linear velocity control.
Implementation
of depth velocity
controller.
Evaluation of
depth velocity control.
Implementation
of position and
attitude controller.
Evaluation of attitude control.
C11.
Evaluation of positional control.
C12.
Integration of control methods.
C13.
Evaluation of integrated control.
Description
Research of control methods and principles used in
similar projects.
Propose a control strategy which allows for control
of the ROV in accordance with the functionality
requirements specified in the requirements specification document.
Read, comment and restructure current code to
suit new implementations. Adapt existing code to
code documentation system.
Time
33
Implement a combined velocity controller based on
the control strategy proposition.
30
Simulation and real world tests to compare angular
velocity control performance to the demands specified in the requirements specification document.
Simulation and real world tests to compare linear
velocity control performance to the demands specified in the requirements specification document.
Implement a depth velocity controller based on the
control strategy proposition.
5
Simulation and real world tests to compare depth
velocity control performance to the demands specified in the requirements specification document.
Implement a controller for the ROV’s position and
attitude based on the control strategy proposition.
–
Simulation and real world tests to compare attitude
control performance to the demands specified in
the requirements specification document.
Simulation and real world tests to compare positional control performance to the demands specified
in the requirements specification document.
Integrate the developed controllers in an overall
structure to enable control of multiple states simultaneously. Establish and implement control modes
including the combinations of reference signals for
each control mode.
Tests need to be performed in order to determine if
the implemented control modes are appropriate for
an operator.
–
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
40
31
5
12
–
–
30
40
Remotely Operated Underwater Vehicle
Project Plan
R V
15
Table 8: Activities regarding control. (2/2)
No
C14.
C15.
C16.
C17.
C18.
C19.
Activity
Verify that all
control-related
requirements are
fulfilled.
Telegraph signal
generation.
Test system dynamics from telegraph signals.
Finalize implementation of controllers.
Implementation of
controllers in the
simulator.
Evaluation and
testing of controllers.
Description
Verify that the control module fulfils the requirements specified in the requirement specification.
Time
8
Investigate suitable control signals for parameter
estimation. Implement a ROS-node that sends
these control signals. Implement a script for performing a parameter test.
Test how the ROV responds to the telegraph signals in the small pool.
58
Add parameters to dynamic reconfigure and integrate the controllers.
10
Implement all controllers in simulink.
20
Test controllers with and without exact linearization active.
60
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
10
R V
13.5
Remotely Operated Underwater Vehicle
Project Plan
16
Simulation and Modelling Activities
Table 9 lists activities related to the simulation and modelling of the ROV. S stands for
Simulation.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Remotely Operated Underwater Vehicle
Project Plan
R V
17
Table 9: Activities regarding simulation and modelling.
No
S1.
Activity
Plan tests for linear velocities.
S2.
Clean up and
structure Simulink
environment
Real-time Simulink
functionality
S3.
S4.
S5.
S6.
S7.
S8.
S9.
XBOX controller
as real-time
Simulink input
Hardware-in-theloop mode for
ROS.
Simulink - ROS
interface.
Introduce linear
velocities in simulation model.
Identification experiment with
added linear velocities.
Update model with
new parameters.
S10.
Model validation.
S11.
Verify that all
simulator requirements are fulfilled.
HWIL ROS node
generation from
Simulink.
Parameter estimation using EKF
filter.
S12.
S13.
Description
The existing model needs extension with linear velocities. With a way to estimate linear velocities,
the model then needs identification of parameters. To accomplish this, appropriate tests must
be planned and later undertaken to gather data for
parameter identification.
The existing Simulink files are not so well structured. Update names of files and/or folders to ease
navigating among them.
Implement functionality to run a Simulink simulation in real-time, with features to read input during
runtime.
Implement functionality to input signals to
Simulink in real-time using an XBOX controller.
Time
4
This mode should disable the physical thrusters
and instead send the control signals to Simulink
using the interface developed in activity S3. The
sensor fusion module should also be disabled, and
state estimates should be received from the simulation environment in Simulink.
Create, implement and test an interface for communication between Simulink and ROS.
Add the linear velocity states to the simulation
model.
9
Perform an experiment to gather data for estimation and validation of the model parameters with
added linear velocities.
55
Use the data gathered in the identification experiment to find the values of the model parameters.
Update the simulation model with new parameter
values.
Use the data gathered to validate the model with
updated parameters.
Verify that the simulation module fulfils the requirements specified in the requirement specification. Prepare plots showing model fit.
C code generation from Simulink.
37
Implement parameter estimation filters in Matlab.
20
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
31
20
–
15
24
35
4
10
R V
13.6
Remotely Operated Underwater Vehicle
Project Plan
18
Visualization Activities
Table 10 lists activities related to the visualization of the ROV. V stands for Visualization. All visualization activities were removed in version 1.3 of this document after the
requirements regarding visualization of the ROV were removed.
Table 10: Activities regarding visualization.
No
V1.
V2.
V3.
V4.
Activity
Create a visualization module interface.
3D visualization
of attitude and
velocity.
Establish Simulink
- Visualization interface.
Verify that all visualization requrements are fulfilled.
Description
Create a specification for the interface with the visualization module.
Time
–
Use the state estimates to create a 3D visualization
of the ROV’s attitude and velocity vector.
–
Implement support for communication between the
simulation environment and the visualization module.
Verify that the visualization module fulfils the requirements specified in the requirement specification.
–
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
–
R V
13.7
Remotely Operated Underwater Vehicle
Project Plan
19
Graphical User Interface Activities
Table 11 lists activities related to the graphical user interface. GUI stands for Graphical
User Interface. During the MSc thesis project a GUI for the ROV was implemented,
and we will improve and add functionality to that GUI.
Table 11: Activities regarding the Graphical User Interface
No
GUI1.
GUI2.
Activity
GUI windows.
Display useful signals
GUI3.
Display and modify filter settings.
GUI4.
Control mode selection.
Real time control
of control signals.
Real time control
of reference signals.
File format specification.
Load and use preprogrammed control and reference
signals.
XBOX control signal input
XBOX reference
signal input
Input mode selection
Graphical representation
Verify that all requirements for the
GUI are fulfilled.
GUI5.
GUI6.
GUI7.
GUI8.
GUI9.
GUI10.
GUI11.
GUI12.
GUI13.
Description
Improve the window structure of the GUI.
Add fields and plots displaying values of control
signals, measurement signals, reference signals and
state estimates.
Add fields to display and modify measurement and
process noise covariances, then publish to control
and sensor fusion modules.
Add selection buttons to switch between open loop
control (no controller) and closed loop control.
Add functionality to change the control signals in
real time in the GUI.
Add functionality to change the reference signals in
real time in the GUI.
Create a file format specification (.csv) for preprogrammed control/reference signals.
Add functionality to import a preprogrammed set
of control and reference signals.
Time
–
–
Implement functionality to input control signals
with an XBOX-controller.
Implement functionality to input reference signals
with an XBOX-controller.
Add selection buttons to switch between text input, preprogrammed and XBOX mode.
Graphical representation of ROV position and orientation.
Verify that the GUI module fulfils the requirements
specified in the requirement specification.
4
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
–
4
–
–
–
–
4
2
–
2
Remotely Operated Underwater Vehicle
Project Plan
R V
13.8
20
Administration Activities
Table 12 lists activities related to Administration. A stands for Administration.
Table 12: Activities regarding administration
No
A1.
A2.
13.9
Activity
Weekly meetings.
Compile status
reports.
Description
Weekly meetings with the project group.
Summarize the work that has been done and update time plan.
Time
102
10
Documentation Activities
Table 13 lists activities related to the documentation. D stands for Documentation. Table 13 lists activities related to documentation.
Table 13: Activities regarding the documentation.
No
D1.
Activity
Web page.
D2.
D3.
D4.
Project plan.
System overview.
Design specification.
Test plan.
Test protocol.
Requirements specification.
Media for presentation.
Continuous technical documentation.
Finalize technical
documentation.
Post study and
reflections.
Create presentation poster.
Prepare final presentation.
D5.
D6.
D7.
D8.
D9.
D10.
D11.
D12.
D13.
Description
Create a web page with information and documents
related to the project.
Write project plan.
Write system overview.
Plan and write design specification.
Time
5
Plan and write test plan.
Write test protocol.
Write requirement specification.
35
12
130
Record a video of the project and upload on
Youtube.
Document the work and results of the project.
20
Complete the technical documentation, such as the
technical report.
Post study and reflections to evaluate the project.
100
Create a poster to help present the ROV at the
final presentation.
Prepare final presentation.
10
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
113
76
95
20
10
15
Remotely Operated Underwater Vehicle
Project Plan
R V
14
21
Time Plan
The different tasks that needs to be achieved during the project can roughly be divided
into the following:
General activities Contains activities not connected to a specific group.
Hardware Contains hardware-related activities.
Sensor fusion Contains activities related to vision based positioning and sensor fusion.
Control system Contains activities related to research, implementation and evaluation of control systems.
Simulation and modelling Contains activities related to software simulation and
HWIL simulation as well as modelling of the ROV.
Visualization Contains activities related to 3D-visualization of the ROV in its environment.
GUI Contains activities related to the development of the GUI.
Administration Contains the activities Weekly meetings and Compile status reports.
Documentation Contains activities related to document writing and preparation of
presentations.
These tasks are then divided into the activities given in Section 13 which are easier to
estimate how time consuming each task is. There is a separate document named Time
Plan that plans for when the above mentioned tasks will be executed. The time plan
for the project will be updated regularly as the project proceeds. The time plan also
includes information about the persons responsible for each activity. This implies that
they will work with the activity, but other project members could participate in the activity as well.
15
Change Plan
In the case of changing requirements of the ROV’s functionality, the project group need
to motivate to the customer and client why the requirement shall be changed and what
it shall be changed to. Both the customer, the client and the project group need to
agree upon the new requirements. Then the requirement specification, the project plan
and the time plan shall be updated.
16
Quality Plan
This section describes how the project group will work to ensure the quality of the delivered product.
16.1
Audits
Documents produced during the project should be reviewed by at least two people to
reduce the risk of errors.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Remotely Operated Underwater Vehicle
Project Plan
R V
16.2
22
Test Plan
The test plan will contain detailed information about when and how system tests will
be carried out. Each test should be constructed in a way that makes it easy to deduce if
a certain system requirement is satisfied after the test is done.
17
Risk Analysis
Various events that might impact the progress of the project have been identified and
summarised in a short analysis.
17.1
Indispensable Activities
The ongoing plan is to use images together with a camera to estimate world space position and orientation. The project in its current form is quite dependant on this solution. If this idea proves to be hard to implement it will probably be very hard to measure linear velocities. Without good estimates of positions and linear velocities it will in
turn be hard to realize other activities, such as improved controlling.
17.2
Hardware Malfunctions
It is always a possibility that hardware malfunctions. In case that should happen it is
good if the damaged part can be replaced with something that is in stock. If new parts
must be ordered the delivery wait time might delay the progress of the project.
17.3
Illness
Another thing that is always a risk is people getting ill. If the illness sustains for a major part of the project, a meeting for renegotiation of the project requirements will be
held. To minimise the risk of minor colds holding up the progress of the project, most
activities are carried out by at least two people.
18
Priorities
The project groups priority is to develop robust functionality that easily can be used
or further developed by future project groups. In the event of a project delay, negotiations should be held with the client to possibly post-pone the delivery date or remove a
certain requirement.
19
Project Ending
The project will end when the client and customer have received and approved all the
project deliverables and the examiner has received the project groups post study and
reflections. At the end of the project all resources such as PC:s, ROV and project group
room should be handed back. Documentation will be available at the projects web page
after the project is finished.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]
Remotely Operated Underwater Vehicle
Project Plan
R V
23
References
[1]
Adam Aili and Erik Ekelund. “Model-Based Design, Development and Control of
an Underwater Vehicle”. MSc Thesis. Sweden: Linköping University, 2016.
[2]
Niklas Sundholm. System Overview, Remotely Operated Underwater Vehicle. 2016.
[3]
Niklas Sundholm. Design Specification, Remotely Operated Underwater Vehicle.
2016.
TSRT10 Automatic control - Project course, Linköping University
Document responsible: Niklas Sundholm, [email protected]