mar/report.tex

\documentclass[english,titlepage,nomath]{siltex-report}
\include{include/preamble}

\title{Title}
\subtitle{Thesis Report}
\course{}
\faculty{\large Electrical Engineering, Mathematics and Computer Science}
\supervisor{%
	Dr. ir. J.F. Broenink \\
	Ir. T.G. Broenink
}
\author{%
    Wouter Horlings
}

\begin{document}
\maketitle
\makerro
\chapter{Samenvatting}
Dit is nu een eerste opzet van de structuur van mijn verslag.
De eerste hoofdstukken komen goed overeen met mijn orinele projectplan.
Dan is er een hoofdstuk over de casestudy zelf.
Daarin ben ik tegen best wel veel dingen aangelopen.
Vooral omdat de methode toch direct was afgeleid van een meer softwarekant.
Al vrij snel kwam ik er achter dat een dynamisch model een interactie tussen powerports.
Waar software een duidelijke input en output heeft.
Het grote verschil komt hier dus ook een volgend "blokje" aan je output hangen wel gevolgen heeft voor je dynamische systeem en niet voor je software.

Features los van elkaar beschouwen is dus niet haalbaar in een dynamisch systeem.
Als je dit terugbrengt tot subsystemen dan kom je een heel eind verder.
Maar dan wordt het implementeren van een onderdeel gelijk een tijdverslindende stap.

In de stap zelf was het toevoegen van detail in kleine stukjes wel erg succesvol.
Maar dit komt ook in een aantal andere papers naar voren.

Ik heb een verzameling van dingen die beter kunnen in het process.
Maar het is nog wel interessant om te bespreken of een "hardware-only" systeem onwikkelen nog wel van deze tijd is.
Enige complexiteit is nu vaak uberhaupt mogelijk omdat er embedded software in kan.

Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een aantal punten kon aandragen waarom dit zo veel belangrijker is voor software dan hardware.

\tableofcontents
\include{include/acronyms}
\chapter{Introduction}
    \section{Context}
    \section{Problem Statement}
    \section{Research Objective}
    \section{Approach}

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

    \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}
    \include{content/designcycle}

\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}
                \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}
\chapter{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}
        \rro{Without mechanical experience is difficult}
        \rro{Better specification document is a team effort}
        \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}
            \rroi{More room for initial simulations, before making concrete specs}
    \section{Feature Separation}
        \rro{During the case study, the planned approach was not possible}
        \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}.}

\chapter{Discussion}
    \section{Complexity}
        \rro{\textcite{sheard_718_1998} discusses:}
            \rroi{Mechanical solutions are inherent simpler than software solution}
            \rro{Huge difference in states}
            \rroi{Mechanical part of prototype has 3 states}
            \rroii{2 angles, 1 marker angle (given that is still operating correctly)}
            \rroii{Double it for each angular velocity: making it 6}
            \rroi{Each embedded part of the stepper drivers have more than 30 states}
            \rroii{With two drivers it gives it easily 10 times more states already}
            \rroi{Software itself has more than 40 states}

            \rro{Mechanical states are linked}
            \rroi{Software engineer has to implement and link the states}

            \rro{Mechanical states/behavior is always limited by the law of physics.}
            \rroi{We cannot make mechanics al large as we want}
            \rro{Software has almost no scaling limitations}
            \rroi{Can have gigantious amounts of states}
            \rroi{States can be changed separately}
            \rroi{Only limitations are always the computing power}
            \rroi{Real-time limitations are occuring when we want to keep up with physics}
            \rro{Mechanics that reach the same complexity as software where this design method would be usefull is something that never fits in a Thesis.}
            \rroi{Probably only on industrial scale}

            \rro{The "soft" in software is based on that it can be changed, improved, tweaked.}
            \rroi{This does not mean that it is cheap or easy}
            \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}

    \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}
            \rroi{A single hardware feature cannot be tested as connecting another feature changes the output}
            \rroii{Difference between a power-connection and a singal-port}
            \rroi{Smallest division in hardware is a subsystem}

    \section{Interesting concepts}
        \rro{Some features are required for multiple design options}
        \rroi{Implementing them earlier does not contribute to the cost of switching design.}

\chapter{Conclusion}

\printbibliography
\end{document}