master-thesis
/
mar
1
0
Vork 0
Code Kwesties 0 Pull-aanvragen 0 Publicaties 16 Wiki Activiteit
Bladeren bron

Add feedback Tim

tags/0.4.1-experiment
Wouter Horlings 5 jaren geleden
bovenliggende
d5a1e98160
commit
3c54b580f4
6 gewijzigde bestanden met toevoegingen van 81 en 62 verwijderingen
Zij-aan-zij weergave
Diff Options
Show Stats Download Patch File Download Diff File
  1. +3
    -2
      content/case_experiment.tex
  2. +37
    -26
      content/case_experiment_initial_design.tex
  3. +4
    -1
      content/case_experiment_problem_description.tex
  4. +35
    -27
      content/case_experiment_specifications.tex
  5. +1
    -5
      graphics/robmosys.tex
  6. +1
    -1
      include

+ 3
- 2
content/case_experiment.tex Bestand weergeven

@@ -4,9 +4,9 @@
This chapter presents the execution of the case study.
Where the goal of the case study is to evaluate the design plan as presented in \autoref{chap:analysis}.
To achieve this goal, I develop a system according to the design plan and document this design process.
The system to be designed is chosen previously in \autoref{sec:sod}.
As described in \autoref{sec:sod}, the system to be designed is a "Tweet on a Whiteboard Writer".
Documenting the process is done by following the evaluation protocol as described in \autoref{sec:evaluation_protocol}.
To start the case study unbiased, during the preparation I did perform as little preliminary research as possible on the design options of the "Tweet on a Whiteboard system".
To start the case study unbiased, during the preparation I did perform as little preliminary research as possible on the design options of the whiteboard writer.

The chapter begins with the section about the preparation phase, which contains the four corresponding design steps as shown in \autoref{fig:design_plan_analysis}.
This is followed by two completed development cycles in the later two sections.
@@ -31,6 +31,7 @@ Splitting the initial design into features is done in the feature definition ste
%\input{content/case_experiment_recap.tex}

\section{First Development Cycle}
\input{content/case_experiment_end-effector.tex}
\subsection{Feature Selection}
\subsection{Rapid Development}
\subsection{Variable Approach}


+ 37
- 26
content/case_experiment_initial_design.tex Bestand weergeven

