master-thesis
/
mar
1
0
Fork 0
Code Issues 0 Pull Requests 0 Releases 16 Wiki Activity
Browse Source

Split chapter in multiple files

tags/0.4.3-reflection
Wouter Horlings 5 years ago
parent
629cd8ad77
commit
1bbe08bbb4
7 changed files with 472 additions and 465 deletions
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. +6
    -465
      content/case_experiment.tex
  2. +46
    -0
      content/case_experiment_feature_definition.tex
  3. +163
    -0
      content/case_experiment_initial_design.tex
  4. +19
    -0
      content/case_experiment_problem_description.tex
  5. +96
    -0
      content/case_experiment_recap.tex
  6. +60
    -0
      content/case_experiment_specifications.tex
  7. +82
    -0
      content/case_experiment_test_protocol.tex

+ 6
- 465
content/case_experiment.tex View File

@@ -23,471 +23,12 @@ This description is detailed into a list of specifications.
Based on the specifications, a number of design solutions proposed and eventually one of these solutions is chosen as initial design. Based on the specifications, a number of design solutions proposed and eventually one of these solutions is chosen as initial design.
Splitting the initial design into features is done in the feature definition step. Splitting the initial design into features is done in the feature definition step.


\subsection{Problem Description}
In the problem description the need for a system can be described as follows:
\begin{itemize}
\item Write a twitter message, or tweet, on a whiteboard.
\item Remove the tweet from the whiteboard.
\item Write the tweet within three minutes on the board.
\item The text must be readable across a meeting room.
\item The solution must contain interesting dynamics.
\end{itemize}

\subsubsection{Evaluation}
The problem description is very brief, which is not a complete surprise.
As most of the work for the problem description was already done by choosing the subject of design.
However, it was not expected to be this minimal.
Perhaps the most serious disadvantage is the absence of stakeholders.
Normally, a good problem definition focusses on getting the stakeholders on the same line \autocite{shafaat_exploring_2015}.
However, this case study does only have one stakeholder, the author, defeating the purpose getting everyone on the same line.
Creating a more elaborate problem description would not improve the following design process, but it does cost valuable time.

\subsection{Specifications}
\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}}.
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.
Using \ac{ears} to define these specifications gives:
\begin{enumerate}
\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.
\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 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.
\end{enumerate}
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}

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}
\subsubsection{Evaluation}
The specifications step was performed without problems.
Defining the specifications for the problem description did not present any difficulty.
Due to the simplicity of the problem description, there were no contradictory requirements, which would complicate the specifications.
Furthermore, a single stakeholder takes away any negotiation the stakeholders.

Although the specifications itself are not difficult to define, ensuring that they are complete is difficult.
Team members and stakeholders help to spot any ambiguity or problems with the validity.
\ac{ears} was very useful in this case as it gives a strong template to help avoid ambiguity.

\subsection{Initial design}
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 explained in the following sections.
From the possible configurations, the optimal configuration that fits the specifications is made into an initial design.
\subsubsection{Cable-Driven}
The cable-driven robot is suspended with multiple cables.
The end-effector that contains the marker is moved along a board by changing the length of the cables.
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.
\begin{figure}
\centering
\includegraphics[width=10.8cm]{graphics/cablebot.pdf}
\caption{Planar view of cable driven robot. This setup contains two motorized pulleys in both top corners. From these two cables a mass is suspended at position $x,y$.
By changing the length of the cables, the mass can be moved over along the whole board.}
\label{fig:cablebotdrawing}
\end{figure}
\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$.
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}

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.
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.
Depending on the implementation, the extra cables make the system over-constrained.
Nevertheless, the extra cables allow for higher acceleration limits in vertical and horizontal direction.

