Update of report

content/casestudy.tex

@@ -127,10 +127,9 @@
             For readability, the result has to be readable from 4 meters distance.
 
             The specifications itself are written with \ac{ears} and are as follows:
-            \begin{itemize}
+            \begin{enumerate}
                 \item The Writer shall be able to write at least 50 characters per line.
                 \item The Writer shall be able to write at least 5 lines of text.
-                \item The Writer shall display the author, time, content, and number of retweets, favorites and replies in plain-text.
                 \item The Writer shall plot characters with a size that is readable from 4 meters for a person with good eyesight.
                 \item The Writer shall plot in a regular used font with corresponding character spacing.
                 \item When a new tweet is send to the Writer, the Writer, shall wipe the existing tweet and write down a new tweet.
@@ -140,7 +139,7 @@
                 \item When a reset-signal is send to the Writer, the Writer shall recalibrate its position on the board.
                 \item When a wipe-signal is send to the Writer, the Writer shall wipe the board clean.
                 \item The Writer shall not damage itself.
-            \end{itemize}
+            \end{enumerate}
 
             Additionally there are some restrictions on construction.
             The tooling in limited to some hobby/DIY tools.
@@ -183,6 +182,7 @@
                 \end{itemize}
 
         \subsection{Initial Design}
+        \label{sec:initialdesign}
             \rro{Research on Existing Systems}
             The initial design started with a design space exploration.
             The goal was to collect possible solutions and ideas for the implementation.
@@ -252,6 +252,14 @@
                 It was therefore decided to combine a small SCARA with a cable driven robot.
                 Where the SCARA can write a couple of characters at high speed from a fixed position.
                 The cables can than move the complete SCARA to the next position.
+                The full setup can be seen in \autoref{fig:general_design}.
+            \begin{figure}
+                \centering
+                \includegraphics[width=\linewidth]{graphics/general_design.pdf}
+                \caption{Rough design of the system. The carriage is in this situation blue and the SCARA is red. The two cable running to the top-corners of the whiteboard move the carriage.}
+                \label{fig:general_design}
+            \end{figure}
+
 
                 The combined system introduces sufficient complexity for the design method.
                 The cable robot and SCARA are both sub-systems of the complete writing robot that can be implemented separately.
@@ -319,7 +327,7 @@
             \rroi{Additionally, division of system requirements}
             \rro{Expected: A list of features, with corresponding dependencies}
             \rro{Could define features, but non of them described mechanical components that could be implemented.}
-            \rro{Result: Improvised a structure that was loosely based on Robmosys}
+            \rro{Result: Improvised a structure that was loosely based on RobMoSys}
             \rroi{The lose features:}
             \rroii{End-effector}
             \rroii{SCARA}
@@ -337,29 +345,254 @@
                 Even though, there is a feature definition that can be used in the next step, there remain a couple of difficulties.
                 There is still a really strong border between features and components.
                 And the single level of components makes it impossible to depict the dependencies between components.
-                Developing larger and complexer systems will have sub-components in the system, introducing even more dependencies.
+                Developing larger and complex systems will have sub-components in the system, introducing even more dependencies.
                 Therefore, this is not a valid solution for feature definition.
                 Fortunately the current solution suffices to continue the case study.
                 
         \subsection{System Test Specification}
