Continued writing

content/casestudy.tex

@@ -19,6 +19,7 @@
         \autoref{tab:prepost} contains the set of paired questions.
         One question prior to the step and one question that reflects on that answer after the step.
         \autoref{tab:questionsmethod} is a list of questions that reflect on the design method itself.
+        \rrot{Add the additional questions}
 
         \begin{table*}
             \caption{Table with questions to evaluate the steps. With corresponding questions ordered in pre and post step columns.}
@@ -111,32 +112,209 @@
             \begin{itemize}
                 \item The system shall write a twitter message on the board.
             \end{itemize}
-            
+
+            \subsubsection{Evaluation}
+                The problem definition within this case study does not represent a conventional design process.
+                Therefore, the problem definition was not evaluated in this case study.
         \subsection{Specifications}
-            \rro{Present Specifications for Case}
+        \label{sec:specifications}
+            %\rro{Present Specifications for Case}
+            During this step the goal is to setup a document with concrete specifications of the system.
+            This resulted in a document that had a short description and a list of specifications.
+            The description described in short the general operating procedure.
+            As the writer has to write and update a tweet on the whiteboard, it must be able to write and wipe the board.
+            Furthermore, it should be able to draw 140 characters of readable text on the board.
+            For readability, the result has to be readable from 4 meters distance.
+
+            The specifications itself are written with \ac{ears} and are as follows:
+            \begin{itemize}
+                \item The Writer shall be able to write at least 50 characters per line.
+                \item The Writer shall be able to write at least 5 lines of text.
+                \item The Writer shall display the author, time, content, and number of retweets, favorites and replies in plain-text.
+                \item The Writer shall plot characters with a size that is readable from 4 meters for a person with good eyesight.
+                \item The Writer shall plot in a regular used font with corresponding character spacing.
+                \item When a new tweet is send to the Writer, the Writer, shall wipe the existing tweet and write down a new tweet.
+                \item If the Writer is not wiping or writing then the Writer shall not obstruct the view of the whiteboard.
+                \item While writing, the Writer shall have a writing speed of at least 1 character per second.
+                \item If the Writer is tasked to wipe the tweet, the Writer shall wipe the tweet within 60 seconds
+                \item When a reset-signal is send to the Writer, the Writer shall recalibrate its position on the board.
+                \item When a wipe-signal is send to the Writer, the Writer shall wipe the board clean.
+                \item The Writer shall not damage itself.
+            \end{itemize}
+
+            Additionally there are some restrictions on construction.
+            The tooling in limited to some hobby/DIY tools.
+            As the rapid prototyping facilities at the university are closed due to the Covid-19 pandemic.
+            \begin{itemize}
+                \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) in a, although limited, wide variation of size.
+                        \item Drill
+                        \item Screwtap set
+                        \item Jigsaw
+                        \item Wrenches
+                        \item Soldering iron
+                        \item Various Pliers 
+                        \item PLA 3D printer
+                    \end{itemize}
+            \end{itemize}
             \subsubsection{Evaluation}
-                \rro{EARS is a good method}
-                \rro{Expected walk in the park}
-                \rro{Was difficult to validate}
+                While performing this step it became clear that big improvements can be made.
+                The focus of this case is at the actual hardware implementation.
+                This caused the steps in the preliminary design to be overlooked.
+                The lack of a good problem description and not having an experienced design team makes the specifications even more difficult.
+                An extensive specification document would benefit the design process.
+                However, it would also be very time consuming and would not fit in the time frame of this thesis.
+                A conclusion similar to the evaluation of the problem description is that this unique case study is not a good basis for defining specifications.
+
+                Some concrete points from this step are:
+                \begin{itemize}
+                    \item \ac{ears} is very useful during for the specifications.
+                    \item Being thorough and complete is difficult without a team.
+                    \item Difficult to avoid ambiguity.
+                    \item Difficult to validate the specifications.
+                \end{itemize}
+
+                The latter point was reason to add additional questions to the evaluation form:
+                \begin{itemize}
+                    \item What is the method of testing?
+                    \item How did you test/validate the step?
+                \end{itemize}
+
         \subsection{Initial Design}
             \rro{Research on Existing Systems}