\subsubsection{Cartesian-coordinate robot}
This configuration is a very common design for plotters and shown in \autoref{fig:plotter}.
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 rather simple.
A bigger challenge is the construction of the system, as the vertical slider has to stay vertical during operation.
Especially the length of this setup makes twisting of the vertical slider more likely.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/plotter.pdf}
\caption{This Cartesian plotter consists of two horizontal sliders to provide the $x$-movement and one vertical slider to provide the $y$-movement.}
\label{fig:plotter}
\end{figure}

\subsubsection{Polar-coordinate robot}
This robot is a combination of a prismatic and a revolute joint.
Where the revolute joint can rotate the prismatic joint as seen in \autoref{fig:polar}.
With this it can reach any point within a radius from rotational joint.
This is a little more complex design than the Cartesian robot.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/polar.pdf}
\caption{A combination of a revolute joint and a prismatic joint, creating a polar-coordinate robot.}
\label{fig:polar}
\end{figure}
\begin{marginfigure}
\centering
\includegraphics[width=3.74cm]{graphics/polar_protrude.pdf}
\caption{The diagonal lined section shows the part of the protruding area that is used by the arm.}
\label{fig:polar_protrude}
\end{marginfigure}

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.
\autoref{fig:polar_protrude} gives an impression of the required area.
Even with this area, the arm cannot reach the complete board.
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 quadratically.
Furthermore, the long arm introduces stiffness problems and it amplifies any inaccuracy in the joint.
\subsubsection{SCARA}
The SCARA robot is a configuration with two linkages that are connected via rotational joints.
It can be compared to a human arm drawing on a table as seen in \autoref{fig:scara}.
Similar to the Polar robot it can reach all points within a radius from the base of the robot.
However, the arm can be configurated to not protrude outside of the board.
If the situation requires the arm to protrude, it is still significantly less than the polar arm (\autoref{fig:polar_protrude}).
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 is therefore not a robot that is convenient with large working areas.
However, it can be really quick and precise in relative small areas.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/scara.pdf}
\caption{Schematic example of a SCARA, consisting of two rotation linkages. This setup can be compared to a human arm, where the gray base above the whiteboard represents the shoulder and the connections between both linkages the elbow.}
\label{fig:scara}
\end{figure}

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

\begin{table}[]
\caption{Table with comparison of the four proposed configurations and a combined configuration of the cable bot and the SCARA.}
\label{tab:initial_design}
\begin{tabular}{l|l|l|l|l|l|}
\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
\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.
The grading for the combined system is shown in the most right column in \autoref{tab:initial_design}.

\begin{figure}
\centering
\includegraphics[width=10.8cm]{graphics/combined.pdf}
\caption{Combined system that integrates the cable bot together with the SCARA. The SCARA in red is mounted on the carriage in blue. This carriage is then suspended by cables.}
\label{fig:combined}
\end{figure}
In the combined system, the SCARA will only be large enough to write a small number of characters at the time.
This will alternate with the cable bot moving the base of the SCARA to the next position, so that it can write the next set of characters on the whiteboard.
\autoref{fig:combined} shows a simple view of the system.

\subsubsection{Evaluation}
This was the first step that felt really productive in the design process.
It created a enormous amount of information and insight of the design.
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?
\subsection{Feature Definition}
\label{sec:case_featuredefinition}
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.85\linewidth]{graphics/robmosys}
\caption{Feature Definition based on the separation of levels introduced by RobMoSys}
\label{fig:robmosys}
\end{figure*}

\subsubsection{Evaluation}
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 complex 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{Test Protocol}
The last step of the preliminary design is to design tests.
The tests are designed around the specifications.
However, during the creation of the tests it was found that the list of specifications were lacking.
Furthermore, the previous steps did not provide any order of operation.
During this step the order of operation and additional specifications are determined.

There are two modes of operation: writing and wiping.
The writing operation can be split in the following steps:
\begin{enumerate}
\item Move cable driven carriage to position of characters.
\item Write three characters with the SCARA.
\item Repeat step 1 and 2 till the Tweet is on the board.
\item Move carriage away from the text on the board.
\end{enumerate}