@@ -14,7 +14,7 @@
The cable-based positioning systems result in a end-effector with a large range and high velocities.
A basic setup can be seen in \autoref{fig:cablebotdrawing}.
This given setup contains two cables that are motorized.
The big advantage of this system is that it scales good, as the cables can have almost any length.
The big advantage of this system is that it scales well, as the cables can have almost any length.
\begin{figure}
\centering
\includegraphics[width=10.8cm]{graphics/cablebot.pdf}
@@ -25,7 +25,7 @@
\begin{marginfigure}
\centering
\includegraphics[width=3.74cm]{graphics/cable_angle.pdf}
\caption{Illustrating the limit for horizontal acceleration $a$, for different angles to compensate for gravitational acceleration $g$.
\caption{Illustrating the limit for pure horizontal acceleration $a$, for different angles to compensate for gravitational acceleration $g$.
The red arrow represents the acceleration as a result of the pulling force of the cable, which is vectorized in a vertical acceleration that compensates $g$ and a vertical acceleration $a$.}
\label{fig:cable_angle}
\end{marginfigure}
@@ -33,8 +33,8 @@
Although it is possible to achieve high velocities, this system is limited by the gravitational acceleration.
In case of vertical acceleration, the maximum downward acceleration or upward deceleration is limited by \SI{9.81}{\meter\per\second\squared}.
The horizontal acceleration depends on the relative angle of the suspending cable.
The closer the end-effector is below the cable pulley, the lower the vertical acceleration becomes.
\autoref{fig:cable_angle} illustrates the vertical acceleration for different angles.
The closer the end-effector is below the cable pulley, the lower the pure horizontal acceleration becomes.
\autoref{fig:cable_angle} illustrates the horizontal acceleration for different angles.
A possible solution to this is to add one or two additional wires to the system.
These can pull on the system to 'assist' the gravitational force.
@@ -48,8 +48,8 @@
Because each slider covers a single X or Y axis, the control and dynamics of this system are rather simple.
The biggest challenge is in the construction of the system, especially when the size of the system is increased.
The larger system requires bigger length sliders, which are expensive.
Another difficulty is the actuation of both horizontal sliders, if these sliders do not operate synchronous, the vertical slider will rotate.
However, this is slider is not allowed to rotate, thus probably breaking the system.
Another difficulty is the actuation of both horizontal sliders, if these sliders do not operate synchronous, the vertical slider rotates.
However, the construction of the slider is not able to rotate, resulting in damage to the system.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/plotter.pdf}
@@ -106,14 +106,21 @@
\subsubsection{Choice of system}
The previous sections have shown four different configurations.
These configurations are compared in \autoref{tab:initial_design}.
Each of the systems are scored on range, dimension, speed, scaling and the interesting dynamics.
Each of the systems are scored on range, speed, cost, obstruction, effective area, and the interesting dynamics.
The range scores the system on the practical dimension of the system, larger is better.
The cable and cartesian configuration scale very well, the cables or slider rails can be made longer without real difficulty.
The SCARA or polar configuration run into problems with the arm lengths, as forces scale quadratically with their length.
The dimension looks at the number of states that require control and is for all systems defined as 2.5D.
The half dimension is the binary state for the marker on or off the board.
Except for the cable bot, all configurations score sufficient on speed.
The cable bot can be quick, but is limited in acceleration, and depends on the type of cable configuration.
For the cost, all systems fit within the €200 budget, except for the Cartesian setup.
All systems require some DC or stepper motors, but the cartesian setup also requires linear sliders which are expensive for longer distances.
The obstruction score depends on the capability of the system to move away from the text on the board, such that the system does not obstruct the written tweet.
For the scalability, only the cable bot scores high.
The cables make it possible to easily change the operating range of the system, only requiring reconfiguration.
The cartesian system scales poor because the length of the sliders is fixed, and longer sliders are expensive.
For the Polar system and SCARA, the forces on the joints scale quadratically with the length of the arms.
However, the SCARA can be build with counter balance making it scale less worse than the Polar system.
With the effective area, the system is scored on the area it requires to operated versus the writable area.
The last one, how interesting or challenging are the dynamics.
The cartesian configuration is trivial, both sliders operate completely separate from each other and the position coordinates can be mapped one to one with the sliders.
For the other configuration, some inverse kinematics are required to get from desired position to the control angles of the system.
@@ -125,20 +132,23 @@
\cline{2-6}
& Cable bot & Cartesian & Polar & SCARA & Combined \\ \hline
\multicolumn{1}{|l|}{Range} & + + & + & - - & - & + + \\ \hline
\multicolumn{1}{|l|}{Dimension} & 2.5 & 2.5 & 2.5 & 2.5 & 4.5 \\ \hline
\multicolumn{1}{|l|}{Speed} & - & + & + & + + & + \\ \hline
\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Interesting\\ dynamics\end{tabular}} & + & - - & + & + & + + \\ \hline
\multicolumn{1}{|l|}{Cost} & + + & - - & + & + & + \\ \hline
\multicolumn{1}{|l|}{Obstruction} & - & + & + & + & - \\ \hline
\multicolumn{1}{|l|}{Scalability} & + + & - & - - & - & + \\ \hline
\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Effective\\ area\end{tabular}} & + + & + & - - & + & + + \\ \hline
\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Interesting\\ dynamics\end{tabular}} & - & - - & - & + & + + \\ \hline
\end{tabular}
\end{table}
Based on the dimension, all configurations fail to meet the required four state minimum.
By combining two configurations, it is possible to meet the minimum of four states.
To get the best system, I decided to combine a 'speed' and a 'range' configuration.
This results in a system that has both properties.
Combining anything with the cartesian configurations, creates just a moving base for the other configurations.
Together with the trivial dynamics, this option is discarded.
Suspending the SCARA of the polar configuration with cables creates very interesting dynamics, as moving the end-effector also influences the cables.
From both options, the SCARA is quicker and scales better with range than the polar.
Therefore, the SCARA is chosen above the polar configuration to be combined with the cable bot.
Based on this comparison, I decided to disqualify the cartesian and polar system.
The cartesian has no interesting dynamics and is expensive to build at a large enough scale.
The polar system is just not feasible, the arm length required to cover the writing area results forces that are too large.
Making the joint that can deliver the torque for that arm and also providing enough speed is just out of the scope of this case study.
The two remaining configurations also contain some downsides. The cable bot is slow, and the arm length for the SCARA is also likely to cause problems.
Therefore, I decided to combine both systems: a cable bot system that moves a small SCARA along the whiteboard.
The small SCARA is quick while the cable bot gives the system an enormous range.
Resulting in a system that scores high on all criteria except obstruction.
The grading for the combined system is shown in the most right column in \autoref{tab:initial_design}.

\begin{figure}
@@ -157,9 +167,10 @@
In hind sight, it would have been useful to have this information during the specifications step.
However, as the specifications step are mainly on the "what" to solve, and specifically not on "how" to solve it, this information was avoided on purpose during the specifications step.

This step did result in a initial design that can be used in the next steps.
However, I noticed that none of the previous steps gave some implementation threshold.
For the problem description and the specifications steps this was a minimum implementation level.
This step was a optimal implementation level, the minimum was reached rather quick.
But at what level of implementation needs this step to be concluded?
A related question: Would a simple dynamic model of the initial design be a useful insight or a waste of time?
This step did result in an initial design that can be used in the next steps.
However, I noticed that none of the previous steps have a clear start or end.
For the problem description and the specification steps the question is when all required information is collected.
In the initial design it is always possible continue researching design options to come up with an even better design.
Especially with complex system, it is unrealistic to create complete specifications before making design decissions.
Resulting in the question: at what point do we have enough information and must we move to the next design step?
This is also known as the \emph{requirement versus design paradox} \autocite{fitzgerald_collaborative_2014}.