-                \rroi{Cable bot}
-                    \rroii{Cable Tensioning, helps avoid oscillations}
-                \rroi{Cartesian-coordinate robot}
-                \rroi{SKARA}
-                \rroi{Polar-coordinate robot}
-                \rroi{Combination of the different systems}
-            \rro{Choice of system}
-                \rroi{Combine Cable bot with SCARA}
-                    \rroii{Combination gives more dimensions of freedom to system}
-                    \rroii{Otherwise it is expected that modeling is too easy}
+            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.
+            These robots can be sorted in four different configurations
+            Each configuration is worked out and will be discussed here.
+            
+            \subsubsection{Cable Driven}
+                The cable driven robot is suspended with multiple cables.
+                The end-effector that contains the markers is moved along a board by changing the length of the cables.
+                The cable based positioning systems result in a end-effector with large range and high velocities.
+                A possible setup can be seen in \autoref{fig:cablebotdrawing}
+                \begin{figure}
+                    \centering
+                    \includegraphics[width=0.9\linewidth]{graphics/8564503-fig-1-source-large.png}
+                    \caption{Planar view of cable driven robot. \autocite{aguas_sliding_2018}}
+                    \label{fig:cablebotdrawing}
+                \end{figure}
+                Each of the cables can be motorized.
+                Unfortunately, this does make the system over-constrained.
+                However, it is possible to only motorize two of the four cables and pretension the other two.
+                This makes the system exactly constrained. 
+                Furthermore, the lower cables could be completely left out of the design.
+                This makes the design even simpler but the pretensions could help dampening the system.
+
+            \subsubsection{Cartesian-coordinate robot}
+                This configuration is a very common design for plotters.
+                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 very simple.
+                For the dimensions the length of the sliders define the limits.
+                
+            \subsubsection{Polar-coordinate robot}
+                This robot is a combination of a prismatic and a revolute joint.
+                Where the rotational joint can rotate the prismatic joint.
+                With this it can reach any point within a radius from rotational joint.
+                This is a little more complex design than the Cartesian robot.
+                
+                This robot has some disadvantages.
+                The range of the robot is defined by the length of the prismatic joint.
+                However, if the prismatic joint is fully retracted, the joint does not get shorter.
+                In that case the arm still protrudes on the other side.
+                Therefore the complete radius around the revolute joint cannot have any obstacles.
+                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 quadratic.
+                Moreover, the longer arm also introduces stiffness problems.
+            
+            \subsubsection{SCARA}
+                The SCARA robot is a configuration with two linkages that are via with rotational joints.
+                It can be compared to a human arm drawing on a table.
+                Similar to the Polar robot it can reach all points within a radius from the base of the robot.
+                However, the arm only protrudes half the radius.
+                Furthermore, depending on the configuration the of the arm the area where it protrudes can be significantly smaller.
+                However, the additional joint and extra arm length does add to the moment of inertia and gravitational torque similar to the polar robot.
+                The SCARA robot is therefore not a robot that is convenient with large working areas.
+                However, it can be really quick and precise in relative small areas.
+
+            \subsubsection{Choice of system}
+                Similar to the previous steps. 
+                The type of design has to aid the evaluation of this design method.
+                Where normally it would be beneficial to keep a design simple.
+                This implementation has to be complex enough.
+                
+                Based on the complexity the cartesian and polar coordinate robots are excluded.
+                Especially at higher speeds the SCARA becomes dynamically interesting due to the torque of both joints.
+                However, it is unlikely that the SCARA provides enough features to implement multiple features.
+                It was therefore decided to combine a small SCARA with a cable driven robot.
+                Where the SCARA can write a couple of characters at high speed from a fixed position.
+                The cables can than move the complete SCARA to the next position.
+
+                The combined system introduces sufficient complexity for the design method.
+                The cable robot and SCARA are both sub-systems of the complete writing robot that can be implemented separately.
+
             \subsubsection{Evaluation}
-                \rro{Difficult to validate if the system is working}
-                \rro{Design stays very rough}
-                    \rroi{Not sufficient detail to communicate to other engineers}
-                    \rroi{Lack in experience.}
-                \rro{Tested: Discussed and reviewed with daily-supervisor}
+                The initial design step felt like an actual start of the design process.
+                Looking at multiple solutions resulted in new insight of the systems.
+                However, this knowledge would have more useful when defining the specifications in \autoref{sec:specifications}.
+                Furthermore, the specifications were written with the whiteboard writer in mind.
+                This step was used to select the robot that would evaluate the design method.
+                Similar to the previous step it became more evident that the complete preliminary design phase was not adequate.
+
+                Validation of the decision was also lacking.
+                The combining both systems was discussed as the best option.
+                However, a simple model of the different proposed systems is needed to verify that decision.
+                And again, there was a lack of an experience to make a good trade-off.
+
         \subsection{Feature Definition}
