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{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}
                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}
            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}
                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 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}
            \rroit{Should this document be included in the report?}
            \rroi{Each test covers one or more specs}
            \subsubsection{Evaluation}
                \rro{Was quite easy to perform}
                \rroi{Difficult due to specs and features not working out as expected}
                \rroi{Most features could not be tested as the subsystem needs to be completed first}
                \rro{Tested by peer-review}
                \rroi{Found that a review without all the project information is difficult}

    \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}