The other operation is wiping.
This is similar to the operation of writing with the following steps:
\begin{enumerate}
\item Move cable driven carriage to position of characters.
\item Clear the area in reach of the SCARA.
\item Repeat step 1 and 2 till the Tweet is removed from on the board.
\end{enumerate}
Furthermore, switching between the states requires the tool to be switched.
As this is a difficult operation there are not yet requirements or order of operation specified.

Based on the order of operation, the following specifications were added to the list in \autoref{sec:specifications}:
\begin{enumerate}
\setcounter{enumi}{11}
\item While writing, the SCARA shall have a writing speed of at least 1.5 characters per second.
\item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least 3 characters at that position.
\item When the SCARA finished writing at their current position, the Carriage shall move the SCARA to it's next position where it can write the subsequent characters.
\item When the SCARA has to be moved to a new position, the Carriage shall perform this movement within 1 second.
\end{enumerate}
These additional specifications are also based on the combined system decission that was made in section \autoref{sec:initialdesign}.
These specifications distribute responsibility between sub-components.

With the updated specifications it was possible to create a number of test cases.
In total there are five small test cases and four large test cases.
The small tests cover a sub-system and the large tests apply on the complete systems.
Each tests has a list of specifications that are covered with the test and for smaller tests the subsystem under test is also determined.
With a short description it is described how the test should be performed.

One of the small tests is performed by drawing a square:
\begin{test}
\begin{description}
\item[Coverage] SCARA
\item[Specifications] 3, 7, 11, 13
\item[Description]
The SCARA must draw a square of at least \SI{50}{\milli\meter} high and \SI{70}{\milli\meter} wide.
This box is large enough to draw at least 3 characters.
This square should be drawn within one second.
If it is slower than that, it is not able to achieve specification 7.
\end{description}
\end{test}
Repeatability is tested in one of the large system wide tests:
\begin{test}
\begin{description}
\item[Coverage] All features
\item[Specifications] 3, 4, 9, 11
\item[Description]
To test the repeatability of the system must do four things:
\begin{itemize}
\item The system will be reset.
\item Draw multiple squares (\SI{60}{\milli\meter} x \SI{60}{\milli\meter}) at a random position within the drawing range (\SI{1000}{\milli\meter} x \SI{300}{\milli\meter}).
\item The system will be reset again.
\item Then in a random order, at least different from the order of squares, a circle with a \SI{55}{\milli\meter} diameter must to be drawn inside the squares.
\end{itemize}
The test is successful if the circles are not drawn outside of the squares.
\end{description}
\end{test}

\subsubsection{Evaluation}
This step was completed with not many difficulties.
The specific order of operation and extra specifications should not be part of this step.
It was already concluded that the steps in the preliminary design were not as expected.
The fact that this step resulted in an additional changes only adds to that conclusion.

The design of the test cases resulted in valuable information about the system.
This information would be very useful in an earlier stage of the preliminary design.


\subsection{Recap}
During the problem definition and the specifications step it was difficult to stay within the "what" has to be solved and not go into the "how" it has to be solved.
Furthermore,
The test definitions of the last step conclude the preliminary design phase.
This preliminary design shows a clear notion of a hasty execution from a design standpoint.
The preliminary design was performed over a period of 5 weeks, by one developer with little experience in design documentation.
This makes notion of hasty not surprising for this unproven design method.
That does not mean that this preliminary design is a waste of time.
From the evaluation moments during the preliminary phase there are a couple of interesting points.
\begin{itemize}
\item The lack of a design team with experienced engineers would drastically improve the execution of this design phase.
Such a team is also able to find the smaller problems of such a design phase, which are currently completely overlooked.
\item It is not possible to view each step in the design process as singular.
Each step creates more insight and information about the final design.
Making a very strong separation between the steps forces the developer to make decisions on to little information.
\item The term features has to be split in to functions and components for a hardware design.
The actual implementation are the components such that they can perform the function.
\end{itemize}

