| @@ -1,64 +1,13 @@ | |||
| %&tex | |||
| \chapter{case method} | |||
| \chapter{Case study Method} | |||
| \label{chap:case_method} | |||
| The goal of this case study is to evaluta the design plan as presented in the previous chapter. | |||
| The evalutation is done by developing a system according to the design plan. | |||
| Ingeneral, the method of the case study follows all the steps of the design plan. | |||
| Additionally, an evaluation protocol ensures that the development is evaluated consistently. | |||
| The last important thing is a subject of design that is developed in the case study. | |||
| The next sections present the evaluation protocol and the subject of design. | |||
| \section{Subject of Design} | |||
| The choice in subject of design has a strong influcence on the evaluation of the design plan. | |||
| A set of requirements is used to ensure that the optimal subject of design is selected. | |||
| \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. | |||
| \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{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. | |||
| \section{Evaluation Protocol} | |||
| A survey is design to assess how the method is applied during the case study. | |||
| The survey specifies a list of questions. | |||
| @@ -127,3 +76,68 @@ A set of requirements is used to ensure that the optimal subject of design is se | |||
| 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. | |||
| \section{Subject of Design} | |||
| The choice in subject of design has a strong influence on the effectiveness of the evaluation of the design plan. | |||
| To ensure the best subject of design a list of requirements is composed. | |||
| Based on this list the best subject of design is a "Tweet on a whiteboard writer", which will be referred to as system. | |||
| Other subjects were considered, but did not meet the desired requirements. | |||
| The most important requirement is that, while developing the system, the different aspects of the design plan are used. | |||
| Taking into account that there is a limited time budget and that the system must be within the scope of the design plan, the set of possible subjects of design is slim. | |||
| The time budget is set to 10 weeks of development and the system must have a dynamic system that can be controlled. | |||
| The tweet on a whiteboard fits within these requirement as it can have interesting dynamics and has multiple features. | |||
| Although the system could be seen as a simple wall plotter with simple XY-movement, it has alternative implementations that achieve more complex XY-movement. | |||
| %%%%%% Ligt toe dat er meerdere features zijn. | |||
| \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. | |||
| \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{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. | |||