+            The last step of the preliminary design is to design tests.
+            The tests are designed around the specifications.
+            However, during the creation of the tests it was found that the list of specifications were lacking.
+            Furthermore, the previous steps did not provide any order of operation.
+            During this step the order of operation and additional specifications are determined.
+            
+            There are two modes of operation: writing and wiping.
+            The writing operation can be split in the following steps:
+            \begin{enumerate}
+                \item Move cable driven carriage to position of characters.
+                \item Write three characters with the SCARA.
+                \item Repeat step 1 and 2 till the Tweet is on the board.
+                \item Move carriage away from the text on the board.
+            \end{enumerate}
+            
+            The other operation is wiping.
+            This is similar to the operation of writing with the following steps:
+            \begin{enumerate}
+                \item Move cable driven carriage to position of characters.
+                \item Clear the area in reach of the SCARA.
+                \item Repeat step 1 and 2 till the Tweet is removed from on the board.
+            \end{enumerate}
+            Furthermore, switching between the states requires the tool to be switched.
+            As this is a difficult operation there are not yet requirements or order of operation specified.
+
+            Based on the order of operation, the following specifications were added to the list in \autoref{sec:specifications}:
+            \begin{enumerate}
+                \setcounter{enumi}{11}
+                \item While writing, the SCARA shall have a writing speed of at least 1.5 characters per second.
+                \item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least 3 characters at that position.
+                \item When the SCARA finished writing at their current position, the Carriage shall move the SCARA to it's next position where it can write the subsequent characters.
+                \item When the SCARA has to be moved to a new position, the Carriage shall perform this movement within 1 second.
+            \end{enumerate}
+            These additional specifications are also based on the combined system decission that was made in section \autoref{sec:initialdesign}.
+            These specifications distribute responsibility between sub-components.
+            
+            With the updated specifications it was possible to create a number of test cases.
+            In total there are five small test cases and four large test cases.
+            The small tests cover a sub-system and the large tests apply on the complete systems.
+            Each tests has a list of specifications that are covered with the test and for smaller tests the subsystem under test is also determined.
+            With a short description it is described how the test should be performed.
+            
+            One of the small tests is performed by drawing a square:
+            \begin{description}
+                \item[Sub-systems] SCARA
+                \item[Specifications] 3, 7, 11, 13
+                \item[Description]
+                    The SCARA must draw a square of at least 50 mm high and 70 mm wide.
+                    This box is large enough to draw at least 3 characters.
+                    This square should be drawn within one second.
+                    If it is slower than that, it is not able to achieve specification 7.
+            \end{description}
+            \rrot{TODO: Make clear that the tests case ends here...}
+            Repeatability is tested in one of the large tests.
+            \begin{description}
+                \item[Specifications] 3, 4, 9, 11
+                \item[Description]
+                    To test the repeatability of the system must do four things:
+                    \begin{itemize}
+                        \item The system will be reset.
+                        \item Draw multiple squares (60 mm x 60 mm) at a random position within the drawing range (1000 mm x 300 mm).
+                        \item The system will be reset again.
+                        \item Then in a random order, at least different from the order of squares, a circle with a 55 mm diameter must to be drawn inside the squares.
+                    \end{itemize}
+                    The test is successful if the circles are not drawn outside of the squares.
+            \end{description}
+            \rrot{TODO: Make clear that the tests case ends here...}
+            \rrot{TODO: Add the tests to the appendix}
+            All the tests are included in the appendix.
             \rro{Specify tests for the different specifications}
             \rro{Made a document with tests}
             \rroit{Should this document be included in the report?}
             \rroi{Each test covers one or more specs}
             \subsubsection{Evaluation}