Another point was noticed while evaluation the complete preliminary design phase.
The lack of a team makes it easy to forget documenting intuitive design decisions.
Although the design method is followed as closely as possible, it often occurs that a decision is made outside of the working environment.
This was noticed during the writing of this chapter that some design decisions were completely missing.
However, during the next phase, these decisions do play a crucial role.
Therefore, this section will give a short recap of the planned design.

\subsubsection{Complete system}
From the initial design the abstract shape of the design is clear.
This is still in line with \autoref{fig:general_design}.
The SCARA is small and can therefore move the arm quick with a fine precision.
At the end of the SCARA there is a end-effector that can grab, hold, end release tool.
It holds a marker while writing and with help of the SCARA it can release the marker.
Then it can grab a cleaning tool to erase whiteboard.
To compensate for the small reach of the SCARA, the SCARA will be mounted to a carriage.
This carriage is suspended from cables and can move along the whiteboard.
The cables give the system a enormous range and velocity.
However, it is not very good in acceleration as cables cannot push.
This makes it suitable for the large and course movements along the board, which complements the movement characteristics of the SCARA.



\subsubsection{SCARA}
The central component of the system is the SCARA.
There are a couple of design options for the SCARA.
As the dynamic complexity is a important part of this design, there will be two arms.
There are some different options for the configuration of the arms and their actuation.
\autoref{fig:configurations} shows four of the possible configurations that are considered during the design phase.
There are still options about where to place the motors and how to connect the joints.
\rrot{Figure needs some graphic improvement}
%\begin{figure}
% \centering
% \includegraphics[width=\linewidth]{graphics/IMG_20201001_134140.jpg}
% \caption{Four different SCARA configurations}
% \label{fig:configurations}
%\end{figure}

\subsubsection{End-effector}
The end-effector is the connection between the SCARA and the tool.
It has two main functions: lifting the tool from the board and switching the tool.
The tool switching functionality is performed by the SCARA as well, by moving the end-effector to the right position.
However, the role of the SCARA is strongly dependent\footnote{ Note, that this dependency exists but not represented in \autoref{fig:robmosys} due to the limitation of the current method.} on how the end-effector is implemented.
For the grabbing function there is a configuration that uses a spring-loaded clamp.
Where one side of the clamp is longer so it can be opened by moving the SCARA.
This operation is shown in \autoref{fig:gripper}
%\begin{figure*}
% \centering
% \includegraphics[width=\linewidth]{graphics/IMG_20201001_144018.jpg}
% \caption{Operation principle of a spring-loaded tool clamp showed from left to right. The green circle represents the tool and the red arm a tool holder. The solid ground is what pushed the upper arm open so the marker can be placed in the tool holder.}
% \label{fig:gripper}
%\end{figure*}

Another dynamically simpler option is to open the clamp with a motor.
The motor adds weight to the end-effector which might require the SCARA to operate slower or to be build stronger.
This component is probably the most difficult one because it requires clamping of the tools.
Modeling this behavior is difficult as it will involve contact dynamics.

\subsubsection{Cable driven Carriage}
The end-effector and the SCARA are moved all together on a carriage.
The carriage will be suspended from two or four cables.
A configuration with two cables is the simplest.
However, the tension in this system is generated by the gravitational pull.
This introduces limitations in the acceleration of the system.
If the carriage moves upwards and the cable pulleys stop.
The carriage is only decelerated by the force of gravity.
Moving over its set point, followed by crashing down in to the cables.

However, making the system with four motorized pulleys makes the system over constrained.
This will solve the acceleration problem. But it will create a difficult positioning system.
As all the wires have to be tensioned but not distort the movement by restricting the other motors.

\subsubsection{Electronics}
Although this mainly is a hardware design, there is going to be some control-software.
For this the likely option is a STM nucleo board with RIOT-OS as a embedded OS.
This choice is mainly because of previous experience and local knowledge of the operating system.

