Merge branch 'experiment' into 'master'

Experiment

See merge request horlingsw/master-assignment-report!14

.gitlab-ci.yml

@@ -2,7 +2,6 @@
 ---
 stages:
   - typeset
-  - rro
 
 variables:
   GIT_SUBMODULE_STRATEGY: recursive
@@ -12,13 +11,10 @@ final_report:
   image: registry.gitlab.com/silkeh/latex:latest
   script:
     - apk update; apk add make
-    - make
-    - mkdir tmp
-    - mv RichReportOutline.rro tmp/
+    - make -j
   artifacts:
     paths:
       - report.pdf
-      - tmp/RichReportOutline.rro
   only:
     refs:
       - web
@@ -30,21 +26,3 @@ final_report:
       - report.tex
       - content/*.tex
       - graphics/*.tex
-
-rro:
-  stage: rro
-  dependencies: 
-    - final_report
-  image: registry.gitlab.com/silkeh/latex:latest
-  script:
-    - latexmk -xelatex include/RichReportOutline.tex
-  artifacts:
-    paths:
-      - RichReportOutline.pdf
-  only:
-    refs:
-      - web
-      - branches
-      - tags
-    changes:
-      - tmp/RichReportOutline.rro

content/analysis.tex

@@ -44,11 +44,8 @@ The steps that are introduced by \ridm are covered in more detail.
         To find the best solution it is important to explore the different solutions and design space.
         Often, there are many possible alternatives but they must be narrowed down to the solutions that fit within the schedule and available resources.
         The best alternative is materialized in a design document together with the system requirements.
-        To verify that the system works in line with the system requirements, a test protocol is written for the system.
-        This protocol explains how the tests are preformed and what the pass conditions are.
         This design document is used in the next phase of the design.
 
-
 \section{Rapid Iterative Design Method}
     From this point, the design plan is based on the \ridm and not anymore on the waterfall model.
     The first step is the feature definition, which prepares the required features based on the initial design.
@@ -56,13 +53,20 @@ The steps that are introduced by \ridm are covered in more detail.
     The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature.
     During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step.
 
-    The second step is the feature selection, where one of the features is selected. 
-    This selection is based on the dependencies, risk, and time requirements in the feature definitions.
-    The third step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design, a minimal implementation and tests.
-    In the last step, the variable detail approach is used to add detail to the minimal implementation over multiple iterations.
+    Based on the requirements of \ridm as explained in \autoref{chap:background}, the next step is the feature selection.
+    However, it became apparent that the number of tests related to a specific feature is a good metric for the selection step.
+    Because, at the point that a feature is implemented, the tests are completed as well, and when the tests of the complete system pass, the system meets the specifications.
+    Following the \ridm, these tests are specified at the start of the rapid development cycle.
+    This makes it impossible to use the tests during the feature selections.
+    Therefore, a test protocol step is added after the feature definition and before the feature selection step.
+
+    The third step is the feature selection, where one of the features is selected. 
+    This selection is based on the dependencies, tests, risk, and time requirements in the feature definitions.
+    The fourth step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design and a minimal implementation.
+    In the last step, the variable detail approach is used to add detail to the minimal implementation over the course of multiple iterations.
     The tests are used to determine if the added detail does not introduce any unexpected behavior.
     This cycle of adding detail and testing is repeated till the feature is fully implemented.
-    From this point, the \ridm is repeated from the second step until all features are implemented.
+    From this point, the \ridm is repeated from the third step until all features are implemented.
 
 \subsection{Feature Definition}
     \label{sec:featuredefinition}
@@ -71,9 +75,6 @@ The steps that are introduced by \ridm are covered in more detail.
     To achieve these short cycles, the features that are implemented in these cycles, are as small as possible. 
     However, the features must still be implemented and tested individually during the implementation and can thus not be split indefinitely.
     Together with the definition of the features, the requirements are divided along the features as well.
-    During the initial design, a test protocol is made to evaluate the system-wide specifications.
-    For the feature requirements, tests are added to the test protocol as well.
-    These tests only require the corresponding feature to be implemented and must all pass to finish the implementation of the feature.
     The optimal strategy on splitting features and specifications is strongly dependent on the type of system.
     Therefore, the best engineering judgement of the developer the best tool available.
 
@@ -95,7 +96,14 @@ The steps that are introduced by \ridm are covered in more detail.
     Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected.
     This is not directly a problem, but a good administration of the requirements makes an update of these requirements easier. 
 
-
+\subsection{Test protocol}
+    \label{sec:systemtesting}
+    During the rapid development cycle and the variable detail approach, the system is tested constantly.
+    This is to make sure that the design still performs as expected.
+    The tests are based on the specifications.
+    Each specification must be covered with at least one test.
+    The tests consist of a description which specifies how to perform the test and what the result of the test must of must not be.
+    Together with the description, there is a list of required features to perform the test and a list of specifications that are met if the test passes.
 
 \subsection{Feature Selection}
     \label{sec:feature_selection}
@@ -194,15 +202,6 @@ The electrical motors have also internal states, but store significantly less en
 An basic model would in this case only consists of the arms, possibly even without any dynamic behavior.
 The dynamic behavior, motor characteristics, resistance, or gravitational force are examples of detail elements that can be added to increase the detail.
 
-Now with initial design and the basic model, all that is left is to describe a list of tests.
-The goal of these tests is to verify if the design meets the specifications of the feature.
-The tests have a short description on how to perform the tests and what should be achieved.
-It is important that all the specifications are covered by at least one test.
-This relatively simple approach of testing is possible due to the limited scope of this thesis.
-For a complexer design, the testing needs to be automated.
-The \ac{amt} \autocite{jansen_automated_2019} is an interesting method to perform the testing of the models.
-However, at the time of writing, the software is in a proof of concept state and not usable for this thesis.
-
 \subsection{Variable Detail Approach}
 With the variable detail approach the basic model is developed into a refined model of the feature.
 This is done by implementing the detail elements over the course of multiple iterations.
@@ -233,7 +232,7 @@ The developer must evaluate if there are feasible alternatives left for this ele
 When all detail elements are implemented and the basic model has evolved into a refined model of the feature, the design cycle moves back to the feature selection.
 In the case that this is the last feature to implement, this concludes the development.
 
-\section{Summation}
+\section{Summary of Design Plan}
 \begin{marginfigure}
     \centering
     \includegraphics[width=6cm]{graphics/design_flow_analysis.pdf}
@@ -241,11 +240,12 @@ In the case that this is the last feature to implement, this concludes the devel
     \label{fig:design_plan_analysis}
 \end{marginfigure}
 The waterfall model from \ac{se} and the \ridm \autocite{broenink_rapid_2019} are combined to create the design plan as shown in \autoref{fig:design_plan_analysis}.
-The first four steps of the design process form the preparation phase: problem description, specifications, initial design, and feature definition.
+The first five steps of the design process form the preparation phase: problem description, specifications, initial design, feature definition, and test protocol.
 The initial design step creates a holistic design based on the prior problem description and specifications step.
 The last step of the preparation is the feature definition, where the initial design is split into different features.
 The resulting initial design and its features together form the design proposal for the development steps.
-The development step consists of the feature selection, rapid development, and variable detail steps.
+The last step of the preparation phase is the test protocol step, where the tests are defined to monitor the design process and validate that the system meets the specifications.
+The development cycle consists of the feature selection, rapid development, and variable detail steps.
 These three steps are applied to each feature in the initial design individually.
 
 With each iteration of the development cycle a new feature is added to the complete system.

content/appendix_specifications.tex

@@ -0,0 +1,16 @@
+%&tex
+\chapter{System Specifications}
+    \begin{specification}
+        \begin{enumerate}
+            \setlength{\itemsep}{10pt}
+                \input{content/input/speclista.tex}
+                \input{content/input/speclistb.tex}
+                \input{content/input/speclistc.tex}
+        \end{enumerate}
+    \end{specification}
+
+    \begin{table}
+        \caption{}
+        \label{tab:compare}
+        \includegraphics[width=0.8\linewidth]{graphics/compare_table.pdf}
+    \end{table}

content/appendix_test_cases.tex

@@ -0,0 +1,158 @@
+\chapter{Test Specifications}
+\label{app:test_specification}
+\setcounter{testcounter}{0}
+
+    \begin{test}[label={test1}]{Small rectangle}
+        \input{content/input/systemtest1.tex}
+    \end{test}
+
+    \begin{test}[label={test_perimeter}]{Perimeter}
+        The Cable bot must move along the outer edges of the text area.
+        This area consists of three lines of text with fifty characters each.
+        Resulting in a perimeter of \SI{1000}{\milli\meter} wide and \SI{250}{\milli\meter} high.
+        This proves that reach of the system is sufficient to write the text.
+        Furthermore, the Cable bot should move outside of the perimeter as well.
+        Moving outside of the text area is to prove that Cable bot has a position where it does not obstruct the written text.
+        \tcbline
+        \begin{description}
+            \item[Features:] Cable Bot
+            \item[Specifications:] 1, 2, 6, 11, (12)
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item The Cable bot moved along the edge of the text area.
+                    \item The Cable bot moved outside of the text area.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+    
+    \begin{test}[label={test_speed_carriage}]{Cable Bot Speed}
+        The Cable bot must be able to move a distance of \SI{80}{\milli\meter} in horizontal direction within a second. 
+        At the start and the end of the movement the speed of the Cable bot must be zero.
+        This is to ensure that the SCARA can then write three characters at the given position.
+        \tcbline
+        \begin{description}
+            \item[Features:] Cable Bot
+            \item[Specifications:] 7, 9, (12), 14, 15, 16
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item At the start and end of the test, the Cable bot does not move relative to the board.
+                    \item During the test, the Cable bot has moved \SI{80}{\milli\meter} within \SI{1}{\second}.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+
+    \begin{test}[label={test_triple_char}]{Triple Chars}
+        The SCARA together with the end-effector must write 3 characters without
+        moving the Cable bot. This extends on the small rectangle of \autoref{test1} 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.
+
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA, End-Effector
+            \item[Specifications:] 3, 4, (12), 13, 14
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item The SCARA wrote three characters on the whiteboard within \SI{2}{\second}.
+                    \item The Cable bot did not move more than \SI{10}{\milli\meter}.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+    
+    \begin{test}[label={test_tool_change}]{Tool Change}
+        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.
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA, End-Effector
+            \item[Specifications:] (5), (12), 17
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item A tool is released from the end-effector and stored for later use.
+                    \item A different tool is attached to the end-effector.
+                    \item The tool switch is completed within \SI{10}{\second}.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+
+    \begin{test}[label={test_repeat}]{Repeatability}
+        \input{content/input/systemtest6.tex}
+    \end{test}
+    
+    \begin{test}[label={test_linear}]{Linearity}
+        The system must draw a grid on the drawing range (\SI{1000}{\milli\meter} x \SI{300}{\milli\meter}), with the horizontal and vertical lines spaces \SI{100}{\milli\meter} from each other.
+        The distance between two horizontal or two vertical lines cannot be smaller than \SI{90}{\milli\meter} or larger than \SI{110}{\milli\meter}. 
+        The lines are not allowed to deviate more than \SI{10}{\milli\meter} in a line section of \SI{300}{\milli\meter}.
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA, End-Effector, Cable Bot
+            \item[Specifications:]  1, 2, 3, (12)
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item All lines are drawn, 11 vertical and 4 horizontal lines.
+                    \item All lines in parallel separated from their neighbor by atleast \SI{90}{\milli\meter} and atmost \SI{110}{\milli\meter}.
+                    \item Each line does not deviate more than \SI{10}{\milli\meter}.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+    \begin{test}[label={test_writing}]{Writing}
+
+        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!?@,.-
+\end{verbatim}
+
+        This is a full 150 character area. It must be readable and write all the
+        characters correctly. It must be completed withing 150 seconds. Which is
+        2 minutes and 30 seconds.
+
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA, End-Effector, Cable Bot
+            \item[Specifications:] 1, 2, 3, 4, (5), 6, 7, 12, 13, 14, 15, 16
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item The text as described is readable from a atleast \SI{4}{\meter} distance.
+                    \item The text is writen on a clean whiteboard within \SI{150}{\second}.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+    \begin{test}[label={test_wiping}]{Wiping}
+        The complete board must be cleared of any marking within 60 seconds.
+        This is without the change of tool.
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA, End-Effector, Cable Bot
+            \item[Specifications:] (5), 10, 11, 12
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item The system cleaned the board within \SI{60}{\second}.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+    \begin{test}[label={test:compexity}]{Complexity}
+        The last test is that the design has to be complex enough.
+        This has to be evaluated by the developer of the system.
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA, End-Effector, Cable Bot
+            \item[Specifications:] 8
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item The developer can motivate that the system is complex enough to evaluate the case study.
+                \end{itemize}
+        \end{description}
+    \end{test}
+
+        

content/case_experiment.tex

@@ -1,3 +1,40 @@
 %&tex
-\chapter{case experiment}
-\label{case_experiment}
+\chapter{Case Study: Execution}
+\label{chap:case_experiment}
+This chapter presents the execution of the case study.
+Where the goal of the case study is to evaluate the design plan as presented in \autoref{chap:analysis}.
+To achieve this goal, I develop a system according to the design plan and document this design process.
+As described in \autoref{sec:sod}, the system to be designed is a "Tweet on a Whiteboard Writer".
+Documenting the process is done by following the evaluation protocol as described in \autoref{sec:evaluation_protocol}.
+To start the case study unbiased, during the preparation I did perform as little preliminary research as possible on the design options of the whiteboard writer.
+
+The chapter begins with the section about the preparation phase, which contains the four corresponding design steps as shown in \autoref{fig:design_plan_analysis}.
+This is followed by two completed development cycles in the later two sections.
+Both of these sections cover the three steps that are shown in \autoref{fig:design_plan_analysis}.
+Each design step is described in a separate subsection.
+Herein, the result of the design step is presented and concluded with an evaluation section at the end.
+This evaluation section discusses the pairs of questions that were answered according to the evaluation protocol (\autoref{tab:prepost}).
+The questions regarding the design method itself are discussed in \autoref{chap:reflection}.
+
+\section{Preparation Phase}
+The preparation phase contains four design steps.
+It begins with a problem description.
+This description is detailed into a list of specifications.
+Based on the specifications, a number of design solutions proposed and eventually one of these solutions is chosen as initial design.
+Splitting the initial design into features is done in the feature definition step.
+
+\input{content/case_experiment_problem_description.tex}
+\input{content/case_experiment_specifications.tex}
+\input{content/case_experiment_initial_design.tex}
+\input{content/case_experiment_feature_definition.tex}
+\input{content/case_experiment_test_protocol.tex}
+
+\section{First Development Cycle}
+\input{content/case_experiment_end-effector.tex}
+
+\section{Second Development Cycle}
+\input{content/case_experiment_scara.tex}
+
+\section{System Design Validation}
+\input{content/case_experiment_prototype.tex}
+

content/case_experiment_end-effector.tex

@@ -0,0 +1,108 @@
+With the preparation phase completed, the development cycle is next.
+This consists of three steps: Feature selection, Rapid Development and Variable Approach.
+The current section explains the first development cycle during the design.
+For this first cycle of the design process, I design the end-effector.
+However, not long after the start of the development process, the implementation proved to be too complex.
+This led to the decision to abort the implemention of the end-effector.
+Eventhough no progress was made, this attempted implementation did provide valuable insight in the desing process.
+
+    \subsection{Feature Selection}
+        \label{sec:case_feature_selection_1}
+        \begin{table}[]
+            \caption{Overview of the different features and their dependencies, number of tests that are covered and the risk/time factor.
+            The risk/time factor is calculate as risk divided by time.}
+            \label{tab:firstfeatureselection}
+            \begin{tabular}{|l|l|l|l|l|l|}
+                \hline
+                Feature      & Dependees   & Tests  & Risk   & Time    & Risk/Time  \\ \hline
+                \ac{scara}        & -           & 3      & 40\%   & 10 days & 4          \\ \hline
+                End-effector & \ac{scara}       & 2      & 60\%   & 8 days  & 7.5        \\ \hline
+                \ac{cdc}     & -           & 2      & 30\%   & 10 days & 3          \\ \hline
+            \end{tabular}
+        \end{table}
+        For each feature in the system the dependees, tests and risk/time factor is determined, as explained in \autoref{sec:feature_selection}.
+        These values are combined into \autoref{tab:firstfeatureselection}.
+
+        The \ac{scara} depends on the end-effector, as explained in the initial design.
+        However, for the \ac{cdc} no dependency was defined even though it has to lift the other two components.
+        This is mainly because the torque and range requirements of the \ac{scara} depending on the implementation of the end-effector.
+        Especially the required range depends on the method of grabbing and releasing tools.
+        For the \ac{cdc} 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 apply to that feature.
+        The risk and time values are not determined with a specific protocol, but with simple engineering judgement.
+        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 \ac{scara} has the most moving parts, but no difficult dynamics and has therefore an estimated risk of medium.
+        For the \ac{cdc} there was no real risks and got therefore a low risk indication.
+        
+        Based on \autoref{tab:firstfeatureselection}, the end-effector is implemented first.
+        The end-effector has the most dependees, and is therefore chosen above the other two.
+
+        \subsubsection{Evaluation}
+            This first step of the detail design phase did go well.
+            Although risk and time assessment is always depend on some engineering judgment, this human factor introduces uncertainty in the assessment.
+            However, an improved approach for the risk assesment can drastically reduce this human factor.
+            Within a design team a form of planning poker \autocite{grenning_planning_2002} could be a good option.
+        
+    \subsection{Rapid Development of the End-Effector}
+        This section explains the process of the development of the end-effector.
+        The first step is to create an initial design of the model.
+        In subsequent steps, detail is added to this model.
+
+        The previous section explained the relative high risk assessment  for the end-effector.
+        Which was not exaggerated as the implementation proved to be troublesome.
+        Eventually, the implementation was unfeasible and was therefore cut short.
+        Nonetheless did it result in useful evaluation points on the design method.
+        The process of this step is explained in the following sections.
+
+
+        The development starts with an initial design of the system.
+        The next step is to develop that further into a model and prototype.
+        This development did not get past the basic model implementation due to unforeseen difficulties.
+        However, the evaluation gave new useful insight on the design plan.
+
+        \subsubsection{Initial design}
+            The end-effector is mounted on the \ac{scara} and acts as an interface.
+            With the end-effector, the \ac{scara} is able to grab and release tools.
+            There are multiple approaches to handle these tools.
+            However, there is a trade-off to be made with the \ac{scara} feature, the heavier the end-effector is, the more force the \ac{scara} must deliver.
+            And because the goal is to make the \ac{scara} light and quick, this end-effector must be light-weight as well.
+            The best options in this case is a simple spring-loaded clamp.
+            To release the tool, the clamp is forced open, pushing it against the holder.
+            As the end-effector is connected to the \ac{scara}, the \ac{scara} is responsible for the pushing force.
+            Because the actuation force of the \ac{scara} is used, it removes the need for an additional servo in the end-effector.
+            Resulting in a simpler and lighter design.
+            The initial design of the clamp and the operation is shown in \autoref{fig:gripper}. 
+            Although this design requires the \ac{scara} to deliver more force.
+            The relative low mass of the end-effector also keeps the moment of inertia small.
+            Therefore, the current design reduces the impact on the acceleration of the \ac{scara} to a minimum.
+            \begin{figure*}
+                \centering
+                \includegraphics[width=151mm]{graphics/end-effector.pdf}
+                \caption{Operation of the end-effector. The clamp is forced open against the holder to release the marker.
+                Instead of releasing, the marker is grabbed by reversing the order of executing for these steps.}
+                \label{fig:gripper}
+            \end{figure*}
+
+        \subsubsection{Behavior Modelling}
+            The next step is to implement this design with the corresponding behavior in a dynamic model.
+            The challenge in this case is the modelling of the contact dynamics.
+            Based on some experience in modelling with collisions, I decided to use the 20-sim 3D mechanics editor.
+            Unfortunately, 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 system freeze caused the model to corrupt, where the complete configuration of the shapes and their collisions was lost.
+            Based on the loss of work and the low feasibility of the implementation, the decision was made to remove the end-effector from the design.
+
+            With the end-effector removed, the \ac{scara} gets a direct connection with the marker.
+            The lifting of the marker from the is included in the \ac{scara} as well.
+            Furthermore, this means that the erasing is no longer possible as a feature.
+
+        \subsubsection{Evaluation}
+            The lost progress of the model is unfortunate, but the implementation did not go as 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.

content/case_experiment_feature_definition.tex

@@ -0,0 +1,60 @@
+%&tex
+\subsection{Feature Definition}
+    \label{sec:case_featuredefinition}
+    At this point there are specifications and an initial design for the system.
+    In the following steps of the design method features will be implemented one by one.
+    The goal of this step is to define those features.
+    However, the predefined approach was not able to produces a set of features that could be implemented.
+    This forced me to create a new approach for this step, introducing components into the design.
+    This section will first address why the current approach is not suitable, followed by the alternative approach.
+
+    \subsubsection{Struggles with Features}
+        For their case study, \textcite{broenink_rapid_2019} design a control system for a mini-segway.
+        This mini-segway is an already existing \ac{cps} that is used during the lab-sessions of a control course, and any control-law can be uploaded directly to the system.
+        The specified features of that system are defined as:
+        \begin{enumerate}
+            \item Balancing the mini-segway upright
+            \item Steering the mini-segway
+            \item Driving forward and backward
+        \end{enumerate}
+        Although this is not explicitly explained, these features have dependencies: the steering and the driving both rely on a balanced segway.
+
+        A set of features for the Whiteboard writer would be:
+        \begin{enumerate}
+            \item Write character on position
+            \item Move carriage to position
+            \item Write text
+        \end{enumerate}
+        In this case, features 1 and 2 are required for feature 3.
+        However, in contrast with the mini-segway, the whiteboard writer does not exist yet.
+        Instead of creating a model based on the system, the system has to be designed first.
+        For these three features, the required hardware can be designed together with the feature.
+        The first feature would then also contain the design of the SCARA and the second feature the cable bot design.
+        Adding the features needed to meet the specifications for wiping the whiteboard, then such a feature would also need to design the SCARA.
+        In other words, more than one feature uses the SCARA in their behavior.
+        Resulting in the question: which feature should implement the hardware?
+
+    \subsubsection{Separating Functions and Components}
+        It was decided not to add the SCARA and the cable bot as features, for the reason that they do not define behavior.
+        Instead, the features define how the hardware behaves.
+        A solution to organize the relations between features and components was found in RobMoSys \autocite{noauthor_robmosys_2017}.
+        RobMoSys defines a separation of levels in a design.
+        Where the levels start functional and moves via software to hardware implementation.
+        Although not all levels of RobMoSys are used, it was very useful to define the features of the system.
+        The definition is shown in \autoref{fig:robmosys}.
+        The current definition of features allows to start the implementation with a component.
+        When the component is finished features can be implemented by following the tree upwards.
+        \begin{figure*}
+            \centering
+            \includegraphics[width=0.85\linewidth]{graphics/robmosys}
+            \caption{Feature Definition based on the separation of levels introduced by RobMoSys}
+            \label{fig:robmosys}
+        \end{figure*}
+
+    \subsubsection{Evaluation}
+        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 clear separation between features and components.
+        And the single level of components makes it impossible to depict the dependencies between components.
+        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.

content/case_experiment_initial_design.tex

@@ -0,0 +1,193 @@
+%&tex
+    \subsection{Initial design}
+    \label{sec:initialdesign}
+        The initial design started with a design space exploration.
+        The goal was to collect possible solutions and ideas for the implementation.
+        The exploration resulted in a lot of whiteboard writing robots ideas.
+        These robots can be sorted in four different configurations
+        Each configuration explained in the following sections.
+        From the possible configurations, the one that fits the specifications best, is made into an initial design.
+        
+        \subsubsection{Cable-Driven}
+            The cable-driven robot is suspended with multiple cables.
+            The end-effector that contains the marker is moved along a board by changing the length of the cables.
+            The cable-based positioning systems result in an end-effector with a large range and high velocities.
+            A basic setup can be seen in \autoref{fig:cablebotdrawing}.
+            This given setup contains two cables that are motorized.
+            The big advantage of this system is that it scales well, as the cables can have almost any length.
+            \begin{figure}
+                \centering
+                \includegraphics[width=10.8cm]{graphics/cablebot.pdf}
+                \caption{Planar view of cable driven robot. This setup contains two motorized pulleys in both top corners. From these two cables a mass is suspended at position $x,y$.
+                By changing the length of the cables, the mass can be moved over along the whole board.}
+                \label{fig:cablebotdrawing}
+            \end{figure}
+            \begin{marginfigure}
+                \centering
+                \includegraphics[width=3.74cm]{graphics/cable_angle.pdf}
+                \caption{Illustrating the limit for pure horizontal acceleration $a$, for different angles to compensate for gravitational acceleration $g$.
+                The red arrow represents the acceleration as a result of the pulling force of the cable, which is vectorized in a vertical acceleration that compensates $g$ and a vertical acceleration $a$.}
+                \label{fig:cable_angle}
+            \end{marginfigure}
+
+            Although it is possible to achieve high velocities, this system is limited by the gravitational acceleration.
+            In case of vertical acceleration, the maximum downward acceleration or upward deceleration is limited by \SI{9.81}{\meter\per\second\squared}.
+            The horizontal acceleration depends on the relative angle of the suspending cable.
+            The closer the end-effector is below the cable pulley, the lower the pure horizontal acceleration becomes.
+            \autoref{fig:cable_angle} illustrates the horizontal acceleration for different angles.
+            
+            A possible solution to this is to add one or two additional wires to the system.
+            These can pull on the system to 'assist' the gravitational force.
+            Depending on the implementation, the extra cables make the system over-constrained.
+            Nevertheless, the extra cables allow for higher acceleration limits in vertical and horizontal direction.
+
+        \subsubsection{Cartesian-coordinate robot}
+            This configuration is a very common design for plotters and shown in \autoref{fig:plotter}.
+            This setup is also known as a gantry robot or linear robot.
+            It normally consists of two sliders, which behave as a prismatic joint. 
+            Because each slider covers a single X or Y axis, the control and dynamics of this system are rather simple.
+            The biggest challenge is in the construction of the system, especially when the size of the system is increased.
+            The larger system requires bigger length sliders, which are expensive. 
+            Another difficulty is the actuation of both horizontal sliders, if these sliders do not operate synchronous, the vertical slider rotates.
+            However, the construction of the slider is not able to rotate, resulting in damage to the system.
+            \begin{figure}
+                \centering
+                \includegraphics[width=8.74cm]{graphics/plotter.pdf}
+                \caption{This Cartesian plotter consists of two horizontal sliders to provide the $x$-movement and one vertical slider to provide the $y$-movement.}
+                \label{fig:plotter}
+            \end{figure}
+            
+        \subsubsection{Polar-coordinate robot}
+            This robot is a combination of a prismatic and a revolute joint.
+            Where the revolute joint can rotate the prismatic joint as seen in \autoref{fig:polar}.
+            With this it can reach any point within a radius from the rotational joint.
+            This is a little more complex design than the Cartesian robot.
+            \begin{figure}
+                \centering
+                \includegraphics[width=8.74cm]{graphics/polar.pdf}
+                \caption{A combination of a revolute joint and a prismatic joint, creating a polar-coordinate robot.}
+                \label{fig:polar}
+            \end{figure}
+            \begin{marginfigure}
+                \centering
+                \includegraphics[width=3.74cm]{graphics/polar_protrude.pdf}
+                \caption{The diagonal lined section shows the part of the protruding area that is used by the arm.}
+                \label{fig:polar_protrude}
+            \end{marginfigure}
+
+            This robot has multiple disadvantages.
+            The range of the robot is defined by the length of the prismatic joint.
+            Thus when the operating range is doubled, the robot size has to be doubled or even more than that.
+            Furthermore, when the arm of the robot is retracted, it protrudes on the other side.
+            Therefore, the complete radius around the revolute joint cannot have any obstacles.
+            \autoref{fig:polar_protrude} gives an impression of the required area.
+            Even with this area, the arm cannot reach the complete board.
+            This makes required space of the setup very inefficient.
+            Another disadvantage is that a long arm increases the moment of inertia and the gravitational torque on the joint quadratically.
+            Furthermore, the long arm introduces stiffness problems and it amplifies any inaccuracy in the joint.
+        
+        \subsubsection{SCARA}
+            The SCARA robot is a configuration with two linkages that are connected via rotational joints.
+            It can be compared to a human arm drawing on a table as seen in \autoref{fig:scara}.
+            Similar to the Polar robot it can reach all points within a radius from the base of the robot.
+            But the SCARA does not protrude like the polar arm (\autoref{fig:polar_protrude}).
+            Depending on the configuration of the arm, it is possible to keep the arm completely within the area of operation.
+            A downside is that the mass of the additional joint and extra arm length increase the moment of inertia and gravitational torque similar to the polar robot.
+            This makes the SCARA configuration convenient for small working areas as that keeps the forces managable.
+            Additionally, as the arms of the SCARA have a fixed length, it is possible to create a counter balance.
+            This can be used to remove any gravitational torque from the system. It would however increase the moment of inertia even further.
+            For current specifications, the working area is too large for any practical application of the SCARA.
+            \begin{figure}
+                \centering
+                \includegraphics[width=8.74cm]{graphics/scara.pdf}
+                \caption{Schematic example of a SCARA, consisting of two rotation linkages. This setup can be compared to a human arm, where the gray base above the whiteboard represents the shoulder and the connections between both linkages the elbow.}
+                \label{fig:scara}
+            \end{figure}
+
+        \subsubsection{Choice of system}
+            The previous sections have shown four different configurations.
+            These configurations are compared in \autoref{tab:initial_design}.
+            Each of the systems are scored on range, speed, cost, obstruction, effective area, and the interesting dynamics:
+            \begin{description}
+                \item{\emph{Range}}\\
+                    The range scores the system on the practical dimension of the system, larger is better.
+                    The cable and cartesian configuration scale very well, the cables or slider rails can be made longer without real difficulty.
+                    The SCARA or polar configuration run into problems with the arm lengths, as forces scale quadratically with their length.
+                \item{\emph{Speed}}\\
+                    Except for the cable bot, all configurations score sufficient on speed.
+                    The cable bot can reach high velocities, but the acceleration is limited, depending on the configuration, to the gravitational acceleration.
+                \item{\emph{Cost}}\\
+                    For the cost, all systems fit within the €200 budget, except for the Cartesian setup.
+                    All systems require DC or stepper motors, but the cartesian setup also requires linear sliders which are expensive, especially for longer distances.
+                \item{\emph{Obstruction}}\\
+                    The obstruction score depends on the capability of the system to move away from the text on the board, such that the system does not obstruct the written tweet.
+                    All systems except for the cable bot can move themself outside of the working area.
+                    It is possible that the cables of the cable bot obstruct the view.
+                    However, the wires are expected to be thin enough to not block any text.
+                \item{\emph{Scalability}}\\
+                    For the scalability, only the cable bot scores high. 
+                    The cables make it possible to easily change the operating range of the system, only requiring reconfiguration.
+                    The cartesian system scales poor because the length of the sliders is fixed, and longer sliders are expensive.
+                    For the Polar system and SCARA, the forces on the joints scale quadratically with the length of the arms.
+                    However, the SCARA can be build with counter balance making it scale less worse than the Polar system.
+                \item{\emph{Effective Area}}\\
+                    With the effective area, the system is scored on the area it requires to operated versus the writable area.
+                \item{\emph{Interesting Dynamics}}\\
+                    The last metric, scores the system on the complexity of the dynamics.
+                    This is a more subjective metric, but also a very important one.
+                    In the problem description, the complexity of the dynamics was determined as one of the core requirements.
+                    The cartesian configuration is trivial, both sliders operate completely separate from each other and the position coordinates can be mapped one to one with the sliders.
+                    For the other configuration, some inverse kinematics are required to get from desired position to the control angles of the system.
+            \end{description}
+
+            \begin{table}[]
+                \caption{Table with comparison of the four proposed configurations and a combined configuration of the cable bot and the SCARA.}
+                \label{tab:initial_design}
+                \begin{tabular}{l|l|l|l|l|l|}
+                    \cline{2-6}
+                    & Cable bot & Cartesian & Polar & SCARA & Combined \\ \hline
+                    \multicolumn{1}{|l|}{Range}                                                          & + +      & +         & - -   & -     & + +      \\ \hline
+                    \multicolumn{1}{|l|}{Speed}                                                          & -        & +         & +     & + +   & +        \\ \hline
+                    \multicolumn{1}{|l|}{Cost}                                                           & + +      & - -       & +     & +     & +        \\ \hline
+                    \multicolumn{1}{|l|}{Obstruction}                                                    & -        & +         & +     & +     & -        \\ \hline
+                    \multicolumn{1}{|l|}{Scalability}                                                    & + +      & -         & - -   & -     & +        \\ \hline
+                    \multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Effective\\ area\end{tabular}}       & + +      & +         & - -   & +     & + +      \\ \hline
+                    \multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Interesting\\ dynamics\end{tabular}} & -        & - -       & -     & +     & + +      \\ \hline
+                \end{tabular}
+            \end{table}           
+            
+            Based on this comparison, I disqualified the cartesian and polar system.
+            The cartesian has no interesting dynamics and is expensive to build at the current scale.
+            The polar system is just not feasible, the arm length required to cover the writing area results forces that are too large.
+            Making a rotational joint that delivers the torque and velocity required for such an arm, is just out of the scope of this case study.
+            The two remaining configurations come with serious downsides as well.
+            The cable bot is slow, and the arm length for the SCARA is also likely to cause problems.
+            However, by combining both, it is possible to get a system that fits the requirements very well.
+            By building a small SCARA that is the suspended by the cable bot, it combines the best of both worlds.
+            The small SCARA is quick and accurate, while the cable bot gives the system an enormous range.
+            Resulting in a system that scores high on all criteria except obstruction.
+            The grading for the combined system is shown in the most right column in \autoref{tab:initial_design}.
+
+            \begin{figure}
+                \centering
+                \includegraphics[width=10.8cm]{graphics/combined.pdf}
+                \caption{Combined system that integrates the cable bot together with the SCARA. The SCARA in red is mounted on the carriage. This carriage is then suspended by cables.}
+                \label{fig:combined}
+            \end{figure}
+            In the combined system, the SCARA will only be large enough to write a small number of characters at the time.
+            This will alternate with the cable bot moving the base of the SCARA to the next position, so that it can write the next set of characters on the whiteboard.
+            \autoref{fig:combined} shows a simple view of the system.
+
+        \subsubsection{Evaluation}
+            This was the first step that felt really productive in the design process.
+            It created a enormous amount of information and insight of the design.
+            In hind sight, it would have been useful to have this information during the specifications step.
+            However, as the specifications step are mainly on the "what" to solve, and specifically not on "how" to solve it, this information was avoided on purpose during the specifications step.
+
+            This step did result in an initial design that can be used in the next steps.
+            However, I noticed that none of the previous steps have a clear start or end.
+            For the problem description and the specification steps the question is when all required information is collected.
+            In the initial design it is always possible continue researching design options to come up with an even better design.
+            Especially with complex system, it is unrealistic to create complete specifications before making design decissions.
+            Resulting in the question: at what point do we have enough information and must we move to the next design step?
+            This is also known as the \emph{requirement versus design paradox} \autocite{fitzgerald_collaborative_2014}.

content/case_experiment_problem_description.tex

@@ -0,0 +1,22 @@
+%&tex
+\subsection{Problem Description}
+The problem description describes the need for a solution or system.
+In this case, I want a robot that can write a tweet on a whiteboard.
+A specific requirement is that the system must be complex enough, such that it uses sufficient aspects of the design method to be able to evaluate that design method.
+The system must meet the following requirements:
+\begin{itemize}
+    \item Write a twitter message, or tweet, on a whiteboard.
+    \item Remove the tweet from the whiteboard.
+    \item Write the tweet within three minutes on the board.
+    \item The text must be readable across a meeting room.
+    \item The solution must contain interesting dynamics.
+\end{itemize}
+
+\subsubsection{Evaluation}
+The problem description is very brief, which is not a complete surprise.
+As most of the work for the problem description was already done by choosing the subject of design.
+However, it was not expected to be this minimal.
+Perhaps the most serious disadvantage is the absence of stakeholders.
+Normally, a good problem definition focusses on getting the stakeholders on the same line \autocite{shafaat_exploring_2015}.
+However, this case study does only have one stakeholder, the author, defeating the purpose getting everyone on the same line.
+Creating a more elaborate problem description would not improve the evaluation of the design process, but it does cost valuable time.

content/case_experiment_prototype.tex

@@ -0,0 +1,71 @@
+%&tex
+To validate the dynamical and mechanical models, I will build a prototype of the current design.
+For the mechanical design, the CAD model is used to print the custom parts.
+Other components, such as steppers, microcontroller, screws and miscellaneous electronics, are ordered.
+To test the dynamics, the steppers and servo have to be actuated.
+To achieve this actuation a control law is written in software.
+
+\subsection{Mechanical Construction}
+With the 3D printed parts the SCARA was easy to construct.
+The diameter of the holes in the parts were printed slightly undersized.
+This was on purpose, such that the holes can be drilled to the specified size.
+To connect the bodies on the joints, a bolt with washers is used.
+Although this is clearly not the ideal technique to build joints, it was by far the easiest option.
+
+During assembly I noticed that the bolts of a joint and those that hold the stepper motor in place collided.
+This was possible because the bolts were not included in the CAD-model.
+In hindsight this should have been included.
+Fortunately there was enough clearance to mount the SCARA slightly further on the axle.
+Resulting in an operating SCARA without having to redesign the mechanics.
+
+\subsection{Control of the SCARA}
+\begin{marginfigure}
+    \centering
+    \includegraphics[width=5cm]{graphics/electronics.pdf}
+    \caption{Hardware connections. The servo motor connected to a pwm-output. The stepper controller connected via UART and IO-pins. The stepper controller provides the correct current for the stepper motors.}
+    \label{fig:signals}
+\end{marginfigure}
+Although the focus of the design plan was specifically not the software, it still forms a important part of the development.
+To run the hardware, I chose for for a STM32 \ac{mcu}. This is a powerfull processor with sufficient IO available.
+The servo motor is directly connected to the IO of the \ac{mcu} while the stepper motor is connected via a stepper controller board, see \autoref{fig:signals}.
+RIOT-OS was chosen as an operating system due to prior experience and available support.
+To be able to write characters on the board the following tasks have to be implemented in software:
+\begin{itemize}
+    \item Driver for the stepper controller
+    \item Driver for servo motor
+    \item Inverse Kinematics
+    \item Control/Path planning
+\end{itemize}
+
+The stepper controller chip can be configured over UART and has two simple IO pins for step and direction signal.
+To simplify the control, the software driver configures the stepper controller and includes functions to move the stepper motor to a certain angle.
+Meaning that the feedforward control of the steppers is handled by the software driver class.
+The angle of the servo motor is controlled by the pulse length of a square wave.
+This signal is generated in the IO peripherals as a PWM signal. 
+The software driver has a toggle function that changes the pulse length. Making the maker lift from or lower on the board.
+The code for the servo driver was already available as a module in RIOT-OS.
+\begin{marginfigure}
+    \centering
+    \includegraphics[width=2.83cm]{graphics/code_objects.pdf}
+    \caption{Simplified data flow in the software. The path planning generates a vector to the next set point. The interpolation reduces the length of this vector. With the inverse kinematics the required stepper motor angles are generated. These angles are set as new set point for the stepper driver.}
+    \label{fig:objects}
+\end{marginfigure}
+
+The path planning is able to write three characters with the SCARA.
+The font for the characters is made by \textcite{hudson_asteroids_2015}.
+This font consists of a simple coordinates for characters and is written in C.
+The path planning is updated with a fixed interval.
+During the update, the set point is linearly interpolated, otherwise the lines are curved between set points.
+To get the angle set points for the stepper motors, the $x,y$-coordinate set point is converted using the inverse kinematics.
+The inverse kinematics is analogous to the model that is used in the development cycle of the SCARA.
+The angle set points are updated for the stepper driver.
+The data path is shown in \autoref{fig:objects}.
+
+The stepper driver has a feedforward controller.
+The driver limits the acceleration and speed to keep the motor within operating specifications and keeps track of the current status of the stepper motor.
+When the angle set point is updated, the driver calculates the time interval between each step and sets a hardware timer to that interval.
+This allows the controller and other drivers to be executed between each step.
+This approach works only if the code executes fast enough.
+During the testing, I found that the inverse kinematics calculation was too expensive, even with the integrated floating point unit.
+As the \ac{mcu} has sufficient flash storage available, the inverse kinematics calculation is replaced by a lookup table.
+

content/case_experiment_recap.tex

@@ -0,0 +1,95 @@
+%&tex
+    \subsection{Recap}
+            During the problem definition and the specifications step it was difficult to stay within the "what" has to be solved and not go into the "how" it has to be solved.
+            Furthermore, 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.
+

content/case_experiment_scara.tex

@@ -0,0 +1,198 @@
+%&tex
+    As the previous development cycle was aborted prematurely, the development cycle is repeated for the next feature.
+    Starting with a feature selection process. Followed by the rapid development.
+    
+
+    \subsection{Feature Selection}
+        The implementation of the end-effector proved to be unfeasible and was therefore removed from the design.
+        This means that only two features are left.
+        \autoref{tab:featurestab2} shows an updated feature comparison.
+        Compared with the previous feature selection in \autoref{tab:firstfeatureselection}, the number of tests for the \ac{scara} decreased and the Risk/Time increased.
+        This is because \autoref{test_tool_change} relied on both the \ac{scara} and the End-effector which is no longer applicable.
+        Based on the feature comparison, the next component to implement is the \ac{scara}.
+
+        \begin{table}[]
+            \caption{Comparison of the two remaining features in the design process. This table is an updated version of \autoref{tab:firstfeatureselection}.}
+            \label{tab:featurestab2}
+            \begin{tabular}{|l|l|l|l|l|l|}
+                \hline
+                Feature      & Dependees   & Tests  & Risk   & Time    & Risk/Time  \\ \hline
+                \ac{scara}        & -           & 2      & 50\%   & 12 days & 4.2        \\ \hline
+                \ac{cdc}     & -           & 2      & 30\%   & 10 days & 3          \\ \hline
+            \end{tabular}
+        \end{table}
+
+        \subsubsection{Evaluation}
+            The feature selection for the second cycle is an updated selection process of the first cycle (\autoref{sec:case_feature_selection_1}).
+            This resulted in a quick and effortless feature selection process, as most of the work was already done.
+
+    \subsection{Rapid Development for SCARA}
+        The goal is to present a functional model of the \ac{scara}.
+        The requirements state that it must be able to write three characters within two seconds.
+        And to pass \autoref{test1} it must draw a \SI{50}{\milli\meter} by \SI{70}{\milli\meter} rectangle within one second.
+        The basic design principle is based on the initial design as shown in \autoref{fig:combined}.
+        For the lowest detail level of the design, I decided on a kinematics model.
+        The model is very simple as it does not implement any physics.
+        However, the model enables me to tinker with the design parameters, such as the lengths of the linkages and joint angles.
+        In the following steps, the level of detail is gradually increased to arrive at a competent model.
+        Planning all the different steps in advance is difficult as design decisions still need to be made.
+        Nonetheless, I can describe at least the following levels of detail for the model:
+        \begin{enumerate}
+            \item Basic kinematics model, no physics.
+            \item Basic physics model, ideal 2D physics.
+            \item Basic Motor behavior, 2D physics with non-ideal DC-motor.
+            \item Basic control law, path planning.
+        \end{enumerate}
+        After these steps the optimal order of implementation for the levels of detail becomes vague.
+        However, the following elements are required to make a competent model:
+        \begin{itemize}
+            \item Improved motor model
+            \item 3D physics model
+        \end{itemize}
+        When the first design decisions made, the succeeding levels of detail for these and other elements are laid out.
+
+
+        \subsubsection{Evaluation}
+            The current steps in the rapid development are difficult to perform.
+            There is, unsurprisingly, lack of a clear vision of the end-product.
+            Which makes an explicit description of every level of detail not realistic.
+            However, it was still possible to describe the initial steps in the level of detail of the design.
+            The remaining elements, that are essential to the design, take shape in a later stage of the development.
+            Apart from this small deviation, the deliverables of this step are a good start of this development cycle.
+
+    \subsection{Variable Detail Approach}
+        The following steps is to increase the level of detail of the model.
+        The initial model together with the set of steps in the detail level is inherited from the previous design step.
+        To start, I implement the basic model and implement the different levels of detail.
+        Based on the model after those steps, it is possible to make more detailed design decisions.
+        The decisions make it possible to plan the subsequent levels of detail.
+        Implementing these details results in a competent model.
+
+        \subsubsection{Basic Kinematics Model}
+            \begin{marginfigure}
+                    \centering
+                    \includegraphics[width=0.9\linewidth]{graphics/scara_arm_kinematics.pdf}
+                    \caption{Basic kinematics of the \ac{scara}. The arm consists of two linkages $a$ and $b$; two joints $\alpha$ and $\beta$; and a point mass $m$ which represents the end-effector/tool.}
+                    \label{fig:scaraarm}
+            \end{marginfigure}
+            The development starts with the basic model shown in \autoref{fig:scaraarm}.
+            The model consists of the forward and inverse kinematics of the design.
+            With this kinematics model it was easy to find a suitable configuration of the \ac{scara}.
+            I tested if the \ac{scara} reaches the required operating area, to satisfy system requirement 14.
+            The operating area is a couple of centimeters away from the base of the \ac{scara}.
+            This is to avoid the singularity point that lies at the base of the \ac{scara}.
+            Resulting in longer arms than strictly necessary but reducing the operating angles of the joints, allowing for simpler construction.
+            
+            At this point, there are already multiple design decisions made about the position of the operating area and the arm lengths.
+            As second detail iteration the basic physics of the model are implemented.
+            The model is in the form of a double pendulum, with two actuated joints.
+            The ideal motors in the joints made give the \ac{scara} unlimited acceleration.
+            As the one of the goals is to get an indication on what the required torque for these joints is, the ideal motors are replaced with basic DC-motors.
+            Implementing a simple PID-controller allows the \ac{scara} to follow the rectangular path as described in \autoref{test1}.
+            The simulation allowed me to determine the minimum requirements of the motors.
+            The motors must be able to deliver at least \SI{0.2}{\newton\meter} of torque and reach an angular velocity of at least \SI{12}{\radian\per\second}.
+        
+        \subsubsection{Detailed design decisions}
+            The basic model gave some valuable insight about the dynamic behavior of the system.
+            However, the current configuration is very simple but requires a motor in the joint.
+            In \autoref{fig:scaradesign}, this setup is shown as configuration 1.
+            The disadvantage is that a motorized joint is heavy, which has to be accelerated with the rest of the arm.
+            Other configurations in \autoref{fig:scaradesign} move the motor to a static position.
+            Configuration 2 is a double arm setup, but has quite limited operating range, caused by a singularity region in the system when both arms at the top are in line with each other.
+            Configuration 3 also has such a singularity, but due to the extended top arm this point of singularity is located outside of the operating range.
+            However, this configuration requires one axis with two motorized joints on it.
+            Even though this is possible, it does increase the complexity of the construction.
+            By adding an extra linkage, the actuation is split as shown in configuration 4.
+            Configuration 4 is the preferred option for the \ac{scara}
+            \begin{figure}
+                \centering
+                \includegraphics[width=0.875\linewidth]{graphics/scara_design.pdf}
+                \caption{Four different \ac{scara} configurations. The colored circles mark which of the joints are actuated. Configuration 3 has two independently actuated joints on the same position.}
+                \label{fig:scaradesign}
+            \end{figure}
+
+            The actuation of the arm is done with stepper motors, which have a strong advantage over DC-motors with their holding torque.
+            The holding torque removes the need for a feedback controller that compensates for external forces.
+            Allowing the stepper motors to be fully operated with a feedforward controller.
+            However, they are heavier and more expensive but the additional mass is beneficial as increased inertia of the base.
+            The extra inertia reduces the displacement which is caused by the reaction force of the \ac{scara} accelerating.
+            The extra costs are easily compensated as it saves development time due to the simplified control law, and the removed need for extra angle sensors used in feedback control.
+
+            Due to the aborted implementation of the end-effector, the \ac{scara} must also lift the marker of the board.
+            With the fourth configuration (\autoref{fig:scaradesign}), it is possible to add an extra joint in the linkage.
+            As the marker only needs to be moved a couple of millimeters from the board, a simple hobby servo suffices.
+
+        \subsubsection{Advanced Detail Design}
+            The design decisions made in the previous sections, make it possible to plan the next steps of adding detail.
+            The following steps are an addition to the steps as described in the previous section:
+            \begin{enumerate}
+                \setcounter{enumi}{4}
+                \item Stepper motor behavior.
+                \item Updating physics model to 3D physics.
+                \item Marker lifting behavior, servo lifts marker of the board.
+            \end{enumerate}
+            Starting by replacing the DC-motor with a stepper motor model, which is based on a model by \textcite{karadeniz_modelling_2018}.
+            The controller is updated as well, to accommodate for the behavior of the steppers.
+            The next step is to implement a dynamic model of configuration 4 in \autoref{fig:scaradesign}.
+            The dynamics of the \ac{scara} are based on a serial link structure \autocite{dresscher_modeling_2010}.
+            This serial link structure makes it easy to add and extend joints, bodies and mass points to the system.
+            Therefore, the last detail, the marker lifting, was added without any difficulty.
+            The servo is connected via a linkage with the marker such that it rotates away from the board.
+
+        \subsubsection{Component Design}
+            At this point the development has reached a detailed design together with a dynamic model representing that design.
+            The dynamic model is a useful tool to test and evaluate the system behavior.
+            However, it does not include the shapes of the components and can therefore not be used to evaluate clearance or collision between components.
+            By implementing the design using CAD software, it is possible to inspect for collisions.
+            Furthermore, this model is than also used to print the custom parts.
+            For the mechanical part I used OpenSCAD as CAD software, based on prior experience with the software.
+            With this it was possible to implement all the custom components as well as the \ac{ots}-components.
+            Using the inverse kinematics model from the basic design of the \ac{scara}, the angles were directly applied on the components in system.
+            Allowing me to change the configuration of the \ac{scara} and inspect the clearance between each component.
+            Following the rectangular path as defined in \autoref{test1} revealed that collisions occurred between parts.
+            These collisions were resolved by adding an indentation in one linkage and moving another linkage.
+            These changes are shown in \autoref{fig:scad_clearance}
+            The complete setup with the custom parts and the \ac{ots}-components, such as stepper motors, servo and marker, is shown in \autoref{fig:scad_carriage}.
+            \begin{figure}
+                \centering
+                \includegraphics[width=0.8\linewidth]{graphics/scad_scara_circles.png}
+                \caption{
+                    CAD of the \ac{scara} configuration, with the end-effector orientated in the lower left corner of the operating area. 
+                    The configuration has been adapted at the two circled points, to resolve collisions in this orientation. 
+                    An indentation was made to ensure that the arm can make the required angle.
+                    The bottom linkage was located above the joints as depicted in the fourth configuration in \autoref{fig:scaradesign}.
+                    This was moved to below the actuated joints as it did collide with the end-effector.
+                }
+                \label{fig:scad_clearance}
+            \end{figure}
+
+            \begin{figure}
+                \centering
+                \includegraphics[width=0.8\linewidth]{graphics/scad_carriage.png}
+                \caption{Rendered 3D model of the \ac{scara}, including steppers, marker and servo.}
+                \label{fig:scad_carriage}
+            \end{figure}
+
+        \subsubsection{Evaluation}
+            The complete development was rather smooth.
+            However, this was not without deviating from the original design plan.
+            It was not feasible to define all different levels of detail before the start of the development.
+            Prior to the design, it was possible to plan 4 levels of detail.
+            After implementing these levels of detail, the design decisions taken made it possible to define additional levels of detail.
+
+            In total there are seven predefined levels of detail in the design.
+            Meaning that there must also be seven test cycles.
+            However, I noticed that this number was significantly higher.
+            During the design, running the simulation of the dynamics is easy.
+            Resulting in extremely short feedback loops, sometimes even minutes.
+            For example, changing the arm lengths and evaluate the new behavior.
+            Did it improve? Is this as expected?
+            Implicitly, the system was very often tested and changed based on test results.
+
+    \subsection{Conclusion}
+        With the development of the \ac{scara} completed.
+        Following the design plan, the development has to be repeated for the design of the \ac{cdc}.
+        However, the evaluation of the development until this point resulted in enough information to draw conclusions about the design plan.
+        I expect that executing this development a third time is not beneficial to the case study, given the additional effort.
+        Time is better spent on the realization of a prototype and improving the current design method.
+        Therefore, the next section goes into the construction of the prototype instead of the development of the \ac{cdc}.

content/case_experiment_specifications.tex

@@ -0,0 +1,59 @@
+%&tex
+    \subsection{Specifications}
+    \label{sec:specifications}
+        The next step is to create specifications based on the problem description.
+        The goal is to write and remove a tweet on the whiteboard.
+        Originally a tweet had a character limit of 140, but this was doubled to 280\autocite{rosen_tweeting_2017}.
+        However, the decision is made to keep the limit at 140, as it does not improve the case study but can increase the construction cost.
+        The text is limited to fifty characters per line, with a total of three lines.
+        This results in ten extra characters that are used for word wrapping.
+        For the readability, the distance to a whiteboard in a meeting room is taken as \SI{4}{\meter}.
+        The operating speed must allow the tweet to be written within three minutes. 
+        Therefore, the goal is to write one character per second.
+        The last requirement is that the dynamics of the system must be sophisticated.
+        Meaning that a solution with complex or non-trivial behavior is preferred.
+        Using \ac{ears} to define these specifications gives:
+        \begin{specification}
+            \begin{enumerate}
+                \setlength{\itemsep}{10pt}
+                    \input{content/input/speclista.tex}
+        \end{enumerate}
+        \end{specification}
+        Some other specifications that are related to the operation of the system are:
+        \begin{specification}
+            \begin{enumerate}
+                \setcounter{enumi}{8}
+                \setlength{\itemsep}{10pt}
+                    \input{content/input/speclistb.tex}
+            \end{enumerate}
+        \end{specification}
+
+        Additionally there are some restrictions on construction.
+        As the rapid prototyping facilities at the university are closed due to the Covid-19 pandemic, the available tooling in reduced to my personal tools:
+        \begin{specification}
+            \begin{itemize}
+                \setlength{\itemsep}{10pt}
+                \item The Writer shall not exceed a total cost in materials and/or tools of €200.
+                \item The Writer shall be constructed with simple tools in the following list:
+                    \begin{itemize}
+                        \item Screwdrivers (Hex/Inbus, Torx, Philips, etc)
+                        \item Drill
+                        \item Screwtaps
+                        \item Jigsaw
+                        \item Wrenches
+                        \item Soldering iron
+                        \item Various Pliers 
+                        \item PLA 3D printer
+                    \end{itemize}
+            \end{itemize}
+        \end{specification}
+        \subsubsection{Evaluation}
+            The specifications step was performed without problems.
+            Defining the specifications for the problem description did not present any difficulty.
+            Due to the simplicity of the problem description, there were no contradictory requirements, which would complicate the specifications.
+            Furthermore, a single stakeholder takes away any negotiation between stakeholders.
+            Where the stakeholders are a combination of engineers on the design team and/or the project client.
+
+            Although the specifications itself are not difficult to define, ensuring that they are complete is difficult.
+            Team members and stakeholders help to spot any ambiguity or problems with the validity.
+            \ac{ears} was very useful in this case as it gives a strong template to help avoid ambiguity.

content/case_experiment_test_protocol.tex

@@ -0,0 +1,87 @@
+%&tex
+\subsection{Test Protocol}
+    The last step of the preparation phase is to design tests.
+    The tests are designed to validate if the system meets the specifications.
+    While defining the tests, it became clear that part of the specifications was not explicitly defined.
+    As the specifications were made before the design decissisions in the initial design and the feature definition, the specifications did not take that information into account.
+    Updating the specifications after the design decissions was overlooked during the specification of the design plan.
+    To ensure the repeatibility of the tests, this step starts with specifying the order of operation and improved specifications.
+
+    \subsubsection{Defining the Order of Operation}
+    There are two modes of operation: writing and wiping.
+    Defining the order of operation also distributes the responsibility between the different components.
+    The writing operation can be split in the following steps:
+    \begin{order}{Writing}
+        \emph{Precondition:} Marker as end-effector.
+        \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}
+    \end{order}
+
+    The other operation is wiping.
+    This is similar to the operation of writing with the following steps:
+    \begin{order}{Wiping}
+        \emph{Precondition:} Wiper as end-effector.
+        \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}
+    \end{order}
+    Furthermore, switching between the states requires the tool to be switched.
+    However, at this point, it is not known how tools will be switched.
+    Therefore, the order of operation is determined during the development of the end-effector.
+    Additionally, the missing order of operation for the end-effector did not result in difficulty while defining the tests.
+
+    \subsubsection{Improving Specifications}
+    Based on the order of operation, the following specifications were added to the list in \autoref{sec:specifications}:
+    \begin{specification}
+        \begin{enumerate}
+            \setcounter{enumi}{12}
+                \input{content/input/speclistc.tex}
+        \end{enumerate}
+    \end{specification}
+    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.
+
+    \subsubsection{Setting up the tests}
+    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 focusses on the speed and range requirements of the SCARA:
+    \setcounter{testcounter}{0}
+    \begin{test}{Small rectangle}
+    \input{content/input/systemtest1.tex}
+    \end{test}
+    Repeatability is tested in one of the large system wide tests:
+    \setcounter{testcounter}{5}
+    \begin{test}{Repeatability}
+    \input{content/input/systemtest6.tex}
+    \end{test}
+    The complete set of system tests is included in \autoref{app:test_specification}.
+
+    \subsubsection{Evaluation}
+        This step was completed without many difficulties.
+        Which includes the revision of the earlier specifications and definition of orders of operation.
+        Indicating that I overlooked details while defining the specifications in \autoref{sec:specifications}.
+        According to the design plan as described in \autoref{chap:analysis}, I should go back and review those specifications.
+        Followed by reviewing all steps after the specifications.
+        However, this complete review is not practical and extremely time consuming.
+        The point here is, looking at the evaluations of this and previous steps, that chosen design strategy is not feasible, especially as a novice designer.
+        In \autoref{chap:case_evaluation} I will evaluate this with more detail.
+
+        During the analysis, I expected more specific tests.
+        Each test could then be used as a milestone during the development of the system.
+        Every time detail is added, an additional test passes.
+        Or a test fails, notifying that something went wrong and should be investigated.
+        Creating such specific tests relies on the details in the design of the system.
+        The current design is basic and these details are added during the feature implementation.
+        Nevertheless, this step resulted in a set of tests that cover all specifications and features that are specified in this preparation phase.
+        When all the tests pass, the system should meet all the requirements.
+

content/case_method.tex

@@ -9,6 +9,7 @@ The last important thing is a subject of design that is developed in the case st
 The next sections present the evaluation protocol and the subject of design.
 
 \section{Evaluation Protocol}
+\label{sec:evaluation_protocol}
     The evaluation protocol ensures that the different steps, decisions and changes of the design are consistently evaluated.
     This protocol contains a questionnaire and model validation.
     The full questionnaire is administered during each step in the design plan.
@@ -83,6 +84,7 @@ The next sections present the evaluation protocol and the subject of design.
         The prototype does not only show where the design process went wrong, it can also be used to improve the design plan to prevent these modeling problems.
 
 \section{Subject of Design}
+\label{sec:sod}
 The choice in subject of design has a strong influence on the effectiveness of the evaluation of the design plan.
 To ensure the best subject of design a list of requirements is composed.
 Based on this list the best subject of design is a "Tweet on a whiteboard writer", which is referred to as system.

content/input/speclista.tex

@@ -0,0 +1,8 @@
+\item The Writer must be able to write at least fifty characters per line.
+\item The Writer must be able to write at least three lines of text.
+\item The Writer must plot characters with a size that is readable from 4 meters for a person with good eyesight.
+\item The Writer must plot in a regular used font with corresponding character spacing.
+\item When a new tweet is send to the Writer, the Writer must wipe the existing tweet and write down the new tweet.
+\item If the Writer is not wiping or writing then the Writer must not obstruct the view of the whiteboard.
+\item While writing, the Writer must have a writing speed of at least one character per second.
+\item The dynamics of the Writer must be complex/sophisticated/interesting.

content/input/speclistb.tex

@@ -0,0 +1,4 @@
+\item If the Writer is tasked to wipe the tweet, the Writer must wipe the tweet within sixty seconds
+\item When a reset-signal is send to the Writer, the Writer must recalibrate its position on the board.
+\item When a wipe-signal is send to the Writer, the Writer must wipe the board clean.
+\item The Writer must not damage itself.

content/input/speclistc.tex

@@ -0,0 +1,5 @@
+\item While writing, the SCARA must 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 three characters at that position.
+\item When the SCARA finished writing at their current position, the Cable bot 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 Cable bot shall perform this movement within one second.
+\item When the system changes from writing to wiping or vice-versa, the SCARA and End-effector should change the tool within ten seconds.

content/input/systemtest1.tex

@@ -0,0 +1,19 @@
+
+        During this test, a rectangle will be drawn on the whiteboard using the SCARA.
+        This rectangle is \SI{50}{\milli\meter} high and \SI{70}{\milli\meter} wide, such that three characters fit within the rectangle.
+        To test the speed requirements, the rectangle should be drawn within one second.
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA
+            \item[Specifications:] 3, 7, 11, 13, 14
+            \item[Results:] The test passes when:
+                \begin{itemize}
+                    \item Rectangle height is at least \SI{50}{\milli\meter}
+                    \item Rectangle width is at least \SI{70}{\milli\meter}
+                    \item Completion time is less than \SI{1}{\second}
+                \end{itemize}
+%                The SCARA must draw a square of at least \SI{50}{\milli\meter} high and \SI{70}{\milli\meter} 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}

content/input/systemtest6.tex

@@ -0,0 +1,18 @@
+
+        This tests if the Writer can draw repeatedly on the same position, for different approach angles, on the board.
+        The system will start with drawing multiple \SI{60}{\milli\meter} squares on the board in a random location.
+        To test the repeatability, a circle with a \SI{55}{\milli\meter} diameter must be drawn inside of the square.
+        This should be done with twenty squares in an area of at least \SI{1000}{\milli\meter} x \SI{300}{\milli\meter}.
+        The drawing order of each square must be different from the drawing order of circles, this ensures that the Cable bot makes a different approach path.
+        \tcbline
+        \begin{description}
+            \item[Features:] SCARA, Cable Bot
+            \item[Specifications:] 3, 4, 9, 11, (12)
+            \item[Results:]
+                The test passes when:
+                \begin{itemize}
+                    \item Each square has a circle drawn inside.
+                    \item The squares and circles are within \SI{5}{\milli\meter} of their given dimensions.
+                    \item All the circles are completely within their corresponding square. 
+                \end{itemize}
+        \end{description}

graphics/cable_angle.tex

@@ -0,0 +1,55 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\usepackage{gensymb}
+\input{graphics/tics.tikz}
+
+\begin{document}
+\begin{tikzpicture}[thick, on grid, x = 2.16cm, y = 2.16cm, >=Stealth]
+    			
+    %Whiteboard
+    \def \smallangle {30}
+        \filldraw[gray] (0,0) -- (0.4,0) arc [start angle=0, end angle=\smallangle, radius=0.4] -- cycle;
+        \node at ({cos(\smallangle/2)*0.6},{sin(\smallangle/2)*0.6}) {$\smallangle\degree$};
+        \draw[->] (0,0) -- (0,1);
+        \node at (0.1,1) {$g$};
+        \draw[->,red] (0,0) -- ({cos(\smallangle)/sin(\smallangle)},1);
+        \draw[->] (0,0) -- ({cos(\smallangle)/sin(\smallangle)},0);
+        \node at ({cos(\smallangle)/sin(\smallangle)},-0.1) {$a$};
+        \draw (0,0) pic {masspoint};
+
+    \begin{scope}[shift={(0,1.4)}]
+    \def \smallangle {60}
+        \filldraw[gray] (0,0) -- (0.4,0) arc [start angle=0, end angle=\smallangle, radius=0.4] -- cycle;
+        \node at ({cos(\smallangle/2)*0.6},{sin(\smallangle/2)*0.6}) {$\smallangle\degree$};
+        \draw[->] (0,0) -- (0,1);
+        \node at (0.1,1) {$g$};
+        \draw[->,red] (0,0) -- ({cos(\smallangle)/sin(\smallangle)},1);
+        \draw[->] (0,0) -- ({cos(\smallangle)/sin(\smallangle)},0);
+        \node at ({cos(\smallangle)/sin(\smallangle)},-0.1) {$a$};
+        \draw (0,0) pic {masspoint};
+    \end{scope}
+    
+
+    		%	\fill[pattern = north east lines] ($ (0,0) + (-1,0) $) rectangle ($ (0,0) + (1,0.5) $);
+    		%	\draw[thick] ($ (0,0.5) + (-1,0) $) -- ($ (0,0.5) + (1,0) $);
+    		%	
+    		%	%draw arm and joints
+                %        \fill (0,0.5) circle (0.2);  
+                %        \draw[thick] (0,0.5) to node[midway,right,draw=none] {$a$} (-1.5,3.5);  
+                %        \fill (-1.5,3.5) circle (0.2); 
+                %        \draw[thick] (-1.5,3.5) to node[midway,above,draw=none] {$b$}(1.51,4.26);		
+                %        
+                %        %draw mass
+                %        \draw (1.7,4.32) circle (0.2) node {$m$};
+                %        
+                %        %draw arc
+	    	%	%\draw[dashed,gray] (-1.5,3.5) -- ++(2.5,0);
+	    	%	%\draw (1,0.5) arc (0:116:1cm) node[above,midway] {$\theta$};	
+
+    		%	%\draw [arrow] (c.south) -- +(0,-1cm) node[midway,right,draw=none] {$F_{g} = m \cdot g$};
+\end{tikzpicture}
+\end{document}
+

graphics/cablebot.tex

@@ -0,0 +1,24 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\input{graphics/tics.tikz}
+
+\begin{document}
+\begin{tikzpicture}[thick, on grid, x = 2.16cm, y = 2.16cm]
+    %Whiteboard
+    \draw (0,0.5) pic {whiteboard};
+    \draw (0,3) -- (1.5,1);
+    \draw (4,3) -- (1.5,1);
+    \draw (0,3) pic {pulley};
+    \begin{scope}[x=-2.16cm]
+            \draw(-4,3) pic {pulley};
+    \end{scope}
+
+    %Draw mass with coordinates
+    \draw (1.5,1) pic {masspoint};
+    \node at (1.8,0.8) {$x,y$};
+\end{tikzpicture}
+\end{document}
+

graphics/code_objects.tex

@@ -0,0 +1,21 @@
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\tikzset{nodes={text height=.7em, text width=2.8cm, align=center,
+draw=black!50, thick, font=\footnotesize, fill=white},
+>={Stealth[round,sep]}, rounded corners, semithick}
+
+\begin{document}
+\begin{tikzpicture}[y=0.8cm,x=3.2cm]
+    \node (pp) {Path planning};
+    \node (ip)[below=1 of pp]  {Interpolation};
+    \node (ik)[below=1 of ip]  {Inverse Kinematics\\/Lookup Table};
+    \node (sd)[below=1 of ik]  {Stepper driver};
+    \begin{scope}[nodes={right, draw=none, fill=none, midway,text width={}}]
+        \path[->] (pp) edge node {$x,y$} (ip)
+              (ip) edge node {$x,y$} (ik)
+              (ik) edge node {$\phi,\psi$} (sd);
+    \end{scope}
+\end{tikzpicture}
+\end{document}

graphics/combined.tex

@@ -0,0 +1,26 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\usetikzlibrary{calc,patterns}
+\input{graphics/tics.tikz}
+
+\begin{document}
+\begin{tikzpicture}[thick, >=Stealth, on grid, y=2.16cm, x=2.16cm]
+    \def \x {0.45};
+    \def \y {0.35};
+    \def \posx {1.7};
+    \def \posy {1.2};
+    \def \beta {-120};
+    \def \alpha {130};
+    \draw (0,0.5) pic {whiteboard};
+    \draw (0,3) -- (\posx-\x,\posy+\y);
+    \draw (4,3) -- (\posx+\x,\posy+\y);
+    \draw (0,3) pic {pulley};
+    \begin{scope}[x=-2.16cm]
+            \draw(-4,3) pic {pulley};
+    \end{scope}
+    \draw (1.7,1.2) pic {scara};
+\end{tikzpicture}
+\end{document}

graphics/compare_table.tex

@@ -0,0 +1,61 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz,array}
+\usepackage{siltex}
+\usetikzlibrary{calc,positioning,patterns,math}
+
+\newcommand{\tikzmark}[1]{\tikz[remember picture,overlay]\coordinate (#1);}
+
+\newcolumntype{V}[1]{@{\hspace{\tabcolsep}}c@{\hspace{\tabcolsep}\tikzmark{#1}}}
+\newcolumntype{T}[1]{@{\hspace{\tabcolsep}}m{0.3cm}@{\hspace{\tabcolsep}\tikzmark{#1}}}
+\newcommand{\xd}{\tikz{\fill[gray] (0,0) circle (3pt)}}
+\newcommand{\od}{\tikz{\draw[gray] (0,0) circle (3pt)}}
+
+
+\begin{document}
+\begin{tikzpicture}[remember picture]
+    \def\th{3.4}
+    \def\ct(#1,#2,#3){%
+        \draw (mytable.north-|#1) --++ (60:\th);
+        \node[rotate=60,anchor=west] at ($(mytable.north-|#1)!0.5!(mytable.north-|#2)$) {#3};
+    }
+    \node[inner xsep=-\pgflinewidth,inner ysep=-\pgflinewidth, anchor=north west] at (0,0) (mytable){%
+        \begin{tabular}{|V{a}| T{b}| T{c}| T{d}| T{e}| T{f}| T{g}| T{h}| T{i}| T{j}| T{k}|}
+            \hline
+            %  & Small rectangle & Perimiter & Cable bot Speed & Tripple Chars & Tool Change & Repeatability & Linearity & Writing & Wiping \\ \hline
+            1  &   &\xd&   &   &   &   &\xd&\xd&   &   \\ \hline
+            2  &   &\xd&   &   &   &   &\xd&\xd&   &   \\ \hline
+            3  &\xd&   &   &\xd&   &\xd&\xd&\xd&   &   \\ \hline
+            4  &   &   &   &\xd&   &\xd&   &\xd&   &   \\ \hline
+            5  &   &   &   &   &\od&   &   &\od&\od&   \\ \hline
+            6  &   &\xd&   &   &   &   &   &\xd&   &   \\ \hline
+            7  &\xd&   &\xd&   &   &   &   &\xd&   &   \\ \hline
+            8  &   &   &   &   &   &   &   &   &   &\xd\\ \hline
+            9  &   &   &\xd&   &   &\xd&   &   &   &   \\ \hline
+            10 &   &   &   &   &   &   &   &   &\xd&   \\ \hline
+            11 &   &\xd&   &   &   &\xd&   &\xd&\xd&   \\ \hline
+            12 &\od&\od&\od&\od&\od&\od&\od&\xd&\xd&   \\ \hline
+            13 &\xd&   &   &\xd&   &   &   &\xd&   &   \\ \hline
+            14 &\xd&   &\xd&\xd&   &   &   &\xd&   &   \\ \hline
+            15 &   &   &\xd&   &   &   &   &\xd&   &   \\ \hline
+            16 &   &   &\xd&   &   &   &   &\xd&   &   \\ \hline
+            17 &   &   &   &   &\xd&   &   &   &   &   \\ \hline
+        \end{tabular}
+        };
+        \draw (mytable.north east) --++ (60:\th);
+        \draw (mytable.north west) --++ (60:\th);
+        \draw (mytable.north east) ++ (60:\th) --([shift={(60:\th)}]mytable.north west);
+
+        \ct(mytable.north west,a,System Specification)
+        \ct(a,b,Small rectangle)
+        \ct(b,c,Perimiter)
+        \ct(c,d,Cable bot speed)
+        \ct(d,e,Triple Chars)
+        \ct(e,f,Tool Change)
+        \ct(f,g,Repeatability)
+        \ct(g,h,Linearity)
+        \ct(h,i,Writing)
+        \ct(i,j,Wiping)
+        \ct(j,k,Complexity)
+\end{tikzpicture}
+\end{document}

graphics/design_flow_analysis.tex

@@ -8,13 +8,14 @@ draw=black!50, thick, font=\footnotesize, fill=white},
 
 \begin{document}
 \begin{tikzpicture}[on grid,y=1.2cm,x=3.2cm]
-    \draw[fill=lightgray] (-1.7cm, 1.5cm) rectangle (1.7cm, -4.1cm);
-    \draw[fill=lightgray] (-1.7cm,-4.3cm) rectangle (5cm, -8.2cm);
+    \draw[fill=lightgray] (-1.7cm, 1.5cm) rectangle (1.7cm, -5.3cm);
+    \draw[fill=lightgray] (-1.7cm,-5.5cm) rectangle (5cm, -9.2cm);
     \node (pd) {Problem Description};
     \node (sp)[below=1 of pd]  {Specifications};
     \node (id)[below=1 of sp]  {Initial Design};
     \node (fs)[below=1 of id]  {Feature Definition};
-    \node (ss)[below=1 of fs]  {Feature Selection};
+    \node (tp)[below=1 of fs]  {Test Protocol};
+    \node (ss)[below=1 of tp]  {Feature Selection};
     \node (a1)[below=0.8 of ss,draw=none, fill=none] {};
     \node (rd)[below=0.8 of a1]  {Rapid Development};
     \node (va)[right=1 of a1]  {Variable Approach};
@@ -23,7 +24,8 @@ draw=black!50, thick, font=\footnotesize, fill=white},
     \path[->] (pd) edge (sp)
               (sp) edge (id)
               (id) edge (fs)
-              (fs) edge (ss)
+              (fs) edge (tp)
+              (tp) edge (ss)
               (ss) edge (rd)
               (rd.east) edge[bend right] (va)
               (va) edge[bend right] (ss.east);

graphics/electronics.tex

@@ -0,0 +1,21 @@
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\tikzset{nodes={minimum height=0.6cm, text width=2.25cm, align=center,
+draw=black!50, thick, font=\footnotesize, fill=white},
+>={Stealth[round,sep]}, rounded corners, semithick}
+
+\begin{document}
+\begin{tikzpicture}[on grid,y=1.2cm,x=2.75cm]
+    \node (mc) {Micro Controller};
+    \node (ha)[left=0.5 of mc,draw=none,fill=none]{};
+    \node (hb)[right=0.5 of mc,draw=none,fill=none]{};
+    \node (sc)[below=1 of hb] {Stepper Controller};
+    \node (sm)[below=1 of sc] {Stepper Motor};
+    \node (sv)[below=1 of ha] {Servo Motor};
+    \path[->] (mc) edge (sc)
+              (mc) edge (sv)
+              (sc) edge (sm);
+\end{tikzpicture}
+\end{document}

graphics/end-effector.tex

@@ -0,0 +1,127 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {calc,arrows.meta,positioning,patterns,math}
+%\input{graphics/tics.tikz}
+        
+\begin{document}
+    \begin{tikzpicture}[x=0.9cm, y=0.9cm, nodes={text width=4.5cm,anchor=north west,draw=none}]
+        \def \markerradius {0.5};
+        \def \angle {40};
+        \def \startangle {-90-\angle};
+        \def \stopangle {-90+\angle};
+        \def \length{4};
+        \def \thick{0.3};
+        \def \clampoffset{2};
+        \pgfmathsetmacro{\clamppos}{\clampoffset-\markerradius*sin(\angle)};
+        \pgfmathsetmacro{\side}{\markerradius*(1-cos(\angle))};
+        \def \clampsection {++(${\side}*(0,1)$) arc[start angle=\startangle,end angle=\stopangle,radius=\markerradius] -- ++(${-1*\side}*(0,1)$)}; 
+        \def \blockdistance {2.8}
+        \def \blockpos {(0,0)};
+        \def \markerdrop {0.5};
+        \def \spacing {5.6};
+        \def \yspacing {4.6};
+    \tikzset{
+        block/.pic=
+        {
+            \def \height {1.5};
+            \def \width {1};
+            \draw[pattern = north west lines] (\clamppos,-1) -- (\clamppos,-\markerdrop) -- \clampsection -- ++(0,-0.2) -- (\blockdistance,-\markerdrop-0.2) -- (\blockdistance,1) -- (\blockdistance+\width,1) -- (\blockdistance+\width,-1); 
+        },
+        upperclamp/.pic=
+        {
+        \def \startangle {90+\angle};
+        \def \stopangle {90-\angle};
+        \def \side {-\markerradius*(1-cos(\angle))};
+            \draw[fill=lightgray] (0,0) -- (${\clamppos}*(1,0)$) coordinate(a) -- \clampsection coordinate(b) -- (\length,0) -- ++(0,\thick) -- (0,\thick);
+        },
+        lowerclamp/.pic=
+        {
+            \draw[fill=lightgray] (0,0) -- (${\clamppos}*(1,0)$) -- \clampsection -- ++(0,-\thick) -- (0,-\thick);
+        },
+        marker/.pic=
+        {
+            \draw[fill=gray] (0,0) circle(\markerradius);
+        }
+    }
+        \def \nodepos {(\blockdistance-4.0,2.9)};
+    \begin{scope}[shift={(0*\spacing,0)}]
+        \def \eex {1.3};
+        \def \eey {-0.5};
+        \pgfmathsetmacro{\clampangle}{max(0,atan2(\eey,{\blockdistance+\eex}))};
+        \draw \blockpos pic {block};
+        \node at \nodepos {1. Marker is clamped in springloaded end-effector.};
+        \draw (2-\eex,{\markerradius+\eey*-1}) pic {marker};
+        \begin{scope}[shift={(-\eex,-\eey)}]
+            \draw (0,0) pic {lowerclamp};
+            \draw (0,1) pic[rotate=\clampangle] {upperclamp};
+        \end{scope}
+    \end{scope}
+    \begin{scope}[shift={(1*\spacing,0)}]
+        \def \eex {0};
+        \def \eey {0};
+        \pgfmathsetmacro{\clampangle}{max(0,atan2(\eey,{\blockdistance+\eex}))};
+        \draw \blockpos pic {block};
+        \node at \nodepos {2. End-effector is positioned on the holder.};
+        \draw (2,\markerradius) pic {marker};
+        \begin{scope}[shift={(-\eex,-\eey)}]
+            \draw (0,0) pic {lowerclamp};
+            \draw (0,1) pic[rotate=\clampangle] {upperclamp};
+        \end{scope}
+    \end{scope}
+    \begin{scope}[shift={(2*\spacing,0)}]
+        \def \eex {0};
+        \def \eey {0.5};
+        \pgfmathsetmacro{\clampangle}{max(0,atan2(\eey,{\blockdistance+\eex}))};
+        \draw \blockpos pic {block};
+        \node at \nodepos {3. End-effector is moved down, forcing the upper clamp open.};
+        \draw (2,\markerradius-\markerdrop) pic {marker};
+        \begin{scope}[shift={(-\eex,-\eey)}]
+            \draw (0,0) pic {lowerclamp};
+            \draw (0,1) pic[rotate=\clampangle] {upperclamp};
+        \end{scope}
+    \end{scope}
+    \begin{scope}[shift={(0*\spacing,-\yspacing)}]
+        \def \eex {0};
+        \def \eey {0.7};
+        \pgfmathsetmacro{\clampangle}{max(0,atan2(\eey,{\blockdistance+\eex}))};
+        \draw \blockpos pic {block};
+        \node at \nodepos {4. End-effector continues down, leaving the marker in the holder.};
+        \draw (2,\markerradius-\markerdrop) pic {marker};
+        \begin{scope}[shift={(-\eex,-\eey)}]
+            \draw (0,0) pic {lowerclamp};
+            \draw (0,1) pic[rotate=\clampangle] {upperclamp};
+        \end{scope}
+    \end{scope}
+    \begin{scope}[shift={(1*\spacing,-\yspacing)}]
+        \def \eex {1};
+        \def \eey {0.7};
+        \pgfmathsetmacro{\clampangle}{max(0,atan2(\eey,{\blockdistance+\eex}))};
+        \draw \blockpos pic {block};
+        \node at \nodepos {5. The longer arm allows the end-effector to move sideways.};
+        \draw (2,\markerradius-\markerdrop) pic {marker};
+        \begin{scope}[shift={(-\eex,-\eey)}]
+            \draw (0,0) pic {lowerclamp};
+            \draw (0,1) pic[rotate=\clampangle] {upperclamp};
+        \end{scope}
+    \end{scope}
+    \begin{scope}[shift={(2*\spacing,-\yspacing)}]
+        \def \eex {1};
+        \def \eey {0};
+        \pgfmathsetmacro{\clampangle}{max(0,atan2(\eey,{\blockdistance-\eex}))};
+        \draw \blockpos pic {block};
+        \node at \nodepos {6. Return to begin position, now without marker.};
+        \draw (2,\markerradius-\markerdrop) pic {marker};
+        \begin{scope}[shift={(-\eex,-\eey)}]
+            \draw (0,0) pic {lowerclamp};
+            \draw (0,1) pic[rotate=\clampangle] {upperclamp};
+        \end{scope}
+    \end{scope}
+
+    \draw (4.2,-1.3*\yspacing) -- (4.2,2.9);
+    \draw[shift={(\spacing,0)}] (4.2,-1.3*\yspacing) -- (4.2,2.9);
+    \draw(-1.4,-1.5) -- ++(3*\spacing,0);
+
+    \end{tikzpicture}
+\end{document}

graphics/plotter.tex

@@ -0,0 +1,23 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\input{graphics/tics.tikz}
+
+\begin{document}
+\begin{tikzpicture}[thick, on grid, x = 2.16cm, y = 2.16cm, >=Stealth]
+    \draw(0,-0.1) pic {rail};
+    \draw(0,2.6) pic {rail};
+    \draw(0,0) pic {whiteboard};
+    \begin{scope}[shift={(1,0)}]
+        \draw[fill=gray!60] (-0.05,-0.1) rectangle (0.05,2.6);
+        \draw[<->] (-0.3,-0.2) -- node[midway,below]{$x$} (0.3,-0.2);
+        \begin{scope}[shift={(0,1.7)}]
+            \draw[fill=gray!80] (-0.12,-0.15) rectangle (0.12,0.15);
+            \draw[<->] (0.25,-0.25) -- node[midway,right]{$y$} (0.25,0.25);
+        \end{scope}
+    \end{scope}
+\end{tikzpicture}
+\end{document}
+

graphics/polar.tex

@@ -0,0 +1,22 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {calc,arrows.meta,positioning,patterns}
+\input{graphics/tics.tikz}
+
+\begin{document}
+\begin{tikzpicture}[thick, on grid, x = 2.16cm, y = 2.16cm, >=Stealth]
+    \draw(-2,-2.75) pic {whiteboard};
+    %\filldraw[pattern = north west lines, pattern color=gray!60,draw=none] (-2,0) -- (2,0) arc[start angle = 0, end angle = 180, radius=2] -- cycle;
+    \draw[fill=gray] (0,0) circle (0.2);
+    \begin{scope}[rotate=45,shift={(-1,0)}]
+            \draw[fill=gray!60] (-1,0.05) rectangle (1.5,-0.05);
+            \draw[<->] (-0.2,0.15) -- node[midway,above]{$r$} (-0.8,0.15);
+            \begin{scope}[shift={(-0.3,0)}]
+                \draw[<->] ({0.8*cos(160)},{0.8*sin(160)}) arc[start angle = 160, end angle= 200, radius = 0.8] node[midway, below left]{$\Phi$};
+            \end{scope}
+    \end{scope}
+\end{tikzpicture}
+\end{document}
+

graphics/polar_protrude.tex

@@ -0,0 +1,23 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {calc,arrows.meta,positioning,patterns}
+\input{graphics/tics.tikz}
+
+\begin{document}
+\begin{tikzpicture}[thick, on grid, x = 1.16cm, y = 1.16cm, >=Stealth]
+    \clip[draw=none] (-0.7,-0.9) rectangle (2.12,2.2);
+    \draw(-2,-2.75) pic {whiteboard};
+    \filldraw[pattern = north west lines, pattern color=gray!60,draw=gray!60] (-2.1,0) -- (2.1,0) arc[start angle = 0, end angle = 180, radius=2.1] -- cycle;
+    \draw[fill=gray] (0,0) circle (0.2);
+    \begin{scope}[rotate=60,shift={(0.5,0)}]
+            \draw[fill=gray!60] (-1,0.05) rectangle (1.5,-0.05);
+            \draw[<->] (0.2,0.15) -- node[midway,above left]{$r$} (0.8,0.15);
+            \begin{scope}[shift={(-0.3,0)}]
+               \draw[<->] ({0.8*cos(160)},{0.8*sin(160)}) arc[start angle = 160, end angle= 200, radius = 0.8] node[midway, below left]{$\Phi$};
+            \end{scope}
+    \end{scope}
+\end{tikzpicture}
+\end{document}
+

graphics/robmosys.tex

@@ -0,0 +1,60 @@
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+
+\begin{document}
+
+\begin{tikzpicture}[on grid,y=1.5cm,x=2.24cm, nodes={text height=.7em, text width=1.8cm, align=center,
+draw=black!20, thick, fill=white, font=\footnotesize},
+>={Stealth[round,sep]}, rounded corners, semithick]
+    \node (a) at (0,0) {Mission};
+    \node (b) at (0,-1) {Task};
+    \node (c) at (0,-2) {Skill};
+    \node (d) at (0,-3) {Function};
+    \node (e) at (0,-4) {Component};
+
+    \begin{scope}[shift={(2.596cm,0)}]
+        %\draw[fill=lightgray] (-0.6, 0.4) rectangle (4.6,-3.4);
+        \node (A) at (2.5,0) {Draw a tweet on a board};
+        \node (B) at (2,-1) {Writing};
+        \node (C) at (3,-1) {Wiping};
+        \node (D) at (0,-2) {Write char at position};
+        \node (E) at (1,-2) {Wipe area};
+        \node (F) at (2,-2) {Hold Marker};
+        \node (G) at (3,-2) {Hold Wiper};
+        \node (H) at (4,-2) {Move to Position};
+        \node (I) at (0,-3) {Move Marker on Board};
+        \node (J) at (1,-3) {Move Wiper on Board};
+        \node (K) at (2,-3) {Switch Tools};
+        \node (L) at (3,-3) {Lift Marker};
+        \node (M) at (4,-3) {More Carriage};
+        \node (N) at (1,-4) {SCARA};
+        \node (O) at (2.5,-4) {End-effector};
+        \node (P) at (4,-4) {Cable driven Carriage};
+    \end{scope}
+    \path[->] (A) edge (B)
+    (A) edge (C)
+    (B) edge (D)
+    (B) edge (H)
+    (C) edge (E)
+    (B) edge (F)
+    (C) edge (G)
+    (D) edge (I)
+    (D) edge (L)
+    (E) edge (J)
+    (F) edge (K)
+    (G) edge (K)
+    (H) edge (M)
+    (a) edge (b)
+    (b) edge (c)
+    (c) edge (d);
+    \path[->,dashed]
+    (I) edge (N)
+    (J) edge (N)
+    (K) edge (N)
+    (K) edge (O)
+    (L) edge (O)
+    (M) edge (P);
+\end{tikzpicture}
+\end{document}

graphics/scara.tex

@@ -0,0 +1,32 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\usetikzlibrary{calc,patterns}
+\input{graphics/tics.tikz}
+
+\begin{document}
+\begin{tikzpicture}[>=Stealth, on grid, y=2.16cm, x=2.16cm]
+
+    \draw(0,0) pic {whiteboard};
+    \begin{scope}[shift={(2,2.8)}]
+        \draw[fill=gray] (0,0) circle (0.2);
+        \begin{scope}[rotate=-60, rounded corners]
+            \draw[fill=gray!60](-0.075,-0.075) rectangle (1.5,0.075);
+            \begin{scope}[shift={(0.8,0)}]
+                \draw[<->] ({0.8*cos(20)},{0.8*sin(20)}) arc[start angle = 20, end angle= -20, radius = 0.8] node[midway, below right]{$\alpha$};
+            \end{scope}
+            \begin{scope}[shift={(1.44,0)}]
+                \begin{scope}[rotate=-104]
+                    \draw[fill=gray!60](-0.075,-0.075) rectangle (1.5,0.075);
+                    \begin{scope}[shift={(0.8,0)}]
+                        \draw[<->] ({0.8*cos(20)},{0.8*sin(20)}) arc[start angle = 20, end angle= -20, radius = 0.8] node[midway, left]{$\beta$};
+                    \end{scope}
+                \end{scope}
+            \end{scope}
+        \end{scope}
+    \end{scope}
+\end{tikzpicture}
+\end{document}
+

graphics/scara_arm_kinematics.tex

@@ -0,0 +1,39 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary{calc,positioning,patterns,math}
+
+\begin{document}
+\begin{tikzpicture}[x=0.75cm, y=0.75cm]
+    \tikzstyle{arrow} = [-latex,ultra thick]
+
+    % draw roof
+    \fill[pattern = north east lines] ($ (0,0) + (-1,0) $) rectangle ($ (0,0) + (1,0.5) $);
+    \draw[thick] ($ (0,0.5) + (-1,0) $) -- ($ (0,0.5) + (1,0) $);
+
+    %draw arm and joints
+    \pgfmathsetmacro{\alphahoek}{120};
+    \pgfmathsetmacro{\a}{4};
+    \pgfmathsetmacro{\betahoek}{-105};
+    \pgfmathsetmacro{\b}{4};
+    \pgfmathsetmacro{\radius}{0.8};
+    \begin{scope}[shift={(0,0.5)}]
+        \draw (\radius,0) arc [start angle=0, end angle=\alphahoek, radius=\radius] node[above,midway] {$\alpha$};
+        \begin{scope}[rotate=\alphahoek]
+            \fill (0,0) circle (0.2);  
+            \draw[thick] (0,0) to node[midway,right,draw=none] {$a$} (\a,0);  
+            \begin{scope}[shift={(\a,0)}]
+                \draw (-\radius,0) arc [start angle=-180, end angle=\betahoek, radius=\radius] node[right,midway] {$\beta$};
+                \begin{scope}[rotate=\betahoek]
+                    \fill (0,0) circle (0.2);  
+                    \draw[thick] (0,0) to node[midway,below,draw=none] {$b$} (\b,0);  
+                    \begin{scope}[shift={(\b,0)}]
+                        \draw[fill=white] (0,0) circle (0.3) node {$m$};
+                    \end{scope}
+                \end{scope}
+            \end{scope}
+        \end{scope}
+    \end{scope}
+\end{tikzpicture}
+\end{document}

graphics/scara_design.tex

@@ -0,0 +1,187 @@
+
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {calc,arrows.meta,positioning,patterns,math}
+%\input{graphics/tics.tikz}
+        
+\begin{document}
+    \begin{tikzpicture}[on grid, x=0.75cm, y=0.75cm]
+        % Define Drawing Box dimentions
+        \def \boxheight {5};
+        \def \boxwidth {6};
+        \def \boxorigin {(-\boxwidth/2,-1)};
+        \def \boxsize {(\boxwidth,\boxheight)};
+        \def \armcolor {gray};
+        \def \jointred {\draw[fill=orange] (0,0) circle(0.4);}
+        \def \jointblue {\draw[fill=blue] (0,0) circle(0.4);}
+
+        
+        \def \width {0.3};
+        \def \length {5};
+        \def \holediameter {0.10};
+        \def \floorheight {0.5};
+        \pgfmathsetmacro{\floorwidth}{4};
+        \def \arm {
+            \draw[fill=\armcolor] (0,0)  ++(0,\width/2) arc[start angle=90, end angle=270, radius=\width/2] -- ++(\length,0) arc[start angle=-90, end angle=90, radius=\width/2] -- cycle;
+            \draw[fill=white] (0,0) circle (\holediameter/2);
+            \draw[fill=white] (\length,0) circle (\holediameter/2);
+        }
+        \def \doublescara {
+            \pgfmathsetmacro{\C}{sqrt(pow(\A,2)+pow(\B,2)-2*\A*\B*cos(\c))};
+            \pgfmathsetmacro{\b}{acos((pow(\A,2) + pow(\C,2) - pow(\B,2))/(2*\A*\C))};
+            \pgfmathsetmacro{\d}{180-\h-\b};
+            \pgfmathsetmacro{\D}{sqrt(pow(\C,2)+pow(\B,2)-2*\B*\C*cos(\d))};
+            \pgfmathsetmacro{\g}{acos(\D/(2*\B))};
+            \pgfmathsetmacro{\f}{acos((pow(\D,2) + pow(\B,2) - pow(\C,2))/(2*\D*\B))};
+            \pgfmathsetmacro{\a}{180-\b-\c};
+            \pgfmathsetmacro{\e}{180-\d-\f};
+            \pgfmathsetmacro{\k}{180-\f-\g};
+            \pgfmathsetmacro{\m}{180-\g-\e-\a};
+            \begin{scope}[shift={(-\A/2,0)}, rotate=\c]
+                \jointred
+                \def \length{\B}
+                \arm
+                \begin{scope}[shift={(\B,0)}, rotate=-\m]
+                    \def \length{\B}
+                    \arm
+                \end{scope}
+            \end{scope}
+            \begin{scope}[shift={(\A/2,0)}, rotate=\h]
+                \jointblue
+                \def \length{\B}
+                \arm
+                \begin{scope}[shift={(\B,0)}, rotate=\k]
+                    \def \length{\B}
+                    \arm
+                \end{scope}
+            \end{scope}
+        };
+
+
+
+        \tikzset{arm/.pic={
+            \def \length {#1}
+            \draw[fill=gray] (0,0)  ++(0,\width/2) arc[start angle=90, end angle=270, radius=\width/2] -- ++(\length,0) arc[start angle=-90, end angle=90, radius=\width/2] -- cycle;
+            \draw[fill=white] (0,0) circle (\holediameter/2);
+            \draw[fill=white] (\length,0) circle (\holediameter/2);
+        },
+        floor/.pic={
+            \def \width {#1/2};
+            \draw (-\width,0) -- (\width,0);
+            \fill[pattern=north west lines] (-\width,-\floorheight) rectangle (\width,0);
+        },
+        box/.pic={
+            \draw \boxorigin rectangle ++\boxsize;
+        }
+        };
+
+        \pgfmathsetmacro{\B}{2.3};
+        \pgfmathsetmacro{\A}{1};
+        \def \nodepos {(2.4,3.4)};
+        %rechts boven
+        \begin{scope}[shift={(1*\boxwidth,1*\boxheight)}]
+            \node at \nodepos {2.};
+            \draw (0,0) pic {box};
+            \draw (0,0) pic {floor=2};
+            %\pgfmathsetmacro{\c}{90};
+            %\pgfmathsetmacro{\h}{40};
+            %\def \armcolor{lightgray};
+            %\doublescara;
+            \pgfmathsetmacro{\c}{130};
+            \pgfmathsetmacro{\h}{60};
+            \def \armcolor{gray};
+            \doublescara;
+        \end{scope}
+
+        
+        % Links boven
+        \begin{scope}[shift={(0*\boxwidth,\boxheight)}]
+            \node at \nodepos {1.};
+            \draw (0,0) pic {box};
+            \draw (0,0) pic {floor=2};
+            \begin{scope}[shift={(0,0)}, rotate=120]
+                \jointred
+                \def \length{\B}
+                \arm
+                \begin{scope}[shift={(\B,0)}, rotate=-100]
+                    \jointblue
+                    \def \length{\B}
+                    \arm
+                \end{scope}
+            \end{scope}
+        \end{scope}
+        
+        %rechts onder
+        \begin{scope}[shift={(\boxwidth,0*\boxheight)}]
+            \node at \nodepos {4.};
+            \draw (0,0) pic {box};
+            \draw (0,0) pic {floor=2};
+            \def \a {105};
+            \def \b {5};
+            \def \c {\b-\a};
+            \def \C {1};
+            \def \B {2.5};
+            \def \A {3};
+            \begin{scope}[shift={(0,0)}, rotate=180+\b]
+                \jointblue
+                \def \length{\C}
+                \begin{scope}[shift={(\length,0)}, rotate=-(180+\c)]
+                    \def \length{\A}
+                    \arm
+                    \begin{scope}[shift={(\length,0)}, rotate=\c]
+                        \def \length{\B+\C}
+                        \arm
+                    \end{scope}
+                \end{scope}
+                \arm
+            \end{scope}
+            \begin{scope}[shift={(0,0)}, rotate=\a]
+                \def \length{\A}
+                \arm
+            \end{scope}
+            \begin{scope}[shift={(\C,0)}, rotate=\a]
+                \jointred
+                \def \length{\C}
+                \begin{scope}[shift={(\length,0)}, rotate=-180-\a]
+                    \def \length{\C}
+                    \arm
+                \end{scope}
+                \arm
+            \end{scope}
+        \end{scope}
+
+        % Links onder
+        \begin{scope}[shift={(0,0)}]
+            \node at \nodepos {3.};
+            \draw (0,0) pic {box};
+            \draw (0,0) pic {floor=2};
+            \def \a {105};
+            \def \b {5};
+            \def \c {\b-\a};
+            \def \C {1};
+            \def \B {2.5};
+            \def \A {3};
+            \begin{scope}[shift={(0,0)}, rotate=180+\b]
+                \draw[fill=blue] (0,0) circle(0.5);
+                \def \length{\C}
+                \begin{scope}[shift={(\length,0)}, rotate=-(180+\c)]
+                    \def \length{\A}
+                    \arm
+                    \begin{scope}[shift={(\length,0)}, rotate=\c]
+                        \def \length{\B+\C}
+                        \arm
+                    \end{scope}
+                \end{scope}
+                \arm
+            \end{scope}
+            \begin{scope}[shift={(0,0)}, rotate=\a]
+                \jointred
+                \def \length{\A}
+                \arm
+            \end{scope}
+        \end{scope}
+
+    \end{tikzpicture}
+\end{document}

graphics/tics.tikz

@@ -0,0 +1,37 @@
+
+\tikzset{
+    pulley/.pic=
+    {
+        \draw (0,0) -- (-0.3,0);
+        \draw (-0.3,-0.2) circle [radius=0.2];
+        \draw (-0.3,-0.2) circle [radius=0.04];
+    },
+    whiteboard/.pic=
+    {
+        \draw[line width=1mm, color=gray, fill=lightgray!70] (0,0) rectangle (4,2.5);
+    },
+    masspoint/.pic=
+    {
+        \draw[fill=white] (0,0) circle (0.2) node {m};
+    },
+    rail/.pic=
+    {
+        \draw[fill=gray!60] (0,0.05) rectangle (4,-0.05);
+    },
+    scara/.pic=
+    {
+        \def \wall {0.05};
+        \draw[fill=gray!60,rounded corners] ({-\x-\wall},{-\y-\wall}) rectangle ({\x+\wall},{\y+\wall});
+        \draw[fill=lightgray!70,rounded corners] ({-\x},{-\y+\wall}) rectangle ({\x},{\y});
+        \begin{scope}[shift={(-\x/2,-\y+\wall/2)},rotate=\alpha, x=7mm, y=7mm]
+            \draw[fill=red](-0.1,-0.1) rectangle (1.6,0.1);
+            \begin{scope}[shift={(1.65,0)}]
+                \begin{scope}[rotate=\beta]
+                    \draw[fill=red](-0.1,-0.1) rectangle (1.4,0.1);
+                    \draw[fill=red](1.4,0) circle (0.2);
+                \end{scope}
+            \end{scope}
+        \end{scope}
+    }
+}
+

include

@@ -1 +1 @@
-Subproject commit 53a54d3e4842e0ad2991fe196a02c8e35cbc2600
+Subproject commit c60fc733267eb72f37dc3228cf76d95be5a7d7db

report.tex

@@ -19,11 +19,13 @@
 
 \begin{document}
 \maketitle
-\makerro
+\frontmatter
 \include{include/acronyms}
 \input{samenvatting}
 \input{summary}
 \tableofcontents
+
+\mainmatter
 \input{introduction}
 \input{background}
 \input{analysis}
@@ -34,7 +36,10 @@
 \input{improved_design}
 \input{conclusion}
 
-%\include{introduction}
+\appendix
+\input{appendix_test_cases}
+\input{appendix_specifications}
 
-\printbibliography
+\backmatter
+\printbibliography[heading=bibintoc,heading=bibnumbered]
 \end{document}