| @@ -1,64 +1,13 @@ | |||||
| %&tex | %&tex | ||||
| \chapter{case method} | |||||
| \chapter{Case study Method} | |||||
| \label{chap:case_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} | \section{Evaluation Protocol} | ||||
| A survey is design to assess how the method is applied during the case study. | A survey is design to assess how the method is applied during the case study. | ||||
| The survey specifies a list of questions. | 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. | Each step will have its own issue. | ||||
| This issue has a description and a checklist for the evaluation. | 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. | 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. | |||||