\input{content/case_experiment_problem_description.tex}
\input{content/case_experiment_specifications.tex}
\input{content/case_experiment_initial_design.tex}
\input{content/case_experiment_feature_definition.tex}
\input{content/case_experiment_test_protocol.tex}
\input{content/case_experiment_recap.tex}


\section{First Development Cycle} \section{First Development Cycle}
\subsection{Feature Selection} \subsection{Feature Selection}


+ 46
- 0
content/case_experiment_feature_definition.tex View File

@@ -0,0 +1,46 @@
%&tex
\subsection{Feature Definition}
\label{sec:case_featuredefinition}
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.85\linewidth]{graphics/robmosys}
\caption{Feature Definition based on the separation of levels introduced by RobMoSys}
\label{fig:robmosys}
\end{figure*}

\subsubsection{Evaluation}
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 complex 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.

+ 163
- 0
content/case_experiment_initial_design.tex View File

@@ -0,0 +1,163 @@
%&tex
\subsection{Initial design}
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 explained in the following sections.
From the possible configurations, the optimal configuration that fits the specifications is made into an initial design.
\subsubsection{Cable-Driven}
The cable-driven robot is suspended with multiple cables.
The end-effector that contains the marker is moved along a board by changing the length of the cables.
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.
\begin{figure}
\centering
\includegraphics[width=10.8cm]{graphics/cablebot.pdf}
\caption{Planar view of cable driven robot. This setup contains two motorized pulleys in both top corners. From these two cables a mass is suspended at position $x,y$.
By changing the length of the cables, the mass can be moved over along the whole board.}
\label{fig:cablebotdrawing}
\end{figure}
\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$.
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}

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.
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.
Depending on the implementation, the extra cables make the system over-constrained.
Nevertheless, the extra cables allow for higher acceleration limits in vertical and horizontal direction.

\subsubsection{Cartesian-coordinate robot}
This configuration is a very common design for plotters and shown in \autoref{fig:plotter}.
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 rather simple.
A bigger challenge is the construction of the system, as the vertical slider has to stay vertical during operation.
Especially the length of this setup makes twisting of the vertical slider more likely.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/plotter.pdf}
\caption{This Cartesian plotter consists of two horizontal sliders to provide the $x$-movement and one vertical slider to provide the $y$-movement.}
\label{fig:plotter}
\end{figure}

\subsubsection{Polar-coordinate robot}
This robot is a combination of a prismatic and a revolute joint.
Where the revolute joint can rotate the prismatic joint as seen in \autoref{fig:polar}.
With this it can reach any point within a radius from rotational joint.
This is a little more complex design than the Cartesian robot.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/polar.pdf}
\caption{A combination of a revolute joint and a prismatic joint, creating a polar-coordinate robot.}
\label{fig:polar}
\end{figure}
\begin{marginfigure}
\centering
\includegraphics[width=3.74cm]{graphics/polar_protrude.pdf}
\caption{The diagonal lined section shows the part of the protruding area that is used by the arm.}
\label{fig:polar_protrude}
\end{marginfigure}

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.
\autoref{fig:polar_protrude} gives an impression of the required area.
Even with this area, the arm cannot reach the complete board.
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 quadratically.
Furthermore, the long arm introduces stiffness problems and it amplifies any inaccuracy in the joint.
\subsubsection{SCARA}
The SCARA robot is a configuration with two linkages that are connected via rotational joints.
It can be compared to a human arm drawing on a table as seen in \autoref{fig:scara}.
Similar to the Polar robot it can reach all points within a radius from the base of the robot.
However, the arm can be configurated to not protrude outside of the board.
If the situation requires the arm to protrude, it is still significantly less than the polar arm (\autoref{fig:polar_protrude}).
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 is therefore not a robot that is convenient with large working areas.
However, it can be really quick and precise in relative small areas.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/scara.pdf}
\caption{Schematic example of a SCARA, consisting of two rotation linkages. This setup can be compared to a human arm, where the gray base above the whiteboard represents the shoulder and the connections between both linkages the elbow.}
\label{fig:scara}
\end{figure}

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

