rework done

docs/report/report.tex

@@ -15,11 +15,12 @@
 \usepackage{adjustbox}
 \usepackage{tablefootnote}
 \usepackage{bm}
+\usepackage{listings}
 
 \author{Hugo Hörnquist \\ {\small hugho389}%
 		\and%
 		Luka Jankovic \\ {\small lukja239}}
-\date{2022--12--21}
+\date{2023--01--13}
 \title{TDDD07 --- Real Time Systems\\%
 {\small Lab Report}}
 
@@ -160,7 +161,9 @@ To be able to create a schedule the worst case execution time (WCET) of each tas
 This is determined experimentally by placing the robot in different scenarios and measuring the execution time 
 for each task using the robot's built in \texttt{timelib} library. The WCET of each task was then set to the worst
 measured execution time. The scenarios used for each message type are presented in Table \ref{tab:scenarios}.
-For each scenario only the current task was run and 23 measurements were made.
+For each scenario 23 measurements are made and only the current task is run except the report task is run together
+with the refine task and the communicate task which is run together with the refine and report task. 
+However, still only the execution time of the communicate task is measured.
 This data, together with the required periods for each task, is used to design the schedule. To ensure proper
 operation, tasks which don't explicitly have a period defined are supposed to be ran as often as possible. The minimum and maximum periods
 for each task are defined in Table \ref{tab:period}, according to the requirements listed in the introduction. The mission task controls
@@ -188,7 +191,7 @@ least common multiple which is 3000.
 
 \begin{table}
 	\begin{center}
-		\caption{Periods for each task in ms. Values highlighted in bold are the values used in the scheduler. Entries with dashes indicate no explicit period time and should be run as often as possible.}
+		\caption{Periods for each task in ms. Values highlighted in bold are the values used in the schedule. Entries with dashes indicate no explicit period time and should be run as often as possible.}
 		\label{tab:period}
 		\begin{tabular}{ c|c|c }
 			\textbf{Task} & \textbf{Minimum} & \textbf{Maximum} \\
@@ -252,9 +255,9 @@ timeslot. Simple counters are used to measure the amount of data being sent per
 
 \subsection{Execution times}
 
-The execution times for each task is shown in figures \ref{fig:mission-wcet} to \ref{fig:communicate-wcet}.
+The execution times for each task is shown in Figures \ref{fig:mission-wcet} to \ref{fig:communicate-wcet}.
 The WCET for the tasks in each scenario is presented in Table \ref{tab:scenarios_res} and the final WCET for each task is presented in Table \ref{tab:tasks_res}
-The schedule itself is presented in figure \ref{fig:scheduler} and Table \ref{tab:scheduler_tab}.
+The schedule itself is presented in Figure \ref{fig:scheduler} and Table \ref{tab:scheduler_tab}.
 
 \begin{figure}
 	\begin{center}