+            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.
+            During this step it became clear that this approach was not feasible.
+            Prior to this step the expectation was that this step would produce three features that could be implemented.
+            These three features were the SCARA, the cable suspended carriage, and the end-effector.
+            However, independent of the interpretation of this step, the result was not the three expected features.
+
+            Why were those three features expected in the first place?
+            During the previous steps a useful evaluation was to anticipate for the subsequent steps.
+            Where one of the following steps is to implement an individual feature.
+            Therefore, it must be possible to implement the feature.
+            Separating the initial design into the smallest components that could still be implemented, resulted in the SCARA, carriage and end-effector.
+            
+            The problem is that these three components do not describe the complete system.
+            Some functions of the system (feature) is performed by a combination of the components.
+            Therefore can the components in the system not be seen as features of the system.
+            Defining the components as features of the system is not a solution.
+            The relations between the components and features is still required.
+            
+            %As the features describe the behavior of the components, it is not a solution to replace the features with components.
+
+            A solution to organize the relations between features and components was found in RobMoSys\footnote{\url{https://robmosys.eu/approach/}}.
+            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 can be seen 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.8\linewidth]{graphics/robmosys}
+                \caption{Feature Definition based on the separation of levels introduced by RobMoSys}
+                \label{fig:robmosys}
+            \end{figure*}
+
+            
+
+            
+            %In the design method by \textcite{broenink_rapid_2019} the features describe software components.
+            %Theoretically, each function in software can be implemented and tested individually.
+            %However, in a dynamic system, a single component 
+            %The SCARA, carriage and end-effector were selected as the smallest 
+            %Although.
+
             \rro{Goal: define features that can be implemented one by one}
             \rroi{Additionally, division of system requirements}
             \rro{Expected: A list of features, with corresponding dependencies}
@@ -156,6 +334,13 @@
                 \rroi{The mission, task, skill etc separation helped a lot in structuring}
                 \rroi{For now, this solution suffices to continue the case study}
                 \rro{Mid-way Conclusion: Preliminary requires large changes}
+                Even though, there is a feature definition that can be used in the next step, there remain a couple of difficulties.
+                There is still a really strong border between features and components.
+                And the single level of components makes it impossible to depict the dependencies between components.
+                Developing larger and complexer systems will have sub-components in the system, introducing even more dependencies.
+                Therefore, this is not a valid solution for feature definition.
+                Fortunately the current solution suffices to continue the case study.
+                
         \subsection{System Test Specification}
             \rro{Specify tests for the different specifications}
             \rro{Made a document with tests}
@@ -168,3 +353,50 @@
                 \rro{Tested by peer-review}
                 \rroi{Found that a review without all the project information is difficult}
 
+    \section{Detail Design}
+        \subsection{Feature Selection: First Iteration}
+            \subsubsection{Selection}
+                \rro{Compared: Dependency, tests coverage and risk/time ratio}
+                \rroi{First Feature/system to implement is End-effector.}
+                \rroii{Due to dependency and high risk/time}
+            \subsubsection{Implementation}
+                \rro{Plan: Model a gripper}
+                \rroi{Result: Underestimated Complexity}
+                \rroii{No debugging options for collisions in 3D-ME}
+                \rroii{Crash with software resulted in corrupted model}
+                \rro{Conclusion: not feasible in scope of case study}
+            \subsubsection{Evaluation}
+                \rro{Result is not as expected}
+                \rro{Risk/time factor proofed itself useful}
+        \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}
+            \subsubsection{Implementation}
+                \rrot{Should this be here? Maybe in an appendix?}
+                \rro{Starting with very abstract model}
+                \rroi{Forward and inverse kinematics}
+                \rro{Increasing model detail}
+                \rroi{2D physics model}
+                \rroi{Simple Motor model}
+                \rroi{Path planning}
+                \rroi{Stepper motor}
+                \rroi{3D physics arm}
+                \rroi{Marker lift (torque on joint)}
+                \rroi{Marker lift (Servo)}
+                \rro{Used 20-sim for dynamic behavior}
+                \rroi{Could determine physical limits}
+                \rro{Used openSCAD for geometric design}
+                \rroi{Could easily avoid collision between parts}
+
+                \rro{Implementation went smooth}
+                \rroi{Order of increase in detail more in line with Koen den Hollander.}
+                \rroi{Stepwise detail increase gives loads of feedback}
+                \rroi{Dynamics model gave feedback on required stepper torque}
+    \section{Testing}
+        \rro{Testing was difficult with only one finished component, however}
+        \rroi{Able to run draw three characters in 2 seconds}
+        \rroi{Able to draw a square in 1 second}
+    \section{Result}
+        \rro{Created a model in 20-sim and openscad}
+        \rro{Build a physical prototype}