+ 4
- 1
content/case_experiment_problem_description.tex Bestand weergeven

@@ -1,6 +1,9 @@
%&tex
\subsection{Problem Description}
In the problem description the need for a system can be described as follows:
The problem description describes the need for a solution or system.
In this case, I want a robot that can write a tweet on a whiteboard.
A specific requirement is that the system must be complex enough, such that it uses sufficient aspects of the design method to be able to evaluate that design method.
The system must meet the following requirements:
\begin{itemize}
\item Write a twitter message, or tweet, on a whiteboard.
\item Remove the tweet from the whiteboard.


+ 35
- 27
content/case_experiment_specifications.tex Bestand weergeven

@@ -3,18 +3,19 @@
\label{sec:specifications}
The next step is to create specifications based on the problem description.
The goal is to write and remove a tweet on the whiteboard.
Originally a tweet had a character limit of 140, but this was doubled to 280\footnote{\url{https://blog.twitter.com/official/en_us/topics/product/2017/tweetingmadeeasier.html}}.
Originally a tweet had a character limit of 140, but this was doubled to 280\autocite{rosen_tweeting_2017}.
However, for this system the limit remains at 140 characters.
The text is limited to fifty characters per line, with a total of three lines.
This results in ten extra characters that can be used for word wrapping.
For the readability, the distance to a whiteboard in a meeting room is taken as \SI{4}{\meter}.
The operating speed should allow the tweet to be written within three minutes.
Therefore, the goal is to write one character per second.
The last requirement is to have interesting dynamics.
Looking at simple plotters, they are referred to as 2.5D as the 'third' dimension only describes a binary state.
For this system, the minimum is set to a system that has at least four full states that have to be controlled.
The last requirement is that the dynamics of the system must be sophisticated.
Meaning that a solution with complex or non-trivial behavior is preferred.
Using \ac{ears} to define these specifications gives:
\begin{enumerate}
\begin{specification}
\begin{enumerate}
\setlength{\itemsep}{10pt}
\item The Writer shall be able to write at least fifty characters per line.
\item The Writer shall be able to write at least three of text.
\item The Writer shall plot characters with a size that is readable from 4 meters for a person with good eyesight.
@@ -22,33 +23,40 @@
\item When a new tweet is send to the Writer, the Writer, shall wipe the existing tweet and write down the 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 one character per second.
\item The Writer shall contain at least four states that require control in order to function.
\item The dynamics of the Writer shall be complex/sophisticated/interesting.
\end{enumerate}
\end{specification}
Some other specifications that are related to the operation of the system are:
\begin{enumerate}
\setcounter{enumi}{8}
\item If the Writer is tasked to wipe the tweet, the Writer shall wipe the tweet within sixty 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{enumerate}
\begin{specification}
\begin{enumerate}
\setcounter{enumi}{8}
\setlength{\itemsep}{10pt}
\item If the Writer is tasked to wipe the tweet, the Writer shall wipe the tweet within sixty 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{enumerate}
\end{specification}

Additionally there are some restrictions on construction.
As the rapid prototyping facilities at the university are closed due to the Covid-19 pandemic, the available tooling in reduced to some hobby/DIY tools:
\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 different sizes.
\item Drill
\item Screwtaps
\item Jigsaw
\item Wrenches
\item Soldering iron
\item Various Pliers
\item PLA 3D printer
\end{itemize}
\end{itemize}
\begin{specification}
\begin{itemize}
\setlength{\itemsep}{10pt}
\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)
\item Drill
\item Screwtaps
\item Jigsaw
\item Wrenches
\item Soldering iron
\item Various Pliers
\item PLA 3D printer
\end{itemize}
\end{itemize}
\end{specification}
\subsubsection{Evaluation}
The specifications step was performed without problems.
Defining the specifications for the problem description did not present any difficulty.


+ 1
- 5
graphics/robmosys.tex Bestand weergeven

@@ -55,10 +55,6 @@ draw=black!20, thick, fill=white, font=\footnotesize},
(K) edge (N)
(K) edge (O)
(L) edge (O)
(M) edge (P)
(d) edge (e);



(M) edge (P);
\end{tikzpicture}
\end{document}

+ 1
- 1
include

@@ -1 +1 @@
Subproject commit 00f6dba02622fda48d1b9921714f53669ab66ffc
Subproject commit c009dc2baa96d33c3c2e89bc156a691f439fdc12

Schrijf Voorbeeld
Laden…
Annuleren
Opslaan