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