From: Mart Lubbers Date: Sat, 23 Jan 2016 18:32:22 +0000 (+0100) Subject: more eval X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=e1505e0c872f18c968820077199257c10862e2c7;p=des2015.git more eval --- diff --git a/marsrover/document/evaluation.tex b/marsrover/document/evaluation.tex index e7be3a1..2ebe08a 100644 --- a/marsrover/document/evaluation.tex +++ b/marsrover/document/evaluation.tex @@ -118,6 +118,7 @@ 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 @@ -125,7 +126,7 @@ 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 +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 @@ -133,13 +134,24 @@ 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. -%development process, use of dsl/technologies, general lessons -From our experience, the most important think in the development process was to -start working from a small functionality and to test it. As soon as we knew -something wrong with the program we can fix and test it again in order to ensure -the functionality worked. This would be good for the development of the next -functionality. The difficulty in the development was in the testing phase. The -reason was sometimes we got an error when running the program in the robot (for -example: sensor exception) and it took so much time for loading all sensors to be -ready for testing. Moreover, there was a time when the robot was crashed and needed -to be restarted which took some time from the development time. +\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. + +\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.