mar/content/analysis.tex

%&tex
\chapter{Analysis}
\label{chap:analysis}
    \section{Design Methods}
    \rro{Introduce the three design methods}
        \rroi{Our design method is based on rapid development}
        \rroi{Rapid development also introduces variable detail method}
        \rroi{Where both methods lack we will fall back to Systems Engineering}
        \subsection{Rapid Development}
            \textcite{broenink_rapid_2019} presented an approach for rapid development of embedded control software.
            The approach can be split in to two parts.
            The first part consists of an cycle for rapid development.
            Where the features of a system are implemented based on agile software development.
            This cycle for rapid development aims to shorten the length of the development cycles.
            The second part consists of rapid development techniques.
            These techniques focus on dividing the development of a single feature in the system in small steps.
            Each step in the implementation adds detail to the implementation of the feature and is tested individually.
            The short cycles, small steps, and intermediate testing produce periodic feedback about the performance and validity of the system.
            This feedback helps to detect and fix faults in the development of the system immediately.

            Combining the two parts with a preparation and evaluation phase creates the bases of the methodology.
            The rapid development cycle becomes the outer cycle and the small step implementation is the inner cycle.
            The preparation step divines the different features and their corresponding levels of detail.
            The order of implementation of the features is important as features can depend on and influence each other.
            \rrot{Explain the different steps}
            \rroit{Do I want to 'copy' the steps from the paper? Do I even want to explain this?}
            \rrot{Insert figure from paper}
            
            \rro{Explain the design method of \textcite{broenink_rapid_2019}}
            \rro{RDM is forms the base of the design method in this thesis}
            \rroi{Order and split features and levels of detail as preparation}
            \rroi{Implement features one by one}
            \rroii{Each feature is implemented with increasing detail}
            \rroii{Begin with a basic implementation}
            \rroii{Increase detail in every step}
            \rroii{Repeat until tests are completed}

            \rro{Expected difficulty is that the hardware features do not always overlap with hardware components}
            \rro{Features are based on the initial design. However, the initial design has space for changes}
            \rroi{Therefore, it is difficult to 'order' the features as they are not fully determined}
        \subsection{Variable Detail}
            The previous section covered the design method for rapid development.
            Part of that is the addition of detail in small increments.
            \textcite{broenink_variable_2018} proposed an approach to organize these different levels of detail.
            The approach starts with evaluating the different signals of the system parts.
            Then based on these signals the interface and model structure is defined.

            \rro{Explain the design method of \textcite{broenink_variable_2018}}
            \rro{Proposes to begin with basic. and build up gradually}
            \rro{Basic model composed of only essential components}
            \rroi{Followed by hard limitation}
            \rroi{Followed by parasitic elements}
        \subsection{Systems Engineering}
            \rro{Explain the general idea of systems engineering}
            \rro{Quote Wikipedia: Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles.}

    \section{System Validation}
    \rro{An aspect of the design method, which is very important, is the validation of the design.}
        \rro{All design methods contain testing}
            \rro{Method developed to run physical behavior tests}
            \rroi{Does interpret simulation results not only end-values}
            \rroi{Used to validate behavior}
            \rro{Is currently in very experimental state}
            \rroi{If not this tool would have been used}
            \rroi{Thus, we will do it manually}
    
    \section{Case Studies}
    \rro{This section will be taken from the project plan}
        \subsection{Requirements}
            The goal is to find a case study that can be used to evaluate the design method within a Master's Thesis.
            Some requirements are defined to help the selection of a suitable case study.
            To fit the design in the period of a Master's Thesis it should not require more than 10 weeks.
            A fully-designed and constructed product is a nice result but is not required.
            The case study can be terminated at the end of the period if all the elements of the design method have been sufficiently evaluated.

            Although a finished product is not required, a partial prototype is part of the testing and validation procedure.
            As the design method focuses on the physical component, a mechanical prototype is important.
            The prototype would originally been constructed with the rapid prototyping facilities at the university.
            However, the COVID-19 pandemic forced the university to close and to work from home.
            This limited the rapid prototyping to DIY-tools and a 3D-printer.

            To comply with the limited time and construction options it is tempting to go with a simple system.
            Going for a simple system is not an option.
            The goal of the design method is to reduce the complexity of the development.
            Therefore, the case study should cover at least multiple features and interesting dynamics.
            Multiple features allow for multiple design cycles.
            Complex dynamics make multiple levels of detail possible.

            \rro{Buildable in 10 weeks}
            \rro{Hardware has to be build in a home setting}
            \rroi{Due to corona it was not possible to use lab-facilities}
            \rro{Dynamics should be complex enough to allow for multiple levels of detail.}
            \rro{Furthermore, as features are going to be implemented one by one, multiple features are required}

            \subsection{Tweet on a Whiteboard}
            \label{sec:whiteboardwriter}
            An example is for a system to be designed is a device that writes tweets on the white board.
            That would be device that can write on white board.
            This can be split in multiple features, with increasing complexity:
            \begin{enumerate}
                \item Moving the marker on the board: Simple XY-movement
                \item Lifting the marker from the board: Z-movement
                \item Erasing: End effector manipulation
                \item Changing color: Switching Marker
                \item Speed increase.
                \item Direct input.
            \end{enumerate}

            The moving and change of color have multiple solutions, which satisfy the features requirement.
            The complexity is also present in this example, the movement of the marker introduces multiple degrees-of-freedom.
            Furthermore, the speed increase adds complexity as well.
            The actuation of the system requires software.
            However, instead of characters on the board it is possible to make basic figures, like squares and circles.
            This minimizes the implementation of the software.

            \subsection{Peg-in-Hole}
            The peg-in-hole problem is quite generic.
            Which could just be a single dimension problem with a only one geometric shape.
            This can be extended with more shapes or dimensions.
            This example is not as specific as the board writer from the previous section.
            However, it is possible to describe multiple features.
            \begin{enumerate}
                \item Movement of the end effector
                \item Grabbing of cube, cylinder, triangle or sphere
                \item Manipulation of the object
                \item Placing the object in the correct hole
            \end{enumerate}
            The challenge with the peg-in-hole problem is often the alignment between the hole and the object.
            How this challenge manifests itself depends on the problem specification.

            In this case, the hardware and software design become intertwined.
            The physical grabbing of the shape is a hardware design problem.
            The actuation and sensing shifts the design problem in the direction of software.
            Determining the shape and correcting the misalignment with the hole is a software problem.
            Therefore, it is not possible to abstract all the software from this design.
            The gripper becomes a sensor-interface and introduces a design choice in the balance between hardware and software.
            Because good hardware design can simplify the software implementation, the software must be taken in to account.

            \subsection{RTK Calibration}
            A suggestion from Controllab Products B.V. is a setup for calibration of \ac{rtk}-modules.
            These modules use satellite positioning and are specified to be accurate at \SI{1}{\centi\meter}.
            Controllab Products B.V. is looking for a system that can verify those positioning values.
            This would require some measurable axis such that the 3D position can be determined.
            Furthermore, as this is planned to be used on ships, the influence of reflections or shielding has to be tested as well.
            The following list contain possible features:
            \begin{enumerate}
                \item Movement of a sensor
                \item Sensor feedback on position
                \item Test shielding
            \end{enumerate}

            Again, in comparison with the previous example, this requires also sensor-data processing.
            This is mainly a software problem. 
            However, the introduction of sensors in the system does give some interesting difficulties to be solved.

            \subsection{Decision}
                The preferred case study is the whiteboard writer in \autoref{sec:whiteboardwriter}.
                The Peg-in-Hole problem is mainly a control problem instead of a mechanical challenge.
                Therefore the Peg-in-Hole problem disqualifies as a good case study for goal of this Thesis.
                The RTK Calibration is a good case study.
                However, as it is a calibration device it has to be accurate.
                It is expected that this abstracts the complex dynamics from the design space.
                Overall the whiteboard writer gave more possibilities and is also a better demo.
                Sending a tweet to a robot has never been a bad demo.