X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=marsrover%2Fdocument%2Fevaluation.tex;h=9d3924011a77d0074ba315de5652d96e39c29c1e;hb=df79a72b12ce6656f0fcf9c0bc3bff114295c46f;hp=15546142ca1ebff16a1108007a1d4772b9fb1d85;hpb=a77c0f57e7044887dd5bab41311e79a0739cb85a;p=des2015.git diff --git a/marsrover/document/evaluation.tex b/marsrover/document/evaluation.tex index 1554614..9d39240 100644 --- a/marsrover/document/evaluation.tex +++ b/marsrover/document/evaluation.tex @@ -33,14 +33,14 @@ and if they are we try to complete as many iterations as possible. sensors and actuators. & \texttt{TaskDSL.xtext}\\ 2 & ER3 & Implement diagnostic functions that print on the \emph{LCD}. & A \emph{LCD} class that prints to the \emph{LCD} screen.\\ - 3 & - & Implement functions in the code generation for basic motor the + 3 & -- & Implement functions in the code generation for basic motor the motor actions: forward, backward, measure rock, measure lake and wait. & Code generation for motors\\ - 4 & - & Implement functions in the code generation for communicating + 4 & -- & Implement functions in the code generation for communicating the sensors from the slave to the master. & Functions in the master program to read the slave's sensors.\\ - 5 & - & Create functionality for sensor values and determine the + 5 & -- & Create functionality for sensor values and determine the treshholds manually. & Code generation for sensors and threshhold constants.\\ 6 & CR1 & Create functionality to keep the MarsRover in the planet. & @@ -66,10 +66,98 @@ and if they are we try to complete as many iterations as possible. treshholds. & A generatable function to calibrate the sensors.\\ 16 & NR5 & Create functionality that when the robot encounters bugs it can restart itself. & Functionality in the main program to do so.\\ - 17 & - & Speed up the behaviour of the robot within safety limits.\\ + 17 & -- & Speed up the behaviour of the robot within safety limits.\\ \bottomrule \end{tabu} \caption{Spiral model iterations}\label{tab:devit} \end{table} \subsection{Evaluation} +\subsubsection{Requirements realisation} +%implemented features and mission range +The final implementation satisfies all the \emph{must have} requirements. +Besides all the most important requirements it also supports all \emph{should +have} requirements except \emph{MR8} in which the robot must be able to +remember the locations of the lakes. This is because we encountered some +problems during the development phase that lead to a shortage of time. Because +of that mapping and localization was not implemented. In the end of the process +we had some time left which we used to implement \emph{ER2} since it was +relatively simple. + +\paragraph{Mission range} +The range of missions the robot can support is a lot bigger then reflected by +the met functional requirements. All actions specifiable in a behaviour consist +of atomic operations that take very little time leading to the action being +interruptible at all times. Together with the rudimentary variable storage we +can make missions very complex. Possible combinations of behaviour can perform +actions such as: counting, following moving objects and grouping objects. + +One could argue that due to the lack of control structures it is very difficult +to program complex missions. This is the case, for example if we would add a +\emph{while} construction it would increase the range of missions very much. +However, it also makes programming the robot much more difficult and will +reduce the usability. With the current structure, the subsumption +architecture and the rudimentary memory, we actually can create such control +structures but it takes a little more effort. + +\paragraph{Flexibility} +The DSL can very easily be improved in the case of adding new sensors or +actuators. For sensors we can just add clauses in the grammar within the +\emph{StoppingExpression} that will process the values. For actuators the same +thing can be done in the \emph{Action} rule. A change in the robot's +configuration can also be handled very quickly albeit not in the DSL itself. We +specifically chose not to incorporate the hardware configuration in the DSL to +keep is a simple as possible and thus less error prone. This means that if the +hardware configuration changes the underlying library must be changed as well. +However, due to the modularity of the library this is very easy. + +\paragraph{Safety} +The DSL by design does not generate \emph{safe} code implicitly. A programmer +can make a program that can destroy the robot very easily. While safety is very +important it would limit the range of missions a lot if some basic behaviours +used in the demonstration for safety would be inherently present. + +\subsubsection{Development process} +\paragraph{Feedback loop} +Booting the bricks takes around a minute to complete. When the robot is +programmed launching the application takes another 30 seconds followed by +another 30 seconds waiting on the initialization of the sensors. About once +every 10 times on high battery and about every other time on low battery the +ultrasonic sensor fails to initialize. We did not have the time to investigate +this properly but the fault was hidden somewhere deep in the \emph{LeJOS} code. +When all sensors were initialized the Bluetooth connection could be commenced +by pressing a button on both bricks. Connecting via Bluetooth has about the +same error rate as the ultrasonic sensor has and takes about 30 seconds. + +This very long start up led to a rough development process with long feedback +loops. After a long time we and other groups found out that applying power to +the bricks during the initialization and pairing reduced the error frequency a +lot. + +\paragraph{Techniques} +Using the combination of all tools such as DSL, XText, XTend and eclipse went +surprisingly well. In the beginning there were some technical difficulties +setting everything up and there was quite some overhead since the tools +required a lot of computing power. But when everything was set up correctly it +worked like a charm. + +Creating our solution was a bit difficult at the beginning due to extra works +designing the DSL to accomodate the robot's missions and behaviours. However +when the DSL was created appropriately the generation of different missions and +behaviours for the robot became very easy. + +\paragraph{General lessons learned} +From our experience, the most important thing in the development process was to +work iteratively in small building blocks. Another lesson learned was the fact +that robots are not always reliable and can behave in unexpected ways. + +Another lesson learned was that plans mostly take longer than expected. Our +planning was very generous but still we did not have time to implement some +extra functionality. If we would have more time we would have tried to make the +robots autonomous in start up. The current robot needs to have a button pressed +when the bricks can pair. We have experimented with autonomous pairing but we +never got it stable but with more time we could make it stable. Another option +is to try to get more requirements. For example the mapping and internal +representation of the locations of the lakes. This problem is not trivial at +all and because of the lack of time we could unfortunately not spend time on +it.