Add content to improvement chapter

content/casestudy.tex

@@ -278,6 +278,7 @@
                 And again, there was a lack of an experience to make a good trade-off.
 
         \subsection{Feature Definition}
+            \label{sec: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 then to define these features.
@@ -610,10 +611,59 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%
 
-        \subsection{Feature Selection: Second Iteration}
-            \subsubsection{Selection}
-                \rro{Scara is next in selection}
-                \rroi{Covers more tests and has higher risk/time factor than carriage}
+        \subsection{Second Feature Selection}
+            The implementation of the end-effector proofed to be impractical.
+            This means that only two features are left.
+            The updated table in \autoref{tab:featurestab2} shows that the next step would be the SCARA.
+            The SCARA has a higher risk/time factor and covers more tests.
+            \begin{table}[]
+                \caption{}
+                \label{tab:featurestab2}
+                \begin{tabular}{llllll}
+                    \hline
+                    Feature  & Dependency & Tests & Risk   & Time   & Risk/Time \\ \hline
+                    SCARA    & -          & 3     & medium & medium & 1         \\
+                    Carriage & -          & 2     & low    & medium & 0.5       \\ \hline
+                \end{tabular}
+            \end{table}
+
+        \subsection{SCARA}
+            At the end of this implementation the SCARA is able to write the first characters
+            This will be achieved by working through different levels of detail.
+            Where each level adds more detail to the model.
+            The levels that are implemented are as follow:
+            \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.
+                \item Advanced motor behavior, 2D physics with stepper motor behavior.
+                \item Advanced physics model, 3D physics with complex dynamics with Lie-algebra.
+                \item Marker lifting behavior, servo lifts marker of the board.
+            \end{enumerate}
+            This mainly describes the different level of physics detail.
+            Together with the physics model there will be a solid 3D CAD model.
+            The CAD model helps to check with dimensions and possible collisions of objects.
+            
+            \subsubsection{Basic kinematics model}
+                The goal of a very simple basic kinematics model is to work out the dimensions and kinematics.
+                The model consists of two submodels: An inverse and a forward kinematics model.
+                The inverse kinematics model calculates the angle of the two arms for a specific setpoint.
+                This model will be used throughout all the following models.
+                To visualize the behavior of the inverse kinematics a forward kinematics model will generate the joint positions from the angles.
+                Plotting these positions allows for inspection and validation of both models.
+
+            \subsubsection{Basic Physics model}
+                In this step the forward kinematics model is replaced with basic 2D physics behavior.
+                Implementing this behavior provides information about the energy in the system.
+                The joints can be powered with ideal motors which makes the whole design very simple.
+                The ideal nature of the model makes it difficult to say something about the energy as the ideal motors deliver an infinite amount of power to the system.
+                However, in the next steps where the motors will be implemented the dynamics become very useful.
+
+            \subsubsection{Basic Motor Behavior}
+                The two ideal effort sources will be replaced with DC motor models.
+
+            
             \subsubsection{Implementation}
                 \rrot{Should this be here? Maybe in an appendix?}
                 \rro{Starting with very abstract model}

content/improvements.tex

@@ -0,0 +1,118 @@
+%&tex
+\chapter{Improved Design Method}
+\label{chap:improvements}
+    \rro{Introduce}
+    \rroi{Preliminairy design required complete new approach}
+    \rroi{Better tooling}
+    \section{System Baseline}
+        The preliminary design phase is not a competent approach for the initial design of a physical system.
+        In the waterfall-like approach each step is completely wrapped up before moving to the next step.
+        Every subsequent step provides more and more information about the design.
+        The information gives often insight in what could have been done better.
+        Although it is possible to review previous completed steps, there is quite a barrier to revise these steps.
+        Redoing previous work is demotivating and will be avoided as much as possible.
+        \rrotodo{Fix these citations}
+        This \emph{cost of change} is an inherent problem of the waterfall model \autocite{alshamrani, adenowo, petersen}
+
+        The development was confronted with this decision during the feature definition step in \autoref{sec:featuredefinition}.
+        The term feature is used for the different characteristics of the system.
+        Were these features map adequately to specifications and software, it does not represents hardware components.
+        Taking the following items from a single branch in \autoref{fig:robmosys}:
+        \begin{enumerate}
+        \item Draw a tweet on a whiteboard
+        \item Writing
+        \item Write a char at position
+        \item Move Marker on board
+        \item SCARA
+        \end{enumerate}
+        The first four items are characteristics of the system, where the first item is an abstract description of the complete system.
+        The subsequent items become more specific with each step.
+        The links between each subsequent item could be described "to perform this feature it is required that system can".
+        These items are derived from the design specification, but are also useful as software.
+        Item 4 would be the software implementation of the motor driver.
+        This motor driver is called by the arm controller that is implement for item 3.
+        The outlier in this list is the SCARA, it is not a sub-feature of \emph{Move marker on board}.
+        The SCARA has motors, mechanical linkage, sensors, as sub-components, but it is not a feature.
+
+        This was a known shortcoming during the case study.
+        One of the solutions that was discussed was to build a feature dependency tree with an iterative approach.
+        Each iteration of the design process would only cover one level of the dependency tree.
+        The first iteration would thus deliver specifications, initial design, order of operations, and tests for the mission level: "Draw a tweet on a whiteboard".
+        Followed by the second level which would repeat everything for \emph{Writing} and \emph{Wiping}.
+        This approach would probably be better that the current approach in the feature definition.
+        It would however require to review all the previous steps and rewrite most of the design method.
+        Furthermore, it was estimated that the additional effort required to restart the design process would negatively impact the overall evaluation of the design method.
+        Nevertheless is it required to find an improved design method.
+
+        The iterative design would help generate a better method, but it still generates a single dependency tree.
+        Therefore can only cover one type of dependency.
+        \textcite{kordon_model-based_2007} presents their \ac{mbed} that is used for two development projects within NASA's Jet Propulsion Lab.
+        The \ac{mbed} introduces a system hierarchy that separates the dependencies over three trees: specifications, functions, and components.
+        Additionally it adds interfaces, that connect different sub-components, and operational scenarios to this hierarchy.
+        The hierarchy is constructed iterative where each iteration generates a new level of sub-specifications, sub-functions and sub-components.
+
+        
+
+
+
+
+
+        
+        
+        
+
+
+
+
+        The term feature was used as a universal concept for design features, hardware features and software features.
+
+        This led to problems while creating a list of features.
+        This led to problems during the feature definition step.
+        The aim of the approach was to create a list of features.
+        Due to the different nature of the features it was impossible to create a single list of features.
+        Making a list for each group of features would result in problems with the selection of the features.
+
+        The problem with the features became apparent during the feature definition step in \autoref{sec:featuredefinition}.
+
+
+        Another problem is the waterfall-like approach.
+        
+        A possible solution that was discussed during the feature definition step in \autoref{sec:featuredefinition}.
+        The current steps are strongly detached from each other. 
+        
+
+        
+
+        
+        
+        \rro{In general, I underestimated the importance of the preliminary research}
+        \rroi{\textcite{broenink_rapid_2019} also skips this part.}
+        \rroi{As the focus of that paper was on the actual implementation, the preliminary phase was over looked}
+        \rroii{However, bringing a system into being, the preliminary design phase is extremely important}
+        \rro{For validation \textcite{garrett_322_2000} suggests:}
+            \rroi{Looking at comparable systems' specifications}
+            \rroi{Use of best engineering judgements}
+            \rroi{Apply early simulation results for feedback}
+            \rroi{A holistic view is required for validation of the initial design/specifications}
+        \rro{Without mechanical experience is difficult}
+        \rro{Better specification document is a team effort}
+            \rroi{A team with engineers in their own specific field that is included in the design}
+        \rro{\textcite{sheard_718_1998} discusses:}
+            \rroi{Mechanical requirements are directly derived from and bounded by physics}
+        \rro{Result: Mechanical specifications are easier to change}
+            \rroi{More room for initial simulations, before making concrete specs}
+    \section{Feature Separation}
+        \rro{During the case study, the planned approach was not possible}
+        \rro{Result: Improvised a structure that was loosly based on Robmosys}
+        \rro{Proposed Improvement: Split layout for requirements, functions and components from State Analysis \textcite{kordon_model-based_2007}.}
+
+        \rro{Instead of trying to start with a feature, a holistic model of essential elements should be created}
+        \rroi{In the holistic basic model, review the features/components on their feasibility}
+        \rroii{How likely is it that this specific component is going to work: And if not, what are the consequences? What do we need to change?}
+        \rroi{Then add detail to the different subcomponents of that model}
+
+    \section{Tooling}
+        \rro{20-sim lacks an object oriented approach}
+            \rroi{Adding detail to a submodel that is used more than once is a PITA}
+            \rroi{Every model is a deepcopy}
+

report.tex

@@ -161,40 +161,7 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
     \include{content/designcycle}
     \include{content/casestudy}
 
-
-\chapter{Improvements}
-\label{chap:improvements}
-    \section{Specifications}
-        \rro{In general, I underestimated the importance of the preliminary research}
-        \rroi{\textcite{broenink_rapid_2019} also skips this part.}
-        \rroi{As the focus of that paper was on the actual implementation, the preliminary phase was over looked}
-        \rroii{However, bringing a system into being, the preliminary design phase is extremely important}
-        \rro{For validation \textcite{garrett_322_2000} suggests:}
-            \rroi{Looking at comparable systems' specifications}
-            \rroi{Use of best engineering judgements}
-            \rroi{Apply early simulation results for feedback}
-            \rroi{A holistic view is required for validation of the initial design/specifications}
-        \rro{Without mechanical experience is difficult}
-        \rro{Better specification document is a team effort}
-            \rroi{A team with engineers in their own specific field that is included in the design}
-        \rro{\textcite{sheard_718_1998} discusses:}
-            \rroi{Mechanical requirements are directly derived from and bounded by physics}
-        \rro{Result: Mechanical specifications are easier to change}
-            \rroi{More room for initial simulations, before making concrete specs}
-    \section{Feature Separation}
-        \rro{During the case study, the planned approach was not possible}
-        \rro{Result: Improvised a structure that was loosly based on Robmosys}
-        \rro{Proposed Improvement: Split layout for requirements, functions and components from State Analysis \textcite{kordon_model-based_2007}.}
-
-        \rro{Instead of trying to start with a feature, a holistic model of essential elements should be created}
-        \rroi{In the holistic basic model, review the features/components on their feasibility}
-        \rroii{How likely is it that this specific component is going to work: And if not, what are the consequences? What do we need to change?}
-        \rroi{Then add detail to the different subcomponents of that model}
-
-    \section{Tooling}
-        \rro{20-sim lacks an object oriented approach}
-            \rroi{Adding detail to a submodel that is used more than once is a PITA}
-            \rroi{Every model is a deepcopy}
+    \include{content/improvements}
 
 \chapter{Discussion}
 \label{chap:discussion}