diff --git a/content/casestudy.tex b/content/casestudy.tex index 3610fdc..160b34b 100644 --- a/content/casestudy.tex +++ b/content/casestudy.tex @@ -19,6 +19,7 @@ \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. + \rrot{Add the additional questions} \begin{table*} \caption{Table with questions to evaluate the steps. With corresponding questions ordered in pre and post step columns.} @@ -111,32 +112,209 @@ \begin{itemize} \item The system shall write a twitter message on the board. \end{itemize} - + + \subsubsection{Evaluation} + The problem definition within this case study does not represent a conventional design process. + Therefore, the problem definition was not evaluated in this case study. \subsection{Specifications} - \rro{Present Specifications for Case} + \label{sec:specifications} + %\rro{Present Specifications for Case} + During this step the goal is to setup a document with concrete specifications of the system. + This resulted in a document that had a short description and a list of specifications. + The description described in short the general operating procedure. + As the writer has to write and update a tweet on the whiteboard, it must be able to write and wipe the board. + Furthermore, it should be able to draw 140 characters of readable text on the board. + For readability, the result has to be readable from 4 meters distance. + + The specifications itself are written with \ac{ears} and are as follows: + \begin{itemize} + \item The Writer shall be able to write at least 50 characters per line. + \item The Writer shall be able to write at least 5 lines of text. + \item The Writer shall display the author, time, content, and number of retweets, favorites and replies in plain-text. + \item The Writer shall plot characters with a size that is readable from 4 meters for a person with good eyesight. + \item The Writer shall plot in a regular used font with corresponding character spacing. + \item When a new tweet is send to the Writer, the Writer, shall wipe the existing tweet and write down a new tweet. + \item If the Writer is not wiping or writing then the Writer shall not obstruct the view of the whiteboard. + \item While writing, the Writer shall have a writing speed of at least 1 character per second. + \item If the Writer is tasked to wipe the tweet, the Writer shall wipe the tweet within 60 seconds + \item When a reset-signal is send to the Writer, the Writer shall recalibrate its position on the board. + \item When a wipe-signal is send to the Writer, the Writer shall wipe the board clean. + \item The Writer shall not damage itself. + \end{itemize} + + Additionally there are some restrictions on construction. + The tooling in limited to some hobby/DIY tools. + As the rapid prototyping facilities at the university are closed due to the Covid-19 pandemic. + \begin{itemize} + \item The Writer shall not exceed a total cost in materials and/or tools of €200. + \item The Writer shall be constructed with simple tools in the following list: + \begin{itemize} + \item Screwdrivers (Hex/Inbus, Torx, Philips, etc) in a, although limited, wide variation of size. + \item Drill + \item Screwtap set + \item Jigsaw + \item Wrenches + \item Soldering iron + \item Various Pliers + \item PLA 3D printer + \end{itemize} + \end{itemize} \subsubsection{Evaluation} - \rro{EARS is a good method} - \rro{Expected walk in the park} - \rro{Was difficult to validate} + While performing this step it became clear that big improvements can be made. + The focus of this case is at the actual hardware implementation. + This caused the steps in the preliminary design to be overlooked. + The lack of a good problem description and not having an experienced design team makes the specifications even more difficult. + An extensive specification document would benefit the design process. + However, it would also be very time consuming and would not fit in the time frame of this thesis. + A conclusion similar to the evaluation of the problem description is that this unique case study is not a good basis for defining specifications. + + Some concrete points from this step are: + \begin{itemize} + \item \ac{ears} is very useful during for the specifications. + \item Being thorough and complete is difficult without a team. + \item Difficult to avoid ambiguity. + \item Difficult to validate the specifications. + \end{itemize} + + The latter point was reason to add additional questions to the evaluation form: + \begin{itemize} + \item What is the method of testing? + \item How did you test/validate the step? + \end{itemize} + \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} + The initial design started with a design space exploration. + The goal was to collect possible solutions and ideas for the implementation. + The exploration resulted in a lot of whiteboard writing robots. + These robots can be sorted in four different configurations + Each configuration is worked out and will be discussed here. + + \subsubsection{Cable Driven} + The cable driven robot is suspended with multiple cables. + The end-effector that contains the markers is moved along a board by changing the length of the cables. + The cable based positioning systems result in a end-effector with large range and high velocities. + A possible setup can be seen in \autoref{fig:cablebotdrawing} + \begin{figure} + \centering + \includegraphics[width=0.9\linewidth]{graphics/8564503-fig-1-source-large.png} + \caption{Planar view of cable driven robot. \autocite{aguas_sliding_2018}} + \label{fig:cablebotdrawing} + \end{figure} + Each of the cables can be motorized. + Unfortunately, this does make the system over-constrained. + However, it is possible to only motorize two of the four cables and pretension the other two. + This makes the system exactly constrained. + Furthermore, the lower cables could be completely left out of the design. + This makes the design even simpler but the pretensions could help dampening the system. + + \subsubsection{Cartesian-coordinate robot} + This configuration is a very common design for plotters. + This setup is also known as a gantry robot or linear robot. + It normally consists of two sliders, which behave as a prismatic joint. + Because each slider covers a single X or Y axis, the control and dynamics of this system are very simple. + For the dimensions the length of the sliders define the limits. + + \subsubsection{Polar-coordinate robot} + This robot is a combination of a prismatic and a revolute joint. + Where the rotational joint can rotate the prismatic joint. + With this it can reach any point within a radius from rotational joint. + This is a little more complex design than the Cartesian robot. + + This robot has some disadvantages. + The range of the robot is defined by the length of the prismatic joint. + However, if the prismatic joint is fully retracted, the joint does not get shorter. + In that case the arm still protrudes on the other side. + Therefore the complete radius around the revolute joint cannot have any obstacles. + This makes required space of the setup very inefficient. + Another disadvantage is that a long arm increases the moment of inertia and the gravitational torque quadratic. + Moreover, the longer arm also introduces stiffness problems. + + \subsubsection{SCARA} + The SCARA robot is a configuration with two linkages that are via with rotational joints. + It can be compared to a human arm drawing on a table. + Similar to the Polar robot it can reach all points within a radius from the base of the robot. + However, the arm only protrudes half the radius. + Furthermore, depending on the configuration the of the arm the area where it protrudes can be significantly smaller. + However, the additional joint and extra arm length does add to the moment of inertia and gravitational torque similar to the polar robot. + The SCARA robot is therefore not a robot that is convenient with large working areas. + However, it can be really quick and precise in relative small areas. + + \subsubsection{Choice of system} + Similar to the previous steps. + The type of design has to aid the evaluation of this design method. + Where normally it would be beneficial to keep a design simple. + This implementation has to be complex enough. + + Based on the complexity the cartesian and polar coordinate robots are excluded. + Especially at higher speeds the SCARA becomes dynamically interesting due to the torque of both joints. + However, it is unlikely that the SCARA provides enough features to implement multiple features. + It was therefore decided to combine a small SCARA with a cable driven robot. + Where the SCARA can write a couple of characters at high speed from a fixed position. + The cables can than move the complete SCARA to the next position. + + The combined system introduces sufficient complexity for the design method. + The cable robot and SCARA are both sub-systems of the complete writing robot that can be implemented separately. + \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} + The initial design step felt like an actual start of the design process. + Looking at multiple solutions resulted in new insight of the systems. + However, this knowledge would have more useful when defining the specifications in \autoref{sec:specifications}. + Furthermore, the specifications were written with the whiteboard writer in mind. + This step was used to select the robot that would evaluate the design method. + Similar to the previous step it became more evident that the complete preliminary design phase was not adequate. + + Validation of the decision was also lacking. + The combining both systems was discussed as the best option. + However, a simple model of the different proposed systems is needed to verify that decision. + And again, there was a lack of an experience to make a good trade-off. + \subsection{Feature Definition} + At this point there are specifications and an initial design for the system. + In the following steps of the design method features will be implemented one by one. + The goal of this step is then to define these features. + During this step it became clear that this approach was not feasible. + Prior to this step the expectation was that this step would produce three features that could be implemented. + These three features were the SCARA, the cable suspended carriage, and the end-effector. + However, independent of the interpretation of this step, the result was not the three expected features. + + Why were those three features expected in the first place? + During the previous steps a useful evaluation was to anticipate for the subsequent steps. + Where one of the following steps is to implement an individual feature. + Therefore, it must be possible to implement the feature. + Separating the initial design into the smallest components that could still be implemented, resulted in the SCARA, carriage and end-effector. + + The problem is that these three components do not describe the complete system. + Some functions of the system (feature) is performed by a combination of the components. + Therefore can the components in the system not be seen as features of the system. + Defining the components as features of the system is not a solution. + The relations between the components and features is still required. + + %As the features describe the behavior of the components, it is not a solution to replace the features with components. + + A solution to organize the relations between features and components was found in RobMoSys\footnote{\url{https://robmosys.eu/approach/}}. + RobMoSys defines a separation of levels in a design. + Where the levels start functional and moves via software to hardware implementation. + Although not all levels of RobMoSys are used, it was very useful to define the features of the system. + The definition can be seen in \autoref{fig:robmosys} + The current definition of features allows to start the implementation with a component. + When the component is finished features can be implemented by following the tree upwards. + \begin{figure*} + \centering + \includegraphics[width=0.8\linewidth]{graphics/robmosys} + \caption{Feature Definition based on the separation of levels introduced by RobMoSys} + \label{fig:robmosys} + \end{figure*} + + + + + %In the design method by \textcite{broenink_rapid_2019} the features describe software components. + %Theoretically, each function in software can be implemented and tested individually. + %However, in a dynamic system, a single component + %The SCARA, carriage and end-effector were selected as the smallest + %Although. + \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} @@ -156,6 +334,13 @@ \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} + Even though, there is a feature definition that can be used in the next step, there remain a couple of difficulties. + There is still a really strong border between features and components. + And the single level of components makes it impossible to depict the dependencies between components. + Developing larger and complexer systems will have sub-components in the system, introducing even more dependencies. + Therefore, this is not a valid solution for feature definition. + Fortunately the current solution suffices to continue the case study. + \subsection{System Test Specification} \rro{Specify tests for the different specifications} \rro{Made a document with tests} @@ -168,3 +353,50 @@ \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} diff --git a/graphics/8564503-fig-1-source-large.png b/graphics/8564503-fig-1-source-large.png new file mode 100644 index 0000000..87f20dd Binary files /dev/null and b/graphics/8564503-fig-1-source-large.png differ diff --git a/graphics/robmosys.tex b/graphics/robmosys.tex new file mode 100644 index 0000000..efda004 --- /dev/null +++ b/graphics/robmosys.tex @@ -0,0 +1,38 @@ +\documentclass{standalone} +\usepackage{tikz} +\usetikzlibrary {arrows.meta,graphs,graphdrawing} \usegdlibrary {layered} + +\begin{document} + +\begin{tikzpicture}[nodes={text height=.7em, text width=1.8cm, align=center, +draw=black!20, thick, fill=white, font=\footnotesize}, +>={Stealth[round,sep]}, rounded corners, semithick] + +\graph [layered layout, level distance=1.5cm, sibling sep=.5em, sibling distance=1.5cm, sweep crossing minimization] { + "Mission" -> "Task" -> "Skill" -> "Function" -> "Component"; + + "Draw a tweet on a board" -> "Writing"; + "Writing" -> { "Write a char at position", "Hold Marker", "Move to position" }; + "Write a char at position" -> { "Move marker on board", "Lift Marker" }; + "Hold Marker" -> "Switch Tools"; + "Move marker on board" -> "SCARA"; + "Lift Marker" -> "End-effector"; + + "Draw a tweet on a board" -> "Wiping"; + "Wiping" -> { "Wipe Area", "Hold Wiper", "Move to position" }; + "Hold Wiper" -> "Switch Tools"; + "Move Wiper on Board" -> SCARA; + "Wipe Area" -> "Move Wiper on Board"; + + "Move to position" -> "Move carriage" -> "Cable driven Carriage"; + "Switch Tools" -> {"End-effector", "SCARA"}; +}; + + % \graph [layered layout] { + % 1 -> 2 -> 3 -> 4; + % }; + + + +\end{tikzpicture} +\end{document} diff --git a/report.tex b/report.tex index 72a08f1..3187cd9 100644 --- a/report.tex +++ b/report.tex @@ -161,57 +161,14 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a \include{content/designcycle} \include{content/casestudy} - \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} \label{chap:improvements} \section{Specifications} + \rro{In general, I underestimated the importance of the preliminary research} + \rroi{\textcite{broenink_rapid_2019} also skips this part.} + \rroi{As the focus of that paper was on the actual implementation, the preliminary phase was over looked} + \rroii{However, bringing a system into being, the preliminary design phase is extremely important} \rro{For validation \textcite{garrett_322_2000} suggests:} \rroi{Looking at comparable systems' specifications} \rroi{Use of best engineering judgements}