@@ -272,10 +275,22 @@ The schedule itself is presented in figure \ref{fig:scheduler} and Table \ref{ta
 	\end{center}
 \end{figure}
 
+\begin{figure}
+	\begin{center}
+		\includegraphics[width=\textwidth]{report-wcet.eps}
+		\caption{Execution time for the report task in ms from lowest to highest. The execution time depends on whether the robot is standing on a victim or not.
+		When it is not standing on a victim, the execution time was between 10,108 and 10,121 ms.
+		When it is standing on one victim, the execution time was between 10,549 and 13,124 ms.
+		When it is standing on two victims, the execution time was between 10,545 and 13,310 ms.
+		}
+		\label{fig:report-wcet}
+	\end{center}
+\end{figure}
+
 \begin{figure}
 	\begin{center}
 		\includegraphics[width=\textwidth]{refine-wcet.eps}
-		\caption{Execution time for the refine task in ms from lowest to highest. The execution time depends on whether the robot is standing on a victim or not.
+		\caption{Execution time for the refine task in ms from lowest to highest. The execution time depends on whether the robot is standing on a victim or not. like the report task.
 		When it is not standing on a victim, the execution time was between 10,108 and 10,121 ms.
 		When it is standing on one victim, the execution time was between 10,549 and 13,124 ms.
 		When it is standing on two victims, the execution time was between 10,545 and 13,310 ms.
@@ -303,7 +318,7 @@ The schedule itself is presented in figure \ref{fig:scheduler} and Table \ref{ta
 \begin{figure}
 	\begin{center}
 		\includegraphics[width=\textwidth]{communicate-wcet.eps}
-		\caption{Execution time for the communicate task in ms from lowest to highest. The execution time depends on whether the robot is standing on a victim or not, just like the refine task, see figure \ref{fig:refine-wcet}.
+		\caption{Execution time for the communicate task in ms from lowest to highest. The execution time depends on whether the robot is standing on a victim or not, just like the report and refine task, see Figure \ref{fig:refine-wcet}.
 		When it is not standing on a victim, the execution time was between 1,084 and 1,097 ms.
 		When it is standing on one victim, the execution time was between 1,086 and 1,449 ms.
 		When it is standing on two victims, the execution time was between 1,085 and 1,444 ms.
@@ -344,7 +359,7 @@ The schedule itself is presented in figure \ref{fig:scheduler} and Table \ref{ta
 \end{figure}
 
 \noindent There was one deadline overrun in the beginning caused by the avoid task which did not affect the operation of the robot.
-There were no further deadline overruns, see figure \ref{fig:avoid-result} to \ref{fig:victim-time-result}.
+There were no further deadline overruns, see Figure \ref{fig:avoid-result} to \ref{fig:victim-time-result}.
 
 \begin{table}
 	\newcommand{\cmd}[1]{\rotatebox{90}{\textbf{#1}}}
@@ -407,7 +422,7 @@ There were no further deadline overruns, see figure \ref{fig:avoid-result} to \r
 \begin{figure}[h]
 	\begin{adjustwidth}{-\oddsidemargin-1.4cm}{-\rightmargin}
 		\centering\includegraphics[width=0.9\paperwidth]{scheduler.eps}
-		\caption{The scheduler for the robot. The minor cycle is 100
+		\caption{The schedule for the robot. The minor cycle is 100
 			ms and the major cycle is 3000 ms.}
 		\label{fig:scheduler}
 	\end{adjustwidth}
@@ -450,7 +465,7 @@ The accuracy of the reported victim locations is presented in table \ref{tab:vic
 
 The test results for the requirements in lab 1 were about the same as in lab 1. They were, however, not recorded.
 The go-ahead message was received every second as was evident by the fact that the robot did not stop due to not receiving it.
-The amount of stream data being sent is presented in figure \ref{fig:stream}.
+The amount of stream data being sent is presented in Figure \ref{fig:stream}.
 
 \begin{figure}
 	\begin{center}
@@ -466,13 +481,30 @@ The amount of stream data being sent is presented in figure \ref{fig:stream}.
 
 % Detail, for each graph. good or bad? references!!
 
-The scenarios were chosen to try and reflect what could happen in practice. This could be further worked upon with more
-intricate scenarios involving more tasks at the same time. However, we felt that the goal was to determine the runtime
-of the tasks in isolation (where applicable). And since we decided on a minor cycle which was longer than the runtime
-of any individual tasks we felt that there was enough headroom to accompany for any unexpected run times that we did not encounter when measuring execution times.
-This is something we saw in practice, with the exception of the avoid task sometimes taking around 150 ms.
+\subsection{Execution times}
+
+The scenarios were chosen to try and reflect what could happen in practice. For the tasks refine, avoid and communicate 
+we feel this method gave us a good understanding of how the execution time varies in different scenarios. We noticed
+that the communicate task did not always take longer to execute when the robot was over one or more victims. We believe
+this is because the send queue had not been filled in those cases, and we still managed to measure the scenario where
+the communicate task did send, as is evidenced by the increase in execution time, see Figure \ref{fig:communicate-wcet}.
+We feel that the tasks navigate and mission needed to be tested in more scenarios than just the standard one to be an
+accurate representation of the runtimes. This could have been done by better studying the behavior of these tasks and
+what type of data they depend on. For example, an appropriate scenario for the mission task would be to send a stop 
+command from the mission control software.
+
+The avoid task would sometimes take around 150 ms to run in the first cycle, when the robot was starting up.
 This, however, did not happen again in the same run and did not affect the performance of the robot.
 
+\subsection{Schedule}
+
+The schedule was designed so that there is margin between the sum of all execution times and the minor cycle, in case
+a task would take longer to execute than what we measured. See Table \ref{tab:tasks_res} and Figure \ref{fig:scheduler}.
+In our testing there were no deadline overruns in the schedule, except for when the avoid task would take longer on the
+first cycle, as mentioned previously.
+
+\subsection{Requirements}
+
 In general our schedule fullfilled the timely requirements. The difference between reported victim locations and known
 victim locations however, varied. From our testing we concluded that an incorrect location of a victim is reported if a
 victim is found before a localisation tag, meaning the correct location of the robot itself is not correctly determined
@@ -482,14 +514,65 @@ yet at that point.
 
 % 
 
-The checks performed in the communication task means that the robot never sends outside its allowed slot. This means that
-the robot always receives the go-ahead message and therefore never has to stop, while still being able to send a good amount
-of stream data. Since we designed our schedule to accomodate for the requirements of the second lab from the beginning, we
-did not have to make any changes to it and therefore the performance regarding the requirements of the first lab are the same.
+\subsection{Data}
 
-One issue, however, with our implementation is that when our robot is connected to the network it has a tendency to cause
-the mission control software to crash unexpectedly. This behavior is mostly random although does seem to occur more often
-right when the robot connects to the network.
+The checks performed in the communication task means that the robot never sends outside its allowed slot. This means that
+the robot always receives the go-ahead message and therefore never has to stop. The varying amount of stream data being
+sent is a result of there being an inconsistent amount of stream data being generated on the robot. We think it would have
+been good to measure the amount of stream data not being sent each time the communicate task runs as well. This way, we could
+measure how far behind we are with the stream data or if we manage to send all of the available stream data. The communicate
+task was always able to send all victim reports, location messages and pheromone maps since it was alyways able to
+send stream data. (It would never have gotten to the stream data if it had to stop while sending the other types of messages.)
+
+\subsection{Requirements}
+
+We designed our schedule to accomodate for the requirements of the second lab while working on the first lab. This means
+that for the most part, we expected the performance requirements to be similar to when running the first lab. We also
+noticed this when running some tests during lab two (not recorded). One big exception is the requirement "The time from 
+when a victim is read by the RFID reader to when a message being sent must be less than 1300 ms". This was measured
+before the change to run the communicate task every second, see figure \ref{fig:victim-time-result}. In theory, this
+requirement will be met because the refine and report task run every minor cycle (100 ms) and the communicate task
+every second (1000 ms). We can, however, not make a conclusion regarding this requirement because we did not test it
+properly.
+
+\subsection{Mission control crashing}
+
+One issue, however, with our implementation is that when our robot is connected to the network it causes
+the mission control software to crash unexpectedly. This behavior occurs whenever the robot is connecting
+to a mission control that is already running (Both when the robot is the only one connected to the mission
+control software and when there are more robots.). We beleive this is due to the communicate task being the
+first thing to run after the robot has waited and our implementation of the stream data buffer. Because the
+communicate task is the first task to run means the other tasks have not been able to populate the data
+queues and buffers at that point. For stream data we decided to use our own circular buffer implementation,
+which internally uses a normal C array. However, we never properly initialize the array nor the pointers when the circular
+buffer struct is created. As a result, the default values in the circular buffer are not zero or empty but rather
+arbritrary values, which are then being sent from the communicate task to the mission control software. As an example,
+the following test which illustrates the problem was run on Linux on an x86 platform:
+
+\begin{lstlisting}[language=C]
+
+$ cat test.c
+#include<stdio.h>
+
+int main() {
+	int a[128];
+	int b, c;
+	printf("%i %i %i\n", a[10], b, c);
+
+	return 0;
+}
+
+$ gcc test.c
+$ a.out
+832 32624 953641648
+
+\end{lstlisting}
+
+As it is now, the quickest solution would be to run the task that generates stream data before running the
+communicate task but that would not solve the underlying issue. We could definitely have spent time to
+fix our circular buffer implementation by assigning default values to the members but the best option in
+regards to the lab would probably be to use the given APIs such as the queue or doubly linked list as we
+did for the rest of the message types.
 
 % We believe it has something to do with...