master-thesis
/
mar
1
0
Fork 0
Código Incidencias 0 Pull Requests 0 Lanzamientos 16 Wiki Actividad
Explorar el Código

Update report

rro
Wouter Horlings hace 5 años
padre
52b84ff57e
commit
d9180ae90b
Se han modificado 5 ficheros con 471 adiciones y 91 borrados
Dividir vista
Opciones de diferencias
Mostrar estadísticas Descargar archivo de parche Descargar archivo de diferencias
  1. +164
    -0
      content/analysis.tex
  2. +170
    -0
      content/casestudy.tex
  3. +4
    -0
      content/designcycle.tex
  4. +1
    -1
      include
  5. +132
    -90
      report.tex

+ 164
- 0
content/analysis.tex Ver fichero

@@ -0,0 +1,164 @@
%&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.

+ 170
- 0
content/casestudy.tex Ver fichero

@@ -0,0 +1,170 @@
%&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.

\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}
\subsection{Specifications}
\rro{Present Specifications for Case}
\subsubsection{Evaluation}
\rro{EARS is a good method}
\rro{Expected walk in the park}
\rro{Was difficult to validate}
\subsection{Initial Design}
\rro{Research on Existing Systems}
\rroi{Cable bot}
\rroii{Cable Tensioning, helps avoid oscillations}
\rroi{Cartesian-coordinate robot}
\rroi{SKARA}
\rroi{Polar-coordinate robot}
\rroi{Combination of the different systems}
\rro{Choice of system}
\rroi{Combine Cable bot with SCARA}
\rroii{Combination gives more dimensions of freedom to system}
\rroii{Otherwise it is expected that modeling is too easy}
\subsubsection{Evaluation}
\rro{Difficult to validate if the system is working}
\rro{Design stays very rough}
\rroi{Not sufficient detail to communicate to other engineers}
\rroi{Lack in experience.}
\rro{Tested: Discussed and reviewed with daily-supervisor}
\subsection{Feature Definition}
\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}
\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}


+ 4
- 0
content/designcycle.tex Ver fichero

@@ -18,6 +18,8 @@
In \autoref{sec:featuredefinition} the feature definition step is explained.
Then the system testing is introduced, followed by feature selection, as the test-cases will influence the feature selection.

\rrot{This figure needs to be improved}
\rroit{Needs the list which is also visible in the evaluation plan in projectplan section 4.1}
\begin{figure}
\includegraphics{graphics/flowgraph.png}
\caption{Flow graph for the design steps. After a successful system testing the feature is completed and specifications are updated. Then the next feature is selected and implemented.}
@@ -30,6 +32,7 @@ The preliminary design is the first step of this design method.
The steps in the preliminary design are expected to only be executed once.
However, any mistakes made, could require a review of one or more steps of the preliminary design.
\subsection{Problem definition}
\rrot{Explain why, what and how for this problem}
The first step of the design cycle is to describe the problem that has to be solved.
A clear and concise problem definition increases a successful design process.
It gives a better basis for the system requirements.
@@ -185,6 +188,7 @@ However, any mistakes made, could require a review of one or more steps of the p
Therefore, features that can make a requirement testable can be selected by the developer to be implemented first.

\subsection{Risk Assessment}
\rrot{Term to use here is "Cost of Change"}
It is important to clear the risks in a development in the shortest amount of time.
If a development runs into problems near the end of its completion all investments are lost.
All features will be ranked on their feasibility and time required for implementation.


+ 1
- 1
include

@@ -1 +1 @@
Subproject commit addd9d0ce841ab33a93d1d618e72637fcfc30817
Subproject commit 1466292b9a964fefb33650f52b6bdc3b2edd76a7

+ 132
- 90
report.tex Ver fichero

@@ -1,3 +1,4 @@
%&tex
\documentclass[english,titlepage,nomath]{siltex-report}
\include{include/preamble}

@@ -42,102 +43,124 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
\tableofcontents
\include{include/acronyms}
\chapter{Introduction}
\section{Context}
\section{Problem Statement}
\section{Context of this Thesis}
%Wat is het probleem?
% Cyber Physical systems worden steeds complexer.
% De complexiteit bemoeilijkt de ontwikkeling significant.
%Hoe proberen we dat op te lossen?
% het paper introduceerd een gestructureerde design methode voor CPS.
% De methode breekt de ontwikkeling op in kleine stukken die elk individueel getest kunnen worden.
% Hierdoor kunnen in een vroeg stadium fouten in de ontwikkeling worden gedetecteerd.
% De methode is ontworpen rondom de ontwikkeling van embedded control software.
% Het dynamische model en de control law worden aan de hand van deze methode ontwikkeld.
% De case in het paper baseerd het dynamische model aan de hand van bestaande hardware.