-                \rro{Was quite easy to perform}
-                \rroi{Difficult due to specs and features not working out as expected}
-                \rroi{Most features could not be tested as the subsystem needs to be completed first}
-                \rro{Tested by peer-review}
-                \rroi{Found that a review without all the project information is difficult}
+                This step was completed with not many difficulties.
+                The specific order of operation and extra specifications should not be part of this step.
+                It was already concluded that the steps in the preliminary design were not as expected.
+                The fact that this step resulted in an additional changes only adds to that conclusion.
+                
+                The design of the test cases resulted in valuable information about the system.
+                This information would be very useful in an earlier stage of the preliminary design.
+
+        \subsection{Recap}
+            The test definitions of the last step conclude the preliminary design phase.
+            This preliminary design shows a clear notion of a hasty execution from a design standpoint.
+            The preliminary design was performed over a period of 5 weeks, by one developer with little experience in design documentation.
+            This makes notion of hasty not surprising for this unproven design method.
+            That does not mean that this preliminary design is a waste of time.
+            From the evaluation moments during the preliminary phase there are a couple of interesting points.
+            \begin{itemize}
+                \item The lack of a design team with experienced engineers would drastically improve the execution of this design phase.
+                    Such a team is also able to find the smaller problems of such a design phase, which are currently completely overlooked.
+                \item It is not possible to view each step in the design process as singular.
+                    Each step creates more insight and information about the final design.
+                    Making a very strong separation between the steps forces the developer to make decisions on to little information.
+                \item The term features has to be split in to functions and components for a hardware design.
+                    The actual implementation are the components such that they can perform the function.
+            \end{itemize}
+
+            Another point was noticed while evaluation the complete preliminary design phase.
+            The lack of a team makes it easy to forget documenting intuitive design decisions.
+            Although the design method is followed as closely as possible, it often occurs that a decision is made outside of the working environment.
+            This was noticed during the writing of this chapter that some design decisions were completely missing.
+            However, during the next phase, these decisions do play a crucial role.
+            Therefore, this section will give a short recap of the planned design.
+
+            \subsubsection{Complete system}
+            From the initial design the abstract shape of the design is clear.
+            This is still in line with \autoref{fig:general_design}.
+            The SCARA is small and can therefore move the arm quick with a fine precision.
+            At the end of the SCARA there is a end-effector that can grab, hold, end release tool.
+            It holds a marker while writing and with help of the SCARA it can release the marker.
+            Then it can grab a cleaning tool to erase whiteboard.
+            To compensate for the small reach of the SCARA, the SCARA will be mounted to a carriage.
+            This carriage is suspended from cables and can move along the whiteboard.
+            The cables give the system a enormous range and velocity.
+            However, it is not very good in acceleration as cables cannot push.
+            This makes it suitable for the large and course movements along the board, which complements the movement characteristics of the SCARA.
+            
+
+            
+            \subsubsection{SCARA}
+            The central component of the system is the SCARA.
+            There are a couple of design options for the SCARA.
+            As the dynamic complexity is a important part of this design, there will be two arms.
+            There are some different options for the configuration of the arms and their actuation.
+            \autoref{fig:configurations} shows four of the possible configurations that are considered during the design phase.
+            There are still options about where to place the motors and how to connect the joints.
+            \rrot{Figure needs some graphic improvement}
+            \begin{figure}
+                \centering
+                \includegraphics[width=\linewidth]{graphics/IMG_20201001_134140.jpg}
+                \caption{Four different SCARA configurations}
+                \label{fig:configurations}
+            \end{figure}
+
+            \subsubsection{End-effector}
+            The end-effector is the connection between the SCARA and the tool.
+            It has two main functions: lifting the tool from the board and switching the tool.
+            The tool switching functionality is performed by the SCARA as well, by moving the end-effector to the right position.
+            However, the role of the SCARA is strongly dependent\footnote{ Note, that this dependency exists but not represented in \autoref{fig:robmosys} due to the limitation of the current method.} on how the end-effector is implemented.
+            For the grabbing function there is a configuration that uses a spring-loaded clamp.
+            Where one side of the clamp is longer so it can be opened by moving the SCARA.
+            This operation is shown in \autoref{fig:gripper}
+            \begin{figure*}
+                \centering
+                \includegraphics[width=\linewidth]{graphics/IMG_20201001_144018.jpg}
+                \caption{Operation principle of a spring-loaded tool clamp showed from left to right. The green circle represents the tool and the red arm a tool holder. The solid ground is what pushed the upper arm open so the marker can be placed in the tool holder.}
+                \label{fig:gripper}
+            \end{figure*}
+
+            Another dynamically simpler option is to open the clamp with a motor.
+            The motor adds weight to the end-effector which might require the SCARA to operate slower or to be build stronger.
+            This component is probably the most difficult one because it requires clamping of the tools.
+            Modeling this behavior is difficult as it will involve contact dynamics.
+
+            \subsubsection{Cable driven Carriage}
+            The end-effector and the SCARA are moved all together on a carriage.
+            The carriage will be suspended from two or four cables.
+            A configuration with two cables is the simplest.
+            However, the tension in this system is generated by the gravitational pull.
+            This introduces limitations in the acceleration of the system.
+            If the carriage moves upwards and the cable pulleys stop.
+            The carriage is only decelerated by the force of gravity.
+            Moving over its set point, followed by crashing down in to the cables.
+            
+            However, making the system with four motorized pulleys makes the system over constrained.
+            This will solve the acceleration problem. But it will create a difficult positioning system.
+            As all the wires have to be tensioned but not distort the movement by restricting the other motors.
+
+            \subsubsection{Electronics}
+                Although this mainly is a hardware design, there is going to be some control-software.
+                For this the likely option is a STM nucleo board with RIOT-OS as a embedded OS.
+                This choice is mainly because of previous experience and local knowledge of the operating system.
+                
+
 
     \section{Detail Design}