graphics/robmosys.tex

@@ -0,0 +1,38 @@
+\documentclass{standalone}
+\usepackage{tikz}
+\usetikzlibrary {arrows.meta,graphs,graphdrawing} \usegdlibrary {layered}
+
+\begin{document}
+
+\begin{tikzpicture}[nodes={text height=.7em, text width=1.8cm, align=center,
+draw=black!20, thick, fill=white, font=\footnotesize},
+>={Stealth[round,sep]}, rounded corners, semithick]
+
+\graph [layered layout, level distance=1.5cm, sibling sep=.5em, sibling distance=1.5cm, sweep crossing minimization] {
+    "Mission" -> "Task" -> "Skill" -> "Function" -> "Component";
+
+    "Draw a tweet on a board" -> "Writing";
+    "Writing" -> { "Write a char at position", "Hold Marker", "Move to position" };
+    "Write a char at position" -> { "Move marker on board", "Lift Marker" };
+    "Hold Marker" -> "Switch Tools";
+    "Move marker on board" -> "SCARA";
+    "Lift Marker" -> "End-effector";
+
+    "Draw a tweet on a board" -> "Wiping";
+    "Wiping" -> { "Wipe Area", "Hold Wiper", "Move to position" };
+    "Hold Wiper" -> "Switch Tools";
+    "Move Wiper on Board" -> SCARA;
+    "Wipe Area" -> "Move Wiper on Board";
+
+    "Move to position" -> "Move carriage" -> "Cable driven Carriage";
+    "Switch Tools" -> {"End-effector", "SCARA"};
+};
+
+ %   \graph [layered layout] {
+ %       1 -> 2 -> 3 -> 4;
+ %   };
+
+
+
+\end{tikzpicture}
+\end{document}

report.tex

@@ -161,57 +161,14 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
     \include{content/designcycle}
     \include{content/casestudy}
 
-    \section{Detail Design}
-        \subsection{Feature Selection: First Iteration}
-            \subsubsection{Selection}
-                \rro{Compared: Dependency, tests coverage and risk/time ratio}
-                \rroi{First Feature/system to implement is End-effector.}
-                \rroii{Due to dependency and high risk/time}
-            \subsubsection{Implementation}
-                \rro{Plan: Model a gripper}
-                \rroi{Result: Underestimated Complexity}
-                \rroii{No debugging options for collisions in 3D-ME}
-                \rroii{Crash with software resulted in corrupted model}
-                \rro{Conclusion: not feasible in scope of case study}
-            \subsubsection{Evaluation}
-                \rro{Result is not as expected}
-                \rro{Risk/time factor proofed itself useful}
-        \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}
-            \subsubsection{Implementation}
-                \rrot{Should this be here? Maybe in an appendix?}
-                \rro{Starting with very abstract model}
-                \rroi{Forward and inverse kinematics}
-                \rro{Increasing model detail}
-                \rroi{2D physics model}
-                \rroi{Simple Motor model}
-                \rroi{Path planning}
-                \rroi{Stepper motor}
-                \rroi{3D physics arm}
-                \rroi{Marker lift (torque on joint)}
-                \rroi{Marker lift (Servo)}
-                \rro{Used 20-sim for dynamic behavior}
-                \rroi{Could determine physical limits}
-                \rro{Used openSCAD for geometric design}
-                \rroi{Could easily avoid collision between parts}
-
-                \rro{Implementation went smooth}
-                \rroi{Order of increase in detail more in line with Koen den Hollander.}
-                \rroi{Stepwise detail increase gives loads of feedback}
-                \rroi{Dynamics model gave feedback on required stepper torque}
-    \section{Testing}
-        \rro{Testing was difficult with only one finished component, however}
-        \rroi{Able to run draw three characters in 2 seconds}
-        \rroi{Able to draw a square in 1 second}
-    \section{Result}
-        \rro{Created a model in 20-sim and openscad}
-        \rro{Build a physical prototype}
 
 \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}