% Maar ontwikkeling van een nieuw CPS betekent dat er ook het fysieke deel van het systeem ontwikkeld moet worden.
% Of de voorgestelde ontwerpmethode geschikt is voor het ontwikkelen hardware dan ook het doel van dit onderzoek.

%
% Als de methode gebruikt gaat worden voor de ontwikkeling van een CPS from scratch moet er onderzocht worden of deze methode past bij het ontwikkelen van nieuwe hardware.
%
% Maar Cyber Physical systems zijn multi disciplinair waarvan embedded control software een is.
Design methodology for \ac{CPS} is one of the research topics within the department of Robotics and Mechatronics.
A design method for rapid development of embedded control software is proposed by \autocite{broenink_rapid_2019} as part of this research topic.
The design method in the paper is used to design a control system on an existing hardware system.
The presented result shows a working control system for a small segway.
Broenink and Broenink emphasize that "this [result] does not mean that the same techniques cannot be applied to the physical part of the system."
This thesis will analyse if these techniques can be applied to the development of a physical system.

%The goal of this thesis is to present a method that is suitable for designing the physical part of a system.
%The method is based on the rapid development design method.
%Initially,
%to analyse which techniques are suitable to a physical system development.









\section{Research Objective}

In the basis this research started with the question if the design method can be applied to the physical part of a system.
That answers is a quick no.
In the early stage of the research it was found that some techniques cannot be copied from a software development into a hardware development.
It is necessary to analyse which techniques cannot be used and replace or improve them.
Otherwise, it is impossible to present a design method that can be applied in a hardware development at the end of this thesis.
The research can be summarized in the following two research questions.
\begin{itemize}
\item Which techniques of the design method can be applied in the development of hardware?
\item Which adaptations are required to create a design method that is suitable for the development of hardware?
\end{itemize}


%\rro{Which techniques of the design method can be applied in the development of hardware?}
%\subsection{Which techniques of the design method can be applied in the development of hardware?}
% The starting point of this research is the design method by \autocite{broenink_rapid_2019}.
% Their design method consists of multiple techniques, in the form of different cycles and steps.
% Each of these techniques will be analysed to determine if they are applicable for the physical component of the design.
% %For any technique that is not applicable, we w
%\subsection{Which adaptations are required to create a design method that is suitable for the development of hardware?}
% Techniques that are not applicable have to be improved or replaced.
%\rro{Which adaptations are required to create a design method that is suitable for the development of hardware?}
\section{Approach}
\rro{Adapt the design method for hardware development}
\rroi{Current design method gives an initial foundation for development}
\rroi{However, lacks detail in some parts}
\rroi{System Engineering will fill in the blanks}
The first step is to create a concrete design method.
The design method by \autocite{broenink_rapid_2019} is in an abstract form.
It often leaves room for interpretation about how certain steps should be performed.
However, this does not help the evaluation of the test method.
If a step is not written down, it is difficult to point out flaws during the evaluation.

\chapter{Analysis}
\section{Design Methods}
\subsection{Rapid development}
\rro{Explain the design method of \textcite{broenink_variable_2018} and \textcite{broenink_rapid_2019}}
\subsection{Systems Engineering}
\rro{Explain the general idea of systems engineering}
By performing a case study where a physical system will be developed, the design method can be evaluated.
However, the type of physical system strongly influences the success of the evaluation.
On the basis of testing requirements, it was decided to develop a Whiteboard Writer.
Implementing this system ensures sufficient complexity but still fits in the scope of this thesis.