\begin{table}[]
\caption{Table with comparison of the four proposed configurations and a combined configuration of the cable bot and the SCARA.}
\label{tab:initial_design}
\begin{tabular}{l|l|l|l|l|l|}
\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
\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.
The grading for the combined system is shown in the most right column in \autoref{tab:initial_design}.

\begin{figure}
\centering
\includegraphics[width=10.8cm]{graphics/combined.pdf}
\caption{Combined system that integrates the cable bot together with the SCARA. The SCARA in red is mounted on the carriage in blue. This carriage is then suspended by cables.}
\label{fig:combined}
\end{figure}
In the combined system, the SCARA will only be large enough to write a small number of characters at the time.
This will alternate with the cable bot moving the base of the SCARA to the next position, so that it can write the next set of characters on the whiteboard.
\autoref{fig:combined} shows a simple view of the system.

\subsubsection{Evaluation}
This was the first step that felt really productive in the design process.
It created a enormous amount of information and insight of the design.
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?

+ 19
- 0
content/case_experiment_problem_description.tex View File

@@ -0,0 +1,19 @@
%&tex
\subsection{Problem Description}
In the problem description the need for a system can be described as follows:
\begin{itemize}
\item Write a twitter message, or tweet, on a whiteboard.
\item Remove the tweet from the whiteboard.
\item Write the tweet within three minutes on the board.
\item The text must be readable across a meeting room.
\item The solution must contain interesting dynamics.
\end{itemize}

\subsubsection{Evaluation}
The problem description is very brief, which is not a complete surprise.
As most of the work for the problem description was already done by choosing the subject of design.
However, it was not expected to be this minimal.
Perhaps the most serious disadvantage is the absence of stakeholders.
Normally, a good problem definition focusses on getting the stakeholders on the same line \autocite{shafaat_exploring_2015}.
However, this case study does only have one stakeholder, the author, defeating the purpose getting everyone on the same line.
Creating a more elaborate problem description would not improve the following design process, but it does cost valuable time.

+ 96
- 0
content/case_experiment_recap.tex View File

@@ -0,0 +1,96 @@
%&tex
\subsection{Recap}
During the problem definition and the specifications step it was difficult to stay within the "what" has to be solved and not go into the "how" it has to be solved.
Furthermore,
The test definitions of the last step conclude the preliminary design phase.
This preliminary design shows a clear notion of a hasty execution from a design standpoint.
The preliminary design was performed over a period of 5 weeks, by one developer with little experience in design documentation.
This makes notion of hasty not surprising for this unproven design method.
That does not mean that this preliminary design is a waste of time.
From the evaluation moments during the preliminary phase there are a couple of interesting points.
\begin{itemize}
\item The lack of a design team with experienced engineers would drastically improve the execution of this design phase.
Such a team is also able to find the smaller problems of such a design phase, which are currently completely overlooked.
\item It is not possible to view each step in the design process as singular.
Each step creates more insight and information about the final design.
Making a very strong separation between the steps forces the developer to make decisions on to little information.
\item The term features has to be split in to functions and components for a hardware design.
The actual implementation are the components such that they can perform the function.
\end{itemize}

Another point was noticed while evaluation the complete preliminary design phase.
The lack of a team makes it easy to forget documenting intuitive design decisions.
Although the design method is followed as closely as possible, it often occurs that a decision is made outside of the working environment.
This was noticed during the writing of this chapter that some design decisions were completely missing.
However, during the next phase, these decisions do play a crucial role.
Therefore, this section will give a short recap of the planned design.