-        \subsection{Feature Selection: First Iteration}
-            \subsubsection{Selection}
+        With the preliminary design finished the first feature can be implemented.
+        Therefore, it has to be determined what that first feature is.
+        This is followed by building a basic model of the first feature.
+        Over multiple cycles detail will be added to that model.
+        When the model is sophisticated enough these steps are repeated for the next feature.
+        \subsection{First Feature Selection}
+            Three different components were defined as hardware features that could be implemented.
+            The feature selection method as defined in \autoref{sec:feature_selection} will be applied to these features.
+            According to the method, the dependencies, test coverage and risk/time factor have to be determined.
+            All the information for this selection is shown in \autoref{tab:firstfeatureselection}
+            \begin{table}[]
+                \caption{Overview of the different features and their dependencies, number of tests that can be completed and the risk/time factor.
+                The risk/time factor is calculate as risk divided by time with \emph{low} = 1, \emph{medium} = 2 and \emph{high} = 3.}
+                \label{tab:firstfeatureselection}
+                \begin{tabular}{llllll}
+                    \hline
+                    Feature      & Dependency   & Tests         & Risk   & Time   & Risk/Time        \\ \hline
+                    Scara        & End-effector & 3             & medium & medium & 1                \\
+                    End-effector & -            & 2             & high   & medium & 1.5              \\
+                    Carriage     & -            & 2             & low    & medium & 0.5              \\ \hline
+                \end{tabular}
+            \end{table}
+
+            The SCARA is dependent on the end-effector, as was explained in the initial design.
+            However, for the carriage no dependency was defined even though it has to lift the other two components.
+            This is mainly because the behavior of the SCARA changes depending on the end-effector, resulting in a possible design change.
+            For the carriage it only changes the mass that has to be lifted.
+            Upgrading the motor torque is a minor parametric change and the dependency is therefore insignificant.
+
+            The testing number is directly the number of tests that can be completed by implementing that single component.
+            For the risk and time it was a engineering judgement and no specific protocol to determine the values.
+            The estimated risk is high for the end-effector due to the collision dynamics of the operation.
+            It has to grab something and that is difficult to model. Furthermore, it was not known if that design would work.
+            The SCARA has the most moving parts, but no difficult dynamics and has therefore an estimated risk of medium.
+            For the carriage the there was no real risks and got therefore a low risk indication.
+            
+            The SCARA would be implemented first based on number of tests, but is dependent on the end-effector.
+            Beginning with the end-effector is an obvious choices. It unlocks the SCARA and has the highest risk/time factor.
+
+            \subsubsection{Evaluation}
+                This first step of the detail design phase did go well.
+                A more refined method for this step could be very useful.
+                But the risk and time assessment will probably always be a engineering judgement from the developer.
+                Within a design team a form of planning poker\footnote{\url{https://en.wikipedia.org/wiki/Planning_poker}{Wikipedia entry: Planning Poker}} could be a good option.
+            
                 \rro{Compared: Dependency, tests coverage and risk/time ratio}
                 \rroi{First Feature/system to implement is End-effector.}
                 \rroii{Due to dependency and high risk/time}
-            \subsubsection{Implementation}
+
+        \subsection{End-effector model}
+            The end-effector will operate as an interface between the SCARA and the different tools.
+            For that it has to be able to grab and release the tools.
+            The initial design is shown in \autoref{fig:gripper}. 
+            With only some experience in modelling with collisions the decision was made to try to make some collisions in the 20-sim 3D mechanics editor.
+            Unfortunately, collisions in a 20-sim model are difficult.
+            There is little tooling available and there are no debugging options if the model does not behave as expected.
+            The marker kept falling trough the gripper or flew away.
+            With the small amount of progress made in two days the implementation was not promising. 
+            A crash in the software caused the model to corrupt, where the complete configuration of the shapes and their collisions was lost.
+            Therefore it was decided that end-effector would be removed from the design.
+
+            With the end-effector removed, the SCARA will get a direct connection with the marker.
+            The lifting of the marker will be included in the SCARA as well.
+            Furthermore, this means that the wiping will no be possible via the SCARA.
+
                 \rro{Plan: Model a gripper}
                 \rroi{Result: Underestimated Complexity}
                 \rroii{No debugging options for collisions in 3D-ME}
@@ -368,6 +601,15 @@
             \subsubsection{Evaluation}
                 \rro{Result is not as expected}
                 \rro{Risk/time factor proofed itself useful}
+                The lost progress of the model is unfortunate, but the implementation did not go expected anyway.
+                It was probably for the best as it forced an evaluation of the design and avoided a tunnel vision while trying to get it to work.
+                However, it did show the value of the risk/time analysis.
+                This early failure resulted in changes for other components.
+                But as none of the components were implemented yet, no work was lost.
+                
+
+%%%%%%%%%%%%%%%%%%%%%%%
+
         \subsection{Feature Selection: Second Iteration}
             \subsubsection{Selection}
                 \rro{Scara is next in selection}

content/designcycle.tex

@@ -164,6 +164,7 @@ However, any mistakes made, could require a review of one or more steps of the p
     As the focus of this Thesis is on hardware design, the software testing will not be part during this research.
 
 \section{Feature Selection}
+    \label{sec:feature_selection}
     This section explains the selection criteria which determines the next feature that will be implemented.
     During the development it is expected that problems and issue occur.
     The consequences of these issues are that a system requires a (partial) redesign.

content/system_test_specification.tex

@@ -0,0 +1,280 @@
+\hypertarget{system-test-specification}{%
+\chapter{System Test Specification}\label{system-test-specification}}
+
+\hypertarget{introduction}{%
+\section{Introduction}\label{introduction}}
+
+A new design method is the goal of this Master's Thesis. Part of the
+design method is a system test specification. The system tests are based
+on the system specifications. If the tests are designed correctly,
+passing the test proofs that the system operates within the
+specifications.
+
+In the following section we will give a short introduction of the system
+that we plan to build. Then we have a section with a collection of
+smaller and or simpler tests. These test can be passed before the system
+is complete. Followed by a set of test that cover the complete system
+and thus require all the features to be available in some part.
+
+\hypertarget{system-description}{%
+\section{System Description}\label{system-description}}
+
+\hypertarget{design}{%
+\subsection{Design}\label{design}}
+
+The system that will be designed is a whiteboard writer. Its goal is to
+write a tweet on a whiteboard. To make it dynamically challenging it is
+a combination of two subsystems. First we have a SCARA, which is a 2D
+arm. This SCARA is relatively small to the complete system. With the
+smaller size we can achieve a higher speed and accuracy. However, the
+size of the arm limits the range significantly. A cable bot will be used
+to move the base of the SCARA arm around on the board.
+
+Furthermore, the third part is the end-effector of the SCARA arm. This
+is how the marker is attached to the arm. The end-effector could also be
+replaced with something that can switch between tools. For example a
+different color marker and a wiping tool. Or vice versa.
+\begin{figure}
+    \centering
+    \includegraphics{graphics/general_design.pdf}
+    \caption{Rough design of the white board writer}
+    \label{fig:figuresize}
+\end{figure}
+
+\hypertarget{components}{%
+\paragraph{Components}\label{components}}
+
+\begin{itemize}
+\item
+  \emph{End-effector:} the end-effector is responsible for the
+  connection of the tool with the SCARA.
+\item
+  \emph{SCARA:} Acronym for: `Selective Compliance Articulated Robot
+  Arm'. It is colored red in the figure above. This arm moves in a 2D
+  space along the whiteboard. Its task is to move the end-effector
+  around. The base of the arm is mounted on the carriage.
+\item
+  \emph{Carriage:} This is the base for the SCARA. It is suspended from
+  two wires. By changing the lenght of the wires it can move itself
+  along the board.
+\end{itemize}
+
+\hypertarget{specification}{%
+\paragraph{Specification}\label{specification}}
+
+From the previous design steps we got the following list of system
+specification:
+
+\begin{enumerate}
+\def\labelenumi{\arabic{enumi}.}
+\item
+  The Writer shall be able to write at least 50 characters per line.
+\item
+  The Writer shall be able to write at least 5 lines of text.
+\item
+  The Writer shall plot characters with a size that is readable from 4
+  meters for a person with good eyesight.
+\item
+  The Writer shall plot in a regular used font with corresponding
+  character spacing.
+\item
+  When a new tweet is send to the Writer, the Writer, shall wipe the
+  existing tweet and write down a new tweet.
+\item
+  If the Writer is not wiping or writing then the Writer shall not
+  obstruct the view of the whiteboard.
+\item
+  While writing, the Writer shall have a writing speed of at least 1
+  character per second.
+\item
+  If the Writer is tasked to wipe the tweet, the Writer shall wipe the
+  tweet within 60 seconds
+\item
+  When a reset-signal is send to the Writer, the Writer shall
+  re-calibrate its position on the board.
+\item
+  When a wipe-signal is send to the Writer, the Writer shall wipe the
+  board clean.
+\item
+  The Writer shall not damage itself.
+\item
+  While writing, the SCARA shall have a writing speed of at least 1.5
+  characters per second.
+\item
+  When the Carriage/base of the SCARA is at a static position, the SCARA
+  shall be able to write at least 3 characters at that position.
+\item
+  When the SCARA finished writing at their current position, the
+  Carriage shall move the SCARA to it's next position where it can write
+  the subsequent characters.
+\item
+  When the SCARA has to be moved to a new position, the Carriage shall
+  perform this movement within 1 second.
+\end{enumerate}
+
+Although the list of specifications does not cover the size of a
+character. For the testing we determined that the body of a character
+should have a height of 20 mm. And can extend about 7 mm above and
+below. Which give a total writable height of about 35 mm
+\begin{figure}
+    \centering
+    \includegraphics{graphics/charactersize.pdf}
+    \caption{Figure size example}
+    \label{fig:figuresize}
+\end{figure}
+
+\hypertarget{operation}{%
+\subsection{Operation}\label{operation}}
+
+There are two main operations of the system. The writing behavior and
+the wiping behavior. To write, the following steps shall be performed:
+
+\begin{itemize}
+\item
+  Move the carriage/base of the SCARA to the first characters that shall
+  be written.
+\item
+  The SCARA writes at least 3 characters at that position.
+\end{itemize}
+
+These two steps are repeated until the complete text is on the board.
+
+The writing operation will behave in a similar way. Where the SCARA will
+do the course operation and the carriage the full operation.
+
+\hypertarget{small-tests}{%
+\section{Small tests}\label{small-tests}}
+
+The following tests do not cover the complete system but only one or two
+subsystems.
+
+\hypertarget{small-square}{%
+\subsection{Small Square}\label{small-square}}
+
+\emph{Subsystem:} SCARA
+
+\emph{Specifications:} 3, 7, 11, 13
+
+The SCARA must draw a square of at least 50 mm high and 70 mm wide. This
+box is large enough to draw at least 3 characters. This square should be
+drawn within one second. If it is slower than that, it is not able to
+achieve specification 7.
+
+\hypertarget{perimeter}{%
+\subsection{Perimeter}\label{perimeter}}
+
+\emph{Subsystem:} Carriage
+
+\emph{Specifications:} 1, 2, 6, 11,
+
+The carriage must move along the outer edges of the text area. This
+means that it must reach 50 characters in width and 5 in height.
+Resulting in perimeter of 1000 mm wide and 250 mm high.
+
+The second part of this test is that the carriage must also move outside
+of the perimeter.
+
+\hypertarget{carriage-speed}{%
+\subsection{Carriage Speed}\label{carriage-speed}}
+
+\emph{Subsystem:} Carriage
+
+\emph{Specifications:} 7, 14
+
+The carriage must be able to move a distance of 80 mm in horizontal
+direction to move within a second. At the start and the end of the
+movement the speed of the carriage must be zero.
+
+This is to ensure that the SCARA can then write its characters at the
+given position.
+
+\hypertarget{triple-chars}{%
+\subsection{Triple Chars}\label{triple-chars}}
+
+\emph{Subsystem:} SCARA, End-effector
+
+\emph{Specifications:} 3, 4, 12, 13
+
+The SCARA together with the end-effector must write 3 characters without
+moving the carriage. This extends on the small square but the
+end-effector must now be able to lift the marker of the board. The three
+characters should be written on the board within two seconds.
+
+\hypertarget{tool-change}{%
+\subsection{Tool change}\label{tool-change}}
+
+\emph{Subsystem:} SCARA, End-effector
+
+\emph{Specifications:} (Not specified, due to errors in earlier design
+phase)
+
+Tool changing is not a specific part of the specification. However, the
+system has to switch in some way between the marker and a wiper. Or a
+different color. For this test the system must switch a tool within 10
+seconds.
+
+\hypertarget{overall-tests}{%
+\section{Overall tests}\label{overall-tests}}
+
+These are the larger tests where all the subsystems come together.
+
+\hypertarget{repeatability}{%
+\subsection{Repeatability}\label{repeatability}}
+
+\emph{Specifications:} 3, 4, 9, 11
+
+To test the repeatability of the system must do four things:
+
+\begin{itemize}
+\item
+  The system will be reset.
+\item
+  Draw multiple squares (60 mm x 60 mm) at a random position within the
+  drawing range (1000 mm x 300 mm)
+\item
+  The system will be reset again
+\item
+  Then in a random order, at least different from the order of squares,
+  a circle of 55m diameter has to be drawn in the squares.
+\end{itemize}
+
+If this is not the case the test fails.
+
+\hypertarget{linearity}{%
+\subsection{Linearity}\label{linearity}}
+
+\emph{Specifications:} 1, 2, 3, 4
+
+The system must draw a grid on the drawing range (1000 mm x 300 mm),
+with the horizontal and vertical lines spaces 100 mm from each other.
+The distance between two horizontal or two vertical lines cannot be
+smaller than 90 mm. The lines are not allowed to deviate more than 10 mm
+in a line section of 300 mm
+
+\hypertarget{type-setting}{%
+\subsection{Type setting}\label{type-setting}}
+
+\emph{Specifications:} 1, 2, 3, 4, 6, 7, 11, 12, 13, 14, 15.
+
+To test the complete writing abilities the following text must be
+written on the board:
+
+\begin{verbatim}
+the quick brown fox jumps over the lazy dog!?@,.-
+0123456789101112131415161718192021222324252627282
+THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG!?@,.-
+0123456789101112131415161718192021222324252627282
+the quick brown fox jumps over the lazy dog!?@,.-
+\end{verbatim}
+
+This is a full 250 character area. It must be readable and write all the
+characters correctly. It must be completed withing 250 seconds. Which is
+4 minutes and 10 seconds.
+
+\hypertarget{wiping}{%
+\subsection{Wiping}\label{wiping}}
+
+\emph{Specifications:} 8, 10, (5 if type setting test passes)
+
+The complete board must be cleared of any marking within 60 seconds.
+This is without the change of tool.

report.tex

@@ -1,5 +1,5 @@
 %&tex
-\documentclass[english,titlepage,nomath]{siltex-report}
+\documentclass[english,titlepage,nomath,nopackage,oneside]{siltex-book}
 \include{include/preamble}
 
 \title{Title}
@@ -244,5 +244,8 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
 \chapter{Conclusion}
 \label{chap:conclusion}
 
+\appendix
+\input{content/system_test_specification.tex}
+
 \printbibliography
 \end{document}