\section{Testing}
\subsection{Automatic Method Testing}
\section{CAD tools}
\subsection{20-sim}
\rro{20-sim will be used for the portbased modeling of the dynamics}
\rroi{Gives the posibility to simulate what I want}
\rroi{And i'm very familiar with it}
\subsection{openSCAD}
\rro{3D drawing software}

\section{Case Studies}
\rro{This section will be taken from the project plan}
\subsection{Coverage}
\subsection{Tweet on a Whiteboard}
\subsection{Sensor Calibration Rig}
\subsection{Peg-in-Hole Robot}
\subsection{Decision}

%\chapter{Design Method}
\rro{This chapter is the project plan with feedback}
The next step is to perform the case study.
Setting up evaluations forms ensures consistent feedback for each step in the case study.
During the case study all the design method steps are performed one by one.
Although the development of the Whiteboard writer was not completed.
The result of the case study is a physical prototype of a subsystem and a substantial amount of feedback.
Based on the feedback from the case study, an improved design method is proposed.




\rro{Define a case study to test the design method}
\rroi{To actually test the method we have to design something}
\rroi{From multiple options we chose the whiteboard writer}
\rroii{Complex enough}
\rroii{Fits within the scope}
\rro{Perform the case study}
\rroi{The case study does not focus on the best product.}
\rroi{Some design decissions are made to aid the evaluation of the design method}
\rroi{Run continuous evaluation during the case study, to improve the design method}
\rro{Use feedback to propose design method for the development of hardware}

\section{Structure of this Thesis}
\autoref{chap:analysis}
\autoref{chap:systemdesign}
\autoref{chap:casestudy}
\autoref{chap:improvements}
\autoref{chap:discussion}
\autoref{chap:conclusion}

\include{content/analysis}
\include{content/designcycle}
\include{content/casestudy}

\chapter{Case Study: Whiteboard writer}
\section{Monitoring}
\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{Specifications}
\rro{Present Specifications for Case}
\subsubsection{Evaluation}
\rro{EARS is a good method}
\rro{Expected walk in the park}
\rro{Was difficult to validate}
\subsection{Initial Design}
\rro{Research on Existing Systems}
\rroi{Cable bot}
\rroii{Cable Tensioning, helps avoid oscillations}
\rroi{Cartesian-coordinate robot}
\rroi{SKARA}
\rroi{Polar-coordinate robot}
\rroi{Combination of the different systems}
\rro{Choice of system}
\rroi{Combine Cable bot with SCARA}
\rroii{Combination gives more dimensions of freedom to system}
\rroii{Otherwise it is expected that modeling is too easy}
\subsubsection{Evaluation}
\rro{Difficult to validate if the system is working}
\rro{Design stays very rough}
\rroi{Not sufficient detail to communicate to other engineers}
\rroi{Lack in experience.}
\rro{Tested: Discussed and reviewed with daily-supervisor}
\subsection{Feature Definition}
\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}
\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}
@@ -185,14 +208,18 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
\section{Result}
\rro{Created a model in 20-sim and openscad}
\rro{Build a physical prototype}

\chapter{Improvements}
\label{chap:improvements}
\section{Specifications}
\rro{For validation \textcite{garrett_322_2000} suggests:}
\rroi{Looking at comparable systems' specifications}
\rroi{Use of best engineering judgements}
\rroi{Apply early simulation results for feedback}
\rroi{A holistic view is required for validation of the initial design/specifications}
\rro{Without mechanical experience is difficult}
\rro{Better specification document is a team effort}
\rroi{A team with engineers in their own specific field that is included in the design}
\rro{\textcite{sheard_718_1998} discusses:}
\rroi{Mechanical requirements are directly derived from and bounded by physics}
\rro{Result: Mechanical specifications are easier to change}
@@ -202,7 +229,18 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
\rro{Result: Improvised a structure that was loosly based on Robmosys}
\rro{Proposed Improvement: Split layout for requirements, functions and components from State Analysis \textcite{kordon_model-based_2007}.}

\rro{Instead of trying to start with a feature, a holistic model of essential elements should be created}
\rroi{In the holistic basic model, review the features/components on their feasibility}
\rroii{How likely is it that this specific component is going to work: And if not, what are the consequences? What do we need to change?}
\rroi{Then add detail to the different subcomponents of that model}

\section{Tooling}
\rro{20-sim lacks an object oriented approach}
\rroi{Adding detail to a submodel that is used more than once is a PITA}
\rroi{Every model is a deepcopy}

\chapter{Discussion}
\label{chap:discussion}
\section{Complexity}
\rro{\textcite{sheard_718_1998} discusses:}
\rroi{Mechanical solutions are inherent simpler than software solution}
@@ -232,6 +270,9 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
\rroi{During prototyping/development it probably cheaper to make a change to the hardware}
\rroi{From the point of production, software becomes cheaper to change than hardware}

\rro{Humans design and build hardware, humans design software but a machine builds it.}
\rroi{Therefore, any flaws that come to light during hardware build is spotted way easier.}

\section{Features vs Subsystems}
\rro{Original method is based on features and implementing them one by one}
\rroi{Software can implement a single feature, where the output can be tested}
@@ -244,6 +285,7 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
\rroi{Implementing them earlier does not contribute to the cost of switching design.}

\chapter{Conclusion}
\label{chap:conclusion}

\printbibliography
\end{document}

Escribir Vista previa
Cargando…
Cancelar
Guardar