\subsubsection{Complete system}
From the initial design the abstract shape of the design is clear.
This is still in line with \autoref{fig:general_design}.
The SCARA is small and can therefore move the arm quick with a fine precision.
At the end of the SCARA there is a end-effector that can grab, hold, end release tool.
It holds a marker while writing and with help of the SCARA it can release the marker.
Then it can grab a cleaning tool to erase whiteboard.
To compensate for the small reach of the SCARA, the SCARA will be mounted to a carriage.
This carriage is suspended from cables and can move along the whiteboard.
The cables give the system a enormous range and velocity.
However, it is not very good in acceleration as cables cannot push.
This makes it suitable for the large and course movements along the board, which complements the movement characteristics of the SCARA.



\subsubsection{SCARA}
The central component of the system is the SCARA.
There are a couple of design options for the SCARA.
As the dynamic complexity is a important part of this design, there will be two arms.
There are some different options for the configuration of the arms and their actuation.
\autoref{fig:configurations} shows four of the possible configurations that are considered during the design phase.
There are still options about where to place the motors and how to connect the joints.
\rrot{Figure needs some graphic improvement}
%\begin{figure}
% \centering
% \includegraphics[width=\linewidth]{graphics/IMG_20201001_134140.jpg}
% \caption{Four different SCARA configurations}
% \label{fig:configurations}
%\end{figure}

\subsubsection{End-effector}
The end-effector is the connection between the SCARA and the tool.
It has two main functions: lifting the tool from the board and switching the tool.
The tool switching functionality is performed by the SCARA as well, by moving the end-effector to the right position.
However, the role of the SCARA is strongly dependent\footnote{ Note, that this dependency exists but not represented in \autoref{fig:robmosys} due to the limitation of the current method.} on how the end-effector is implemented.
For the grabbing function there is a configuration that uses a spring-loaded clamp.
Where one side of the clamp is longer so it can be opened by moving the SCARA.
This operation is shown in \autoref{fig:gripper}
%\begin{figure*}
% \centering
% \includegraphics[width=\linewidth]{graphics/IMG_20201001_144018.jpg}
% \caption{Operation principle of a spring-loaded tool clamp showed from left to right. The green circle represents the tool and the red arm a tool holder. The solid ground is what pushed the upper arm open so the marker can be placed in the tool holder.}
% \label{fig:gripper}
%\end{figure*}

Another dynamically simpler option is to open the clamp with a motor.
The motor adds weight to the end-effector which might require the SCARA to operate slower or to be build stronger.
This component is probably the most difficult one because it requires clamping of the tools.
Modeling this behavior is difficult as it will involve contact dynamics.

\subsubsection{Cable driven Carriage}
The end-effector and the SCARA are moved all together on a carriage.
The carriage will be suspended from two or four cables.
A configuration with two cables is the simplest.
However, the tension in this system is generated by the gravitational pull.
This introduces limitations in the acceleration of the system.
If the carriage moves upwards and the cable pulleys stop.
The carriage is only decelerated by the force of gravity.
Moving over its set point, followed by crashing down in to the cables.

However, making the system with four motorized pulleys makes the system over constrained.
This will solve the acceleration problem. But it will create a difficult positioning system.
As all the wires have to be tensioned but not distort the movement by restricting the other motors.

\subsubsection{Electronics}
Although this mainly is a hardware design, there is going to be some control-software.
For this the likely option is a STM nucleo board with RIOT-OS as a embedded OS.
This choice is mainly because of previous experience and local knowledge of the operating system.


+ 60
- 0
content/case_experiment_specifications.tex View File

@@ -0,0 +1,60 @@
%&tex
\subsection{Specifications}
\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}}.
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.
Using \ac{ears} to define these specifications gives:
\begin{enumerate}
\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.
\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 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.
\end{enumerate}
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}

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}
\subsubsection{Evaluation}
The specifications step was performed without problems.
Defining the specifications for the problem description did not present any difficulty.
Due to the simplicity of the problem description, there were no contradictory requirements, which would complicate the specifications.
Furthermore, a single stakeholder takes away any negotiation the stakeholders.

