1 \section{Development Plan \& Evaluation
}
2 \subsection{Development Plan
}
3 The development plan is written following the spiral software development model
4 in which all requirements are divided into small iterations. Each of the
5 iterations will have an implementation phase, a testing phase, an analysis
6 phase, and a design phase. Furthermore, each of the iterations will have goals
7 and results. The iterations and their deliverables are listed in
8 \autoref{tab:devit
}. The schedule for finishing iterations are listed in
9 \autoref{tab:deadli
}. On the
6th of January the must-have should be finished
10 and if they are we try to complete as many iterations as possible.
13 \begin{tabu
} to
\linewidth{llX
}
15 Deadline & Iterations\\
24 \caption{Deadlines
}\label{tab:deadli
}
28 \begin{tabu
} to
\linewidth{rlXX
}
30 It. & Req. & Description & Deliverables\\
32 1 & NR1 & Create a DSL for MarsRover's missions to use available
33 sensors and actuators. &
\texttt{TaskDSL.xtext
}\\
34 2 & ER3 & Implement diagnostic functions that print on the
\emph{LCD
}.
35 & A
\emph{LCD
} class that prints to the
\emph{LCD
} screen.\\
36 3 & - & Implement functions in the code generation for basic motor the
37 motor actions: forward, backward, measure rock, measure lake and
39 generation for motors\\
40 4 & - & Implement functions in the code generation for communicating
41 the sensors from the slave to the master. & Functions in the master
42 program to read the slave's sensors.\\
43 5 & - & Create functionality for sensor values and determine the
44 treshholds manually. & Code generation for sensors and threshhold
46 6 & CR1 & Create functionality to keep the MarsRover in the planet. &
47 A generatable behaviour to stay on the planet.\\
48 7 & MR3 & Create functionality for not bumping into rocks. & A
49 generatable behaviour to not bump into rocks.\\
50 8 & MR1 & Create functionality to find lakes. & A generatable mission
52 9 & MR6 & Create functionality to perform missions in sequence. & A
53 generatable main program that performs missions.\\
54 10 & MR2, MR4& Create functionality to find rocks. & A generatable
55 mission to find rocks.\\
56 11 & MR5 & Create functionality to push rocks and detect when the
57 robots is pushing. & A generatable behaviour for pushing.\\
58 12 & MR7 & Create functionality to find the parking space. & A
59 generatable behaviour that can find the parking space.\\
60 13 & MR8, ER1 & Create functionality to map the environment and to
61 localize. & A generatable behaviour that can map while
63 14 & ER2 & Create functionality to play sounds. & Add a generatable
64 function for playing sounds.\\
65 15 & NR3, NR4 & Create functionality to calibrate the sensor
66 treshholds. & A generatable function to calibrate the sensors.\\
67 16 & NR5 & Create functionality that when the robot encounters bugs it
68 can restart itself. & Functionality in the main program to do so.\\
69 17 & - & Speed up the behaviour of the robot within safety limits.\\
72 \caption{Spiral model iterations
}\label{tab:devit
}
75 \subsection{Evaluation
}
77 Because of the action defined in behaviour is atomic, it makes the behaviour can be defined dinamically. It means that we can define some combination of actions to do a specific mission. The example of missions that can be supported by the DSL are the following:
79 \item Find lakes by
color sensor
80 \item Find rocks by front ultrasone sensor
82 \item Wander on the table forever
87 \item Park in the corner of the table
89 However the missions that cannot supported by the DSL are the following:
91 \item Find lakes and remember where they are after the robot found them
92 \item Navigate with the map using SLAM (Simultaneous Locatization and Mapping)
95 From our experience, the most important think in the development process was start working from a small functionality and test it. Earlier we know something wrong with the program and earlier we can fix and test it again. That will be good for the development of the next functionality.
96 The difficulty in the development was in the testing phase. The reason is sometimes we got an error when running the program in robot (for example: sensor error) and it took so much time for loading all sensor working to test the robot. There was a time when the robot was crashed and need to be restarted which take some time from the development time.