mar/content/casestudy.tex

%&tex
\chapter{Case Study: Whiteboard writer}
\label{chap:casestudy}
    \section{Monitoring}
        A survey is design to assess how the method is applied during the case study.
        The survey specifies a list of questions.
        All the questions will be adressed for each step in \autoref{fig:flowgraph}.
        Part of the questions will be answered prior to the step.
        The rest of the questions will be answered after the step.
        The questions are not soley to measure the effectiveness of the design method, but as well to investigate the usability.
        For a good usability the step feels intuitive and does not interfere with the workflow.

        Important is that these answers will be used to improve the design method for the next cycle.
        Resulting in a better suited method at the end of the development.
        This survey will be evaluated as well in each step.
        Because it is expected that there are points of interest that are looked over.
        It could be that a step is split in multiple ones or that questions are added during the case study.

        \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.}
            \label{tab:prepost}
            \begin{tabular}{|p{0.35\paperwidth}|p{0.35\paperwidth}|}
                \hline
                \vspace{1mm} \large{Prestep}  & \vspace{1mm} \large{Poststep} \\
                Questions prior to the execution of the step to set a baseline. & Questions after the execution of the step to check if the implementation met the expectations. In hind-sight, what should have been executed differently?\\
                \hline 
                \textbf{What was the previous step?} & \textbf{What will be the next step?} \\
                Does this influence this step? Is this a review? & Moving forward or is a review required of previous step(s)? \\
                \hline
                \textbf{Describe the plan of action.} & \textbf{Explain any deviations from the plan of action.} \\
                What is the next step going to be? How is it going to be executed? & What changed during the execution, what deviations where taken and why? \\
                \hline
                \textbf{What is the expected workload?} & \textbf{Was the workload different than expected?} \\
                How many hours are required for the execution of the step? Also give a range in your incertainty. & How much time was invested in the step? Why was it more or less than expected? \\
                \hline
                \textbf{What is the expected result of the step?} & \textbf{Is the result as expected?} \\
                At the end of the step, what is the expected result? & Does the result match the description made prestep? Why does it not match? \\
                \hline
                \textbf{What is the expected feasibility?} & \textbf{Was the expected feasibility of the implementation accurated?} \\
                What are the problems you expect during implementation? Why? & Even if the implementation succeeded, the feasibility does not have to be 100\%. Give an estimate for the feasibility now that the implementation is finished. Explain the difference with the prestep feasibility.\\
                \hline
            \end{tabular}
        \end{table*}

        \begin{table*}
            \caption{Table with questions to evaluate the design method itself}
            \label{tab:questionsmethod}
            \begin{tabular}{|p{0.35\paperwidth}|}
                \hline
                \textbf{Is this method a suitable approach for the hardware design?}\\
                Are there aspects in the hardware design that is not covered by the method? Or is the method not suited at all for hardware? Why not? How to do it different? \\
                \hline
                \textbf{Does the method contain counter-intuitive steps?} \\
                Are there steps that feel not optimal? Is it appealing to execute the step different? Is it just getting used to? Or really inefficient?\\
                \hline
                \textbf{What is the feasibility of this step in the method itself?} \\
                Not the execution of the step, but the step itself. Are those steps realistic? How can the method be improved? Why? \\
                \hline
                \textbf{Are there questions that can be added to this evaluation?} \\
                Can we add step specific questions or general questions to improve the evaluation? \\
                \hline
            \end{tabular}
        \end{table*}

        \subsection{Reporting}
        To answer all these questions and record all the steps a template was made.
        This template is a markdown-document that contains all the questions.
        The filled in documents will be stored in a git-repository.
        With continuous integration the documents will be merged to a single pdf.

        The development of the hardware will be done in a separate git repository.
        Each step will have its own issue. 
        This issue has a description and a checklist for the evaluation.
        Commits will be referenced to the issue, in that way all commits are grouped and can be tracked in the issue.

        %\rro{Use forms to evaluate the method}
        %\rroi{Questions answered before and after each step}
        %\rroi{Forms are also updated during the design}
    \section{Preliminary Design}
        \subsection{Problem Definition}
            The whole design process is initiated with the problem definition.
            For this case study, the problem definition is a bit different.
            In preparation of the case study it was decided to design a Whiteboard Writer from \autoref{sec:whiteboardwriter}.
            The Whiteboard writer was chosen because it would test the most aspects of the design method during the case study.
            In other words, a problem was needed that could be solved.
            And the problem needed to be complex enough so that the design method could be tested.

            However, during the case study, decisions have to be made about the solution space.
            Some of these decisions are not related with the testing of the design method itself.
            In these situations it is good to have a more concrete goal.
            Therefore, it is decided that the whiteboard writer has to be able to put a twitter message on the board.

            Normally the goal of the problem definition would be to describe the problem that needs to be solved.
            Testing the design method is in this case the problem, which makes it tightly coupled.
            Furthermore, a good problem definition focusses on getting the stake holders on the same line \autocite{shafaat_exploring_2015}.
            However, as the case study is performed by the author, there is only one stake holder.
            Discussion, communication and interaction between team member improves the problem solving in general \autocite{lamb_221_2008}.

            Even though the problem definition stayed in a very minimalistic state.
            The core goals are as follows:
            \begin{itemize}
                \item The system under design shall be used to evaluate the design method.
                \item Engineering decisions are made, in the first place, to aid the evaluation of the design method.
            \end{itemize}

            Secondary goals can be described as:
            \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}
        \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{enumerate}
                \item The Writer shall be able to write at least 50 characters per line.
                \item The Writer shall be able to write at least 5 lines of text.
                \item The Writer shall 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{enumerate}

            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}
                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}
        \label{sec:initialdesign}
            \rro{Research on Existing Systems}
            The initial design started with a design space exploration.
            The goal was to collect possible solutions and ideas for the implementation.
            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 full setup can be seen in \autoref{fig:general_design}.
            \begin{figure}
                \centering
                \includegraphics[width=\linewidth]{graphics/general_design.pdf}
                \caption{Rough design of the system. The carriage is in this situation blue and the SCARA is red. The two cable running to the top-corners of the whiteboard move the carriage.}
                \label{fig:general_design}
            \end{figure}


                The combined system introduces sufficient complexity for the design method.
                The cable robot and SCARA are both sub-systems of the complete writing robot that can be implemented separately.

            \subsubsection{Evaluation}
                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}
            \rro{Could define features, but non of them described mechanical components that could be implemented.}
            \rro{Result: Improvised a structure that was loosely based on RobMoSys}
            \rroi{The lose features:}
            \rroii{End-effector}
            \rroii{SCARA}
            \rroii{Carriage}
            \subsubsection{Evaluation}
                \rro{Multiple problems:}
                \rroi{Specifications were to broad or to specific}
                \rroi{Taking the following steps in to account, none of the features made sense}
                \rroii{None of the features were something that could be modeled}
                \rroii{Type of motor was depending on the forces required}
                \rro{Inspired from RobMoSys we made a tree structure}
                \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 complex systems will have sub-components in the system, introducing even more dependencies.
                Therefore, this is not a valid solution for feature definition.
                Fortunately the current solution suffices to continue the case study.
                
        \subsection{System Test Specification}
            The last step of the preliminary design is to design tests.
            The tests are designed around the specifications.
            However, during the creation of the tests it was found that the list of specifications were lacking.
            Furthermore, the previous steps did not provide any order of operation.
            During this step the order of operation and additional specifications are determined.
            
            There are two modes of operation: writing and wiping.
            The writing operation can be split in the following steps:
            \begin{enumerate}
                \item Move cable driven carriage to position of characters.
                \item Write three characters with the SCARA.
                \item Repeat step 1 and 2 till the Tweet is on the board.
                \item Move carriage away from the text on the board.
            \end{enumerate}
            
            The other operation is wiping.
            This is similar to the operation of writing with the following steps:
            \begin{enumerate}
                \item Move cable driven carriage to position of characters.
                \item Clear the area in reach of the SCARA.
                \item Repeat step 1 and 2 till the Tweet is removed from on the board.
            \end{enumerate}
            Furthermore, switching between the states requires the tool to be switched.
            As this is a difficult operation there are not yet requirements or order of operation specified.

            Based on the order of operation, the following specifications were added to the list in \autoref{sec:specifications}:
            \begin{enumerate}
                \setcounter{enumi}{11}
                \item While writing, the SCARA shall have a writing speed of at least 1.5 characters per second.
                \item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least 3 characters at that position.
                \item When the SCARA finished writing at their current position, the Carriage shall move the SCARA to it's next position where it can write the subsequent characters.
                \item When the SCARA has to be moved to a new position, the Carriage shall perform this movement within 1 second.
            \end{enumerate}
            These additional specifications are also based on the combined system decission that was made in section \autoref{sec:initialdesign}.
            These specifications distribute responsibility between sub-components.
            
            With the updated specifications it was possible to create a number of test cases.
            In total there are five small test cases and four large test cases.
            The small tests cover a sub-system and the large tests apply on the complete systems.
            Each tests has a list of specifications that are covered with the test and for smaller tests the subsystem under test is also determined.
            With a short description it is described how the test should be performed.
            
            One of the small tests is performed by drawing a square:
            \begin{description}
                \item[Sub-systems] SCARA
                \item[Specifications] 3, 7, 11, 13
                \item[Description]
                    The SCARA must draw a square of at least 50 mm high and 70 mm wide.
                    This box is large enough to draw at least 3 characters.
                    This square should be drawn within one second.
                    If it is slower than that, it is not able to achieve specification 7.
            \end{description}
            \rrot{TODO: Make clear that the tests case ends here...}
            Repeatability is tested in one of the large tests.
            \begin{description}
                \item[Specifications] 3, 4, 9, 11
                \item[Description]
                    To test the repeatability of the system must do four things:
                    \begin{itemize}
                        \item The system will be reset.
                        \item Draw multiple squares (60 mm x 60 mm) at a random position within the drawing range (1000 mm x 300 mm).
                        \item The system will be reset again.
                        \item Then in a random order, at least different from the order of squares, a circle with a 55 mm diameter must to be drawn inside the squares.
                    \end{itemize}
                    The test is successful if the circles are not drawn outside of the squares.
            \end{description}
            \rrot{TODO: Make clear that the tests case ends here...}
            \rrot{TODO: Add the tests to the appendix}
            All the tests are included in the appendix.
            \rro{Specify tests for the different specifications}
            \rro{Made a document with tests}
            \rroit{Should this document be included in the report?}
            \rroi{Each test covers one or more specs}
            \subsubsection{Evaluation}
                This step was completed with not many difficulties.
                The specific order of operation and extra specifications should not be part of this step.
                It was already concluded that the steps in the preliminary design were not as expected.
                The fact that this step resulted in an additional changes only adds to that conclusion.
                
                The design of the test cases resulted in valuable information about the system.
                This information would be very useful in an earlier stage of the preliminary design.

        \subsection{Recap}
            The test definitions of the last step conclude the preliminary design phase.
            This preliminary design shows a clear notion of a hasty execution from a design standpoint.
            The preliminary design was performed over a period of 5 weeks, by one developer with little experience in design documentation.
            This makes notion of hasty not surprising for this unproven design method.
            That does not mean that this preliminary design is a waste of time.
            From the evaluation moments during the preliminary phase there are a couple of interesting points.
            \begin{itemize}
                \item The lack of a design team with experienced engineers would drastically improve the execution of this design phase.
                    Such a team is also able to find the smaller problems of such a design phase, which are currently completely overlooked.
                \item It is not possible to view each step in the design process as singular.
                    Each step creates more insight and information about the final design.
                    Making a very strong separation between the steps forces the developer to make decisions on to little information.
                \item The term features has to be split in to functions and components for a hardware design.
                    The actual implementation are the components such that they can perform the function.
            \end{itemize}

            Another point was noticed while evaluation the complete preliminary design phase.
            The lack of a team makes it easy to forget documenting intuitive design decisions.
            Although the design method is followed as closely as possible, it often occurs that a decision is made outside of the working environment.
            This was noticed during the writing of this chapter that some design decisions were completely missing.
            However, during the next phase, these decisions do play a crucial role.
            Therefore, this section will give a short recap of the planned design.

            \subsubsection{Complete system}
            From the initial design the abstract shape of the design is clear.
            This is still in line with \autoref{fig:general_design}.
            The SCARA is small and can therefore move the arm quick with a fine precision.
            At the end of the SCARA there is a end-effector that can grab, hold, end release tool.
            It holds a marker while writing and with help of the SCARA it can release the marker.
            Then it can grab a cleaning tool to erase whiteboard.
            To compensate for the small reach of the SCARA, the SCARA will be mounted to a carriage.
            This carriage is suspended from cables and can move along the whiteboard.
            The cables give the system a enormous range and velocity.
            However, it is not very good in acceleration as cables cannot push.
            This makes it suitable for the large and course movements along the board, which complements the movement characteristics of the SCARA.
            

            
            \subsubsection{SCARA}
            The central component of the system is the SCARA.
            There are a couple of design options for the SCARA.
            As the dynamic complexity is a important part of this design, there will be two arms.
            There are some different options for the configuration of the arms and their actuation.
            \autoref{fig:configurations} shows four of the possible configurations that are considered during the design phase.
            There are still options about where to place the motors and how to connect the joints.
            \rrot{Figure needs some graphic improvement}
            \begin{figure}
                \centering
                \includegraphics[width=\linewidth]{graphics/IMG_20201001_134140.jpg}
                \caption{Four different SCARA configurations}
                \label{fig:configurations}
            \end{figure}

            \subsubsection{End-effector}
            The end-effector is the connection between the SCARA and the tool.
            It has two main functions: lifting the tool from the board and switching the tool.
            The tool switching functionality is performed by the SCARA as well, by moving the end-effector to the right position.
            However, the role of the SCARA is strongly dependent\footnote{ Note, that this dependency exists but not represented in \autoref{fig:robmosys} due to the limitation of the current method.} on how the end-effector is implemented.
            For the grabbing function there is a configuration that uses a spring-loaded clamp.
            Where one side of the clamp is longer so it can be opened by moving the SCARA.
            This operation is shown in \autoref{fig:gripper}
            \begin{figure*}
                \centering
                \includegraphics[width=\linewidth]{graphics/IMG_20201001_144018.jpg}
                \caption{Operation principle of a spring-loaded tool clamp showed from left to right. The green circle represents the tool and the red arm a tool holder. The solid ground is what pushed the upper arm open so the marker can be placed in the tool holder.}
                \label{fig:gripper}
            \end{figure*}

            Another dynamically simpler option is to open the clamp with a motor.
            The motor adds weight to the end-effector which might require the SCARA to operate slower or to be build stronger.
            This component is probably the most difficult one because it requires clamping of the tools.
            Modeling this behavior is difficult as it will involve contact dynamics.

            \subsubsection{Cable driven Carriage}
            The end-effector and the SCARA are moved all together on a carriage.
            The carriage will be suspended from two or four cables.
            A configuration with two cables is the simplest.
            However, the tension in this system is generated by the gravitational pull.
            This introduces limitations in the acceleration of the system.
            If the carriage moves upwards and the cable pulleys stop.
            The carriage is only decelerated by the force of gravity.
            Moving over its set point, followed by crashing down in to the cables.
            
            However, making the system with four motorized pulleys makes the system over constrained.
            This will solve the acceleration problem. But it will create a difficult positioning system.
            As all the wires have to be tensioned but not distort the movement by restricting the other motors.

            \subsubsection{Electronics}
                Although this mainly is a hardware design, there is going to be some control-software.
                For this the likely option is a STM nucleo board with RIOT-OS as a embedded OS.
                This choice is mainly because of previous experience and local knowledge of the operating system.
                


    \section{Detail Design}
        With the preliminary design finished the first feature can be implemented.
        Therefore, it has to be determined what that first feature is.
        This is followed by building a basic model of the first feature.
        Over multiple cycles detail will be added to that model.
        When the model is sophisticated enough these steps are repeated for the next feature.
        \subsection{First Feature Selection}
            Three different components were defined as hardware features that could be implemented.
            The feature selection method as defined in \autoref{sec:feature_selection} will be applied to these features.
            According to the method, the dependencies, test coverage and risk/time factor have to be determined.
            All the information for this selection is shown in \autoref{tab:firstfeatureselection}
            \begin{table}[]
                \caption{Overview of the different features and their dependencies, number of tests that can be completed and the risk/time factor.
                The risk/time factor is calculate as risk divided by time with \emph{low} = 1, \emph{medium} = 2 and \emph{high} = 3.}
                \label{tab:firstfeatureselection}
                \begin{tabular}{llllll}
                    \hline
                    Feature      & Dependency   & Tests         & Risk   & Time   & Risk/Time        \\ \hline
                    Scara        & End-effector & 3             & medium & medium & 1                \\
                    End-effector & -            & 2             & high   & medium & 1.5              \\
                    Carriage     & -            & 2             & low    & medium & 0.5              \\ \hline
                \end{tabular}
            \end{table}

            The SCARA is dependent on the end-effector, as was explained in the initial design.
            However, for the carriage no dependency was defined even though it has to lift the other two components.
            This is mainly because the behavior of the SCARA changes depending on the end-effector, resulting in a possible design change.
            For the carriage it only changes the mass that has to be lifted.
            Upgrading the motor torque is a minor parametric change and the dependency is therefore insignificant.

            The testing number is directly the number of tests that can be completed by implementing that single component.
            For the risk and time it was a engineering judgement and no specific protocol to determine the values.
            The estimated risk is high for the end-effector due to the collision dynamics of the operation.
            It has to grab something and that is difficult to model. Furthermore, it was not known if that design would work.
            The SCARA has the most moving parts, but no difficult dynamics and has therefore an estimated risk of medium.
            For the carriage the there was no real risks and got therefore a low risk indication.
            
            The SCARA would be implemented first based on number of tests, but is dependent on the end-effector.
            Beginning with the end-effector is an obvious choices. It unlocks the SCARA and has the highest risk/time factor.

            \subsubsection{Evaluation}
                This first step of the detail design phase did go well.
                A more refined method for this step could be very useful.
                But the risk and time assessment will probably always be a engineering judgement from the developer.
                Within a design team a form of planning poker\footnote{\url{https://en.wikipedia.org/wiki/Planning_poker}{Wikipedia entry: Planning Poker}} could be a good option.
            
                \rro{Compared: Dependency, tests coverage and risk/time ratio}
                \rroi{First Feature/system to implement is End-effector.}
                \rroii{Due to dependency and high risk/time}

        \subsection{End-effector model}
            The end-effector will operate as an interface between the SCARA and the different tools.
            For that it has to be able to grab and release the tools.
            The initial design is shown in \autoref{fig:gripper}. 
            With only some experience in modelling with collisions the decision was made to try to make some collisions in the 20-sim 3D mechanics editor.
            Unfortunately, collisions in a 20-sim model are difficult.
            There is little tooling available and there are no debugging options if the model does not behave as expected.
            The marker kept falling trough the gripper or flew away.
            With the small amount of progress made in two days the implementation was not promising. 
            A crash in the software caused the model to corrupt, where the complete configuration of the shapes and their collisions was lost.
            Therefore it was decided that end-effector would be removed from the design.

            With the end-effector removed, the SCARA will get a direct connection with the marker.
            The lifting of the marker will be included in the SCARA as well.
            Furthermore, this means that the wiping will no be possible via the SCARA.

                \rro{Plan: Model a gripper}
                \rroi{Result: Underestimated Complexity}
                \rroii{No debugging options for collisions in 3D-ME}
                \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}
                The lost progress of the model is unfortunate, but the implementation did not go expected anyway.
                It was probably for the best as it forced an evaluation of the design and avoided a tunnel vision while trying to get it to work.
                However, it did show the value of the risk/time analysis.
                This early failure resulted in changes for other components.
                But as none of the components were implemented yet, no work was lost.
                

%%%%%%%%%%%%%%%%%%%%%%%

        \subsection{Feature Selection: Second Iteration}
            \subsubsection{Selection}
                \rro{Scara is next in selection}
                \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}