Although the specifications itself are not difficult to define, ensuring that they are complete is difficult.
Team members and stakeholders help to spot any ambiguity or problems with the validity.
\ac{ears} was very useful in this case as it gives a strong template to help avoid ambiguity.

+ 82
- 0
content/case_experiment_test_protocol.tex View File

@@ -0,0 +1,82 @@
%&tex
\subsection{Test Protocol}
The last step of the preliminary design is to design tests.
The tests are designed around the specifications.
However, during the creation of the tests it was found that the list of specifications were lacking.
Furthermore, the previous steps did not provide any order of operation.
During this step the order of operation and additional specifications are determined.

There are two modes of operation: writing and wiping.
The writing operation can be split in the following steps:
\begin{enumerate}
\item Move cable driven carriage to position of characters.
\item Write three characters with the SCARA.
\item Repeat step 1 and 2 till the Tweet is on the board.
\item Move carriage away from the text on the board.
\end{enumerate}

The other operation is wiping.
This is similar to the operation of writing with the following steps:
\begin{enumerate}
\item Move cable driven carriage to position of characters.
\item Clear the area in reach of the SCARA.
\item Repeat step 1 and 2 till the Tweet is removed from on the board.
\end{enumerate}
Furthermore, switching between the states requires the tool to be switched.
As this is a difficult operation there are not yet requirements or order of operation specified.

Based on the order of operation, the following specifications were added to the list in \autoref{sec:specifications}:
\begin{enumerate}
\setcounter{enumi}{11}
\item While writing, the SCARA shall have a writing speed of at least 1.5 characters per second.
\item When the Carriage/base of the SCARA is at a static position, the SCARA shall be able to write at least 3 characters at that position.
\item When the SCARA finished writing at their current position, the Carriage shall move the SCARA to it's next position where it can write the subsequent characters.
\item When the SCARA has to be moved to a new position, the Carriage shall perform this movement within 1 second.
\end{enumerate}
These additional specifications are also based on the combined system decission that was made in section \autoref{sec:initialdesign}.
These specifications distribute responsibility between sub-components.

With the updated specifications it was possible to create a number of test cases.
In total there are five small test cases and four large test cases.
The small tests cover a sub-system and the large tests apply on the complete systems.
Each tests has a list of specifications that are covered with the test and for smaller tests the subsystem under test is also determined.
With a short description it is described how the test should be performed.

One of the small tests is performed by drawing a square:
\begin{test}
\begin{description}
\item[Coverage] SCARA
\item[Specifications] 3, 7, 11, 13
\item[Description]
The SCARA must draw a square of at least \SI{50}{\milli\meter} high and \SI{70}{\milli\meter} wide.
This box is large enough to draw at least 3 characters.
This square should be drawn within one second.
If it is slower than that, it is not able to achieve specification 7.
\end{description}
\end{test}
Repeatability is tested in one of the large system wide tests:
\begin{test}
\begin{description}
\item[Coverage] All features
\item[Specifications] 3, 4, 9, 11
\item[Description]
To test the repeatability of the system must do four things:
\begin{itemize}
\item The system will be reset.
\item Draw multiple squares (\SI{60}{\milli\meter} x \SI{60}{\milli\meter}) at a random position within the drawing range (\SI{1000}{\milli\meter} x \SI{300}{\milli\meter}).
\item The system will be reset again.
\item Then in a random order, at least different from the order of squares, a circle with a \SI{55}{\milli\meter} diameter must to be drawn inside the squares.
\end{itemize}
The test is successful if the circles are not drawn outside of the squares.
\end{description}
\end{test}

\subsubsection{Evaluation}
This step was completed with not many difficulties.
The specific order of operation and extra specifications should not be part of this step.
It was already concluded that the steps in the preliminary design were not as expected.
The fact that this step resulted in an additional changes only adds to that conclusion.

The design of the test cases resulted in valuable information about the system.
This information would be very useful in an earlier stage of the preliminary design.


Write Preview
Loading…
Cancel
Save