master-thesis
/
mar
1
0
Forka 0
Codice Problemi 0 Pull Requests 0 Rilasci 16 Wiki Attività
Sfoglia il codice sorgente

Process feedback case execution

feedback-tim
Wouter Horlings 4 anni fa
parent
ff4e657c6a
commit
ac29d845cb
19 ha cambiato i file con 315 aggiunte e 267 eliminazioni
Visualizzazione separata
Diff Options
Show Stats Download Patch File Download Diff File
  1. +8
    -8
      content/appendix_test_cases.tex
  2. +2
    -11
      content/case_evaluation.tex
  3. +11
    -2
      content/case_evaluation_result.tex
  4. +7
    -7
      content/case_experiment.tex
  5. +37
    -37
      content/case_experiment_end-effector.tex
  6. +3
    -5
      content/case_experiment_feature_definition.tex
  7. +81
    -66
      content/case_experiment_initial_design.tex
  8. +3
    -2
      content/case_experiment_problem_description.tex
  9. +53
    -44
      content/case_experiment_prototype.tex
  10. +67
    -49
      content/case_experiment_scara.tex
  11. +11
    -12
      content/case_experiment_specifications.tex
  12. +21
    -13
      content/case_experiment_test_protocol.tex
  13. +5
    -5
      content/input/speclistc.tex
  14. +1
    -1
      content/input/systemtest1.tex
  15. +1
    -1
      content/input/systemtest6.tex
  16. +1
    -1
      graphics/design_flow.tex
  17. +1
    -1
      graphics/design_flow_analysis.tex
  18. +1
    -1
      graphics/electronics.tex
  19. +1
    -1
      include

+ 8
- 8
content/appendix_test_cases.tex Vedi File

@@ -16,7 +16,7 @@
\tcbline
\begin{description}
\item[Features:] Cable Bot
\item[Specifications:] 1, 2, 6, 11, (12)
\item[Requirements:] 1, 2, 6, 11, (12)
\item[Results:] The test passes when:
\begin{itemize}
\item The Cable bot moved along the edge of the text area.
@@ -33,7 +33,7 @@
\tcbline
\begin{description}
\item[Features:] Cable Bot
\item[Specifications:] 7, 9, (12), 14, 15, 16
\item[Requirements:] 7, 9, (12), 14, 15, 16
\item[Results:] The test passes when:
\begin{itemize}
\item At the start and end of the test, the Cable bot does not move relative to the board.
@@ -52,7 +52,7 @@
\tcbline
\begin{description}
\item[Features:] SCARA, End-Effector
\item[Specifications:] 3, 4, (12), 13, 14
\item[Requirements:] 3, 4, (12), 13, 14
\item[Results:] The test passes when:
\begin{itemize}
\item The SCARA wrote three characters on the whiteboard within \SI{2}{\second}.
@@ -68,7 +68,7 @@
\tcbline
\begin{description}
\item[Features:] SCARA, End-Effector
\item[Specifications:] (5), (12), 17
\item[Requirements:] (5), (12), 17
\item[Results:] The test passes when:
\begin{itemize}
\item A tool is released from the end-effector and stored for later use.
@@ -90,7 +90,7 @@
\tcbline
\begin{description}
\item[Features:] SCARA, End-Effector, Cable Bot
\item[Specifications:] 1, 2, 3, (12)
\item[Requirements:] 1, 2, 3, (12)
\item[Results:] The test passes when:
\begin{itemize}
\item All lines are drawn, 11 vertical and 4 horizontal lines.
@@ -118,7 +118,7 @@ the quick brown fox jumps over the lazy dog!?@,.-
\tcbline
\begin{description}
\item[Features:] SCARA, End-Effector, Cable Bot
\item[Specifications:] 1, 2, 3, 4, (5), 6, 7, 12, 13, 14, 15, 16
\item[Requirements:] 1, 2, 3, 4, (5), 6, 7, 12, 13, 14, 15, 16
\item[Results:] The test passes when:
\begin{itemize}
\item The text as described is readable from a atleast \SI{4}{\meter} distance.
@@ -133,7 +133,7 @@ the quick brown fox jumps over the lazy dog!?@,.-
\tcbline
\begin{description}
\item[Features:] SCARA, End-Effector, Cable Bot
\item[Specifications:] (5), 10, 11, 12
\item[Requirements:] (5), 10, 11, 12
\item[Results:] The test passes when:
\begin{itemize}
\item The system cleaned the board within \SI{60}{\second}.
@@ -147,7 +147,7 @@ the quick brown fox jumps over the lazy dog!?@,.-
\tcbline
\begin{description}
\item[Features:] SCARA, End-Effector, Cable Bot
\item[Specifications:] 8
\item[Requirements:] 8
\item[Results:] The test passes when:
\begin{itemize}
\item The developer can motivate that the system is complex enough to evaluate the case study.


+ 2
- 11
content/case_evaluation.tex Vedi File

@@ -1,15 +1,6 @@
%&tex
\chapter{Case Study: Evaluation}
\label{chap:case_evaluation}
\begin{marginfigure}
\centering
\includegraphics[width=51mm]{graphics/model_versions.pdf}
\caption{
Levels of detail of the design are shown on the right, starting with the least detail at the top and most detail at the bottom.
Through out the development different types of models are used, these are shown on the left.
}
\label{fig:levels}
\end{marginfigure}
The previous chapter described the development and implementation process of the Whiteboard Writer.
This chapter focusses on the evaluation of the development during the case study.
The design method itself is evaluated in the next chapter.
@@ -20,8 +11,8 @@ Then a section is about the time spend on the development.
Followed by two sections on the role of stake holders and the use of modelling languages during a development.
The last section is a more personal reflection about the development.

\section{Result}
\input{content/case_evaluation_result.tex}
% \section{Result}
% \input{content/case_evaluation_result.tex}

\section{Time Investment}
Prior to each step in the development, I made an estimation on the workload of that particular step.


+ 11
- 2
content/case_evaluation_result.tex Vedi File

@@ -2,10 +2,19 @@
In the end, the development produced eight models with increasing levels of detail and one prototype.
The different levels of detail and how they are modelled are shown in \autoref{fig:levels}.
The assembled \ac{scara} prototype is shown in \autoref{fig:prototype}.
This prototype is able execute the small rectangle as described in \autoref{test1}, and thus passes the test.
This prototype is able to execute the small rectangle as described in \autoref{test1}, and thus passes the test.
In addition, it was possible to write three characters. Therefore, passing \autoref{test_triple_char}.

\begin{figure}
\begin{marginfigure}
\centering
\includegraphics[width=51mm]{graphics/model_versions.pdf}
\caption{
Levels of detail of the design are shown on the right, starting with the least detail at the top and most detail at the bottom.
Through out the development different types of models are used, these are shown on the left.
}
\label{fig:levels}
\end{marginfigure}
\begin{figure}[t]
\hspace{5mm}
\includegraphics[width=96mm]{graphics/prototype.JPG}
\caption{Assembled prototype of the \ac{scara}.}


+ 7
- 7
content/case_experiment.tex Vedi File

@@ -4,23 +4,23 @@
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.
As described in \autoref{sec:sod}, the system to be designed is a "Tweet on a Whiteboard Writer".
As described in \autoref{sec:sod}, the subject of design 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 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}.
The chapter begins with the section about the preparation phase, which contains the five steps from problem description to test protocol step as shown in \autoref{fig:design_plan_analysis}.
This is followed by two completed development cycles in the later two sections.
Both of these sections cover the three steps that are shown in \autoref{fig:design_plan_analysis}.
Each design step is described in a separate subsection.
Herein, the result of the design step is presented and concluded with an evaluation section at the end.
Both of these sections cover the feature selection, variable-detail approach and rapid development steps as shown in \autoref{fig:design_plan_analysis}.
Each design step is described in a separate section.
Herein, the result of each design step is presented and concluded with an evaluation section at the end.
This evaluation section discusses the pairs of questions that were answered according to the evaluation protocol (\autoref{tab:prepost}).
The questions regarding the design method itself are discussed in \autoref{chap:reflection}.

\section{Preparation Phase}
The preparation phase contains four design steps.
It begins with a problem description.
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.
The problem description is used to create a list of system requirements.
Based on the requirements, 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.

\input{content/case_experiment_problem_description.tex}


+ 37
- 37
content/case_experiment_end-effector.tex Vedi File

@@ -1,49 +1,52 @@
With the preparation phase completed, the development cycle is next.
This consists of three steps: Feature selection, Rapid Development and Variable Approach.
This consists of three steps: Feature selection, Rapid Development and Variable-detail Approach.
The current section explains the first development cycle during the design.
For this first cycle of the design process, I design the end-effector.
However, not long after the start of the development process, the implementation proved to be too complex.
However, not long after the start of the development process, the implementation of the end-effector proved to be too complex.
This led to the decision to abort the implemention of the end-effector.
Eventhough no progress was made, this attempted implementation did provide valuable insight in the desing process.
Eventhough no progress was made in the design, this attempted implementation did provide valuable insight in the desing process.

\subsection{Feature Selection}
\label{sec:case_feature_selection_1}
\begin{table}[]
\caption{Overview of the different features and their dependencies, number of tests that are covered and the risk/time factor.
The risk/time factor is calculate as risk divided by time.}
For each feature in the system the dependees, tests and \ac{cof}/time factor is determined, as explained in \autoref{sec:feature_selection}.
These values are combined into \autoref{tab:firstfeatureselection}.
\begin{table}[h]
\caption{Overview of the different features and their dependencies, number of tests that are covered and the \ac{cof}/time factor.
The \ac{cof}/time factor is calculate as \ac{cof} divided by time.}
\label{tab:firstfeatureselection}
\begin{tabular}{|l|l|l|l|l|l|}
\hline
Feature & Dependees & Tests & Risk & Time & Risk/Time \\ \hline
\ac{scara} & - & 3 & 40\% & 10 days & 4 \\ \hline
End-effector & \ac{scara} & 2 & 60\% & 8 days & 7.5 \\ \hline
\ac{cdc} & - & 2 & 30\% & 10 days & 3 \\ \hline
\rowcolors{2}{lightgray}{white!100}
\begin{tabular}{llrrrr}
\toprule
Feature & Dependees & Tests & \ac{cof} & \multicolumn{1}{l}{Time} & \ac{cof}/Time \\
\midrule
\ac{scara} & $-$ & $3$ & $40\%$ & $10$ days & $4 $ \\
End-effector & \ac{scara} & $2$ & $60\%$ & $8$ days & $7.5$ \\
\ac{cdc} & $-$ & $2$ & $30\%$ & $10$ days & $3 $ \\
\bottomrule
\end{tabular}
\end{table}
For each feature in the system the dependees, tests and risk/time factor is determined, as explained in \autoref{sec:feature_selection}.
These values are combined into \autoref{tab:firstfeatureselection}.

The \ac{scara} depends on the end-effector, as explained in the initial design.
However, for the \ac{cdc} no dependency was defined even though it has to lift the other two components.
This is mainly because the torque and range requirements of the \ac{scara} depending on the implementation of the end-effector.
This is mainly because the torque and range requirements of the \ac{scara} depend on the implementation of the end-effector.
Especially the required range depends on the method of grabbing and releasing tools.
For the \ac{cdc} it only changes the mass that has to be lifted.
Upgrading the motor torque is a minor parametric change and the dependency is therefore insignificant.
Upgrading the motor torque is a minor parametric change and the dependency is therefore deemed insignificant.

The testing number is directly the number of tests that apply to that feature.
The risk and time values are not determined with a specific protocol, but with simple engineering judgement.
The estimated risk is high for the end-effector due to the collision dynamics of the operation.
The \ac{cof} and time values are not determined with a specific protocol, but with simple engineering judgement.
The estimated \ac{cof} is high for the end-effector due to the collision dynamics of the operation.
It has to grab something and that is difficult to model. Furthermore, it was not known if that design would work.
The \ac{scara} has the most moving parts, but no difficult dynamics and has therefore an estimated risk of medium.
For the \ac{cdc} there was no real risks and got therefore a low risk indication.
The \ac{scara} has the most moving parts, but no difficult dynamics and has therefore an estimated \ac{cof} of medium.
For the \ac{cdc} there was no real \ac{cof} and got therefore a low \ac{cof} indication.
Based on \autoref{tab:firstfeatureselection}, the end-effector is implemented first.
The end-effector has the most dependees, and is therefore chosen above the other two.

\subsubsection{Evaluation}
This first step of the detail design phase did go well.
Although risk and time assessment is always depend on some engineering judgment, this human factor introduces uncertainty in the assessment.
However, an improved approach for the risk assesment can drastically reduce this human factor.
Although \ac{cof} and time assessment is always depend on some engineering judgment, this human factor introduces uncertainty in the assessment.
However, an improved approach for the \ac{cof} assessment can drastically reduce this human factor.
Within a design team a form of planning poker \autocite{grenning_planning_2002} could be a good option.
\subsection{Rapid Development of the End-Effector}
@@ -52,33 +55,29 @@ Eventhough no progress was made, this attempted implementation did provide valua
The first step is to create an initial design of the model.
In subsequent steps, detail is added to this model.

The previous section explained the relative high risk assessment for the end-effector.
The previous section explained the relative high \ac{cof} assessment for the end-effector.
Which was not exaggerated as the implementation proved to be troublesome.
Eventually, the implementation was unfeasible and was therefore cut short.
Nonetheless did it result in useful evaluation points on the design method.
The process of this step is explained in the following sections.


The development starts with an initial design of the system.
The next step is to develop that further into a model and prototype.
This development did not get past the basic model implementation due to unforeseen difficulties.
However, the evaluation gave new useful insight on the design plan.

\subsubsection{Initial design}
The end-effector is mounted on the \ac{scara} and acts as an interface.
With the end-effector, the \ac{scara} is able to grab and release tools.
There are multiple approaches to handle these tools.
The end-effector is mounted on the \ac{scara} and acts as an interface for the tooling.
The \ac{scara} and end-effector combined are able to grab and release the write and erase tooling.
There are multiple approaches to handle the tooling.
However, there is a trade-off to be made with the \ac{scara} feature, the heavier the end-effector is, the more force the \ac{scara} must deliver.
And because the goal is to make the \ac{scara} light and quick, this end-effector must be light-weight as well.

The best options in this case is a simple spring-loaded clamp.
To release the tool, the clamp is forced open, pushing it against the holder.
As the end-effector is connected to the \ac{scara}, the \ac{scara} is responsible for the pushing force.
Because the actuation force of the \ac{scara} is used, it removes the need for an additional servo in the end-effector.
Resulting in a simpler and lighter design.

The initial design of the clamp and the operation is shown in \autoref{fig:gripper}.
Although this design requires the \ac{scara} to deliver more force.
The relative low mass of the end-effector also keeps the moment of inertia small.
Therefore, the current design reduces the impact on the acceleration of the \ac{scara} to a minimum.
Therefore, the current design reduces the impact on the acceleration of the \ac{scara}.
\begin{figure*}
\centering
\includegraphics[width=151mm]{graphics/end-effector.pdf}
@@ -93,17 +92,18 @@ Eventhough no progress was made, this attempted implementation did provide valua
Based on some experience in modelling with collisions, I decided to use the 20-sim 3D mechanics editor.
Unfortunately, there is little tooling available and there are no debugging options if the model does not behave as expected.
The marker kept falling trough the gripper or flew away.

With the small amount of progress made in two days the implementation was not promising.
A system freeze caused the model to corrupt, where the complete configuration of the shapes and their collisions was lost.
Based on the loss of work and the low feasibility of the implementation, the decision was made to remove the end-effector from the design.

With the end-effector removed, the \ac{scara} gets a direct connection with the marker.
The lifting of the marker from the is included in the \ac{scara} as well.
Furthermore, this means that the erasing is no longer possible as a feature.
Lifting and lowering the marker is included in the \ac{scara} feature as well.
Unfortunately, this means that switching to the eraser is not longer possible as functionality.

\subsubsection{Evaluation}
The lost progress of the model is unfortunate, but the implementation did not go as expected anyway.
It was probably for the best as it forced an evaluation of the design and avoided a tunnel vision while trying to get it to work.
However, it did show the value of the risk/time analysis.
However, it did show the value of the \ac{cof} per time analysis.
This early failure resulted in changes for other components.
But as none of the components were implemented yet, no work was lost.
But as none of the other components are implemented yet, no work is lost.

+ 3
- 5
content/case_experiment_feature_definition.tex Vedi File

@@ -1,8 +1,8 @@
%&tex
\subsection{Feature Definition}
\label{sec:case_featuredefinition}
This step divides the specifications and initial design into features.
These features will be implemented one by one during the development cycle, later in the process.
This step divides the requirements and initial design into features.
These features are implemented one by one during the development cycle, later in the process.
As described in \autoref{sec:featuredefinition}, the functionality of the system is split over four different levels of abstraction.
The result of this split is shown \autoref{fig:robmosys}.
@@ -19,10 +19,8 @@
The skill and service features become a bit more vague, often features fit in both categories.
Sometimes it is difficult to split a skill into a service, as they are already very specific.
Additionally, I attempted to keep the feature tree a bit compact, to keep in scope with this thesis.
If each feature would have been split methodically, the amount of features would be immense.

The components could also use a similar approach as the functions, resulting in a hierarchical structure of sub-components.
Where the \ac{scara} would have motors and electronics as sub-components.
The components also use a similar approach as the functions, resulting in a hierarchical structure of sub-components, where the \ac{scara} would have motors and electronics as sub-components.
% 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 clear separation between features and components.


+ 81
- 66
content/case_experiment_initial_design.tex Vedi File

@@ -1,25 +1,25 @@
%&tex
\subsection{Initial design}
\subsection{Initial Design}
\label{sec:initialdesign}
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 ideas.
These robots can be sorted in four different configurations
These robots are sorted in four different configurations.
Each configuration explained in the following sections.
From the possible configurations, the one that fits the specifications best, is made into an initial design.
From the possible configurations, the one that fits the requirements best, 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 an end-effector with a large range and high velocities.
A basic setup can be seen in \autoref{fig:cablebotdrawing}.
The cable-based positioning system results in an end-effector with a large range and high velocities.
A basic setup is shown in \autoref{fig:cablebotdrawing}.
This given setup contains two cables that are motorized.
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}
\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.}
\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 is moved over along the whole board.}
\label{fig:cablebotdrawing}
\end{figure}
\begin{marginfigure}
@@ -47,9 +47,8 @@
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.
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 rotates.
However, the construction of the slider is not able to rotate, resulting in damage to the system.
The larger system requires longer sliders, which are expensive.
Another difficulty is the actuation of both horizontal sliders, if these sliders do not operate synchronous the vertical slider would slant and likely jam.
\begin{figure}
\centering
\includegraphics[width=8.74cm]{graphics/plotter.pdf}
@@ -59,7 +58,7 @@
\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}.
Where the revolute joint can rotate the prismatic joint as shown in \autoref{fig:polar}.
With this it can reach any point within a radius from the rotational joint.
This is a little more complex design than the Cartesian robot.
\begin{figure}
@@ -82,28 +81,47 @@
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.
This makes the required space of the setup very inefficient.
Another disadvantage is that a long arm increases the moment of inertia and the gravitational torque on the joint 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.
But the SCARA does not protrude like the polar arm (\autoref{fig:polar_protrude}).
The \ac{scara} robot is a configuration with two linkages that are connected via rotational joints.
It compares to a human arm drawing on a table as shown in \autoref{fig:scara}.
Similar to the polar robot it can reach all points within a radius from the base of the robot.
But the \ac{scara} does not protrude like the polar arm (\autoref{fig:polar_protrude}).
Depending on the configuration of the arm, it is possible to keep the arm completely within the area of operation.
A downside is that the mass of the additional joint and extra arm length increase the moment of inertia and gravitational torque similar to the polar robot.
This makes the SCARA configuration convenient for small working areas as that keeps the forces managable.
Additionally, as the arms of the SCARA have a fixed length, it is possible to create a counter balance.
This makes the \ac{scara} configuration convenient for small working areas as that keeps the forces manageable.
Additionally, as the arms of the \ac{scara} have a fixed length, it is possible to create a counter balance.
This can be used to remove any gravitational torque from the system. It would however increase the moment of inertia even further.
For current specifications, the working area is too large for any practical application of the SCARA.
For current requirements, the working area is too large for any practical application of the \ac{scara}.
\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.}
\caption{Schematic example of a \ac{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{Combining}
A fifth option is to combine two of the discussed configurations, wherein the best properties of two configurations are used.
The most interesting combination is the cable bot together with the \ac{scara}.
In this combination, the \ac{scara} is small, only able to write a couple of characters.
The smaller size of the \ac{scara} makes it quick.
To write full sentences the \ac{scara} is placed on a carriage that is suspended by the cable bot.
An example of this \ac{cdc} with the mounted \ac{scara} is shown in \autoref{fig:combined}.
\begin{figure}[h]
\centering
\includegraphics[width=10.8cm]{graphics/combined.pdf}
\caption{Combined system that integrates the cable bot together with the \ac{scara}. The \ac{scara} in red is mounted on the \ac{cdc}.}
\label{fig:combined}
\end{figure}

This increases the complexity of the dynamics of the system, by having four degrees of freedom.
Furthermore, the movement of the \ac{scara} also causes movement of the \ac{cdc}.
Shrinking the \ac{scara} also decreases the challenges regarding construction, as long and unstable arms are out of the picture.

\subsubsection{Choice of system}
The previous sections have shown four different configurations.
These configurations are compared in \autoref{tab:initial_design}.
@@ -111,8 +129,8 @@
\begin{description}
\item{\emph{Range}}\\
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 cable, cartesian, and combined configuration scale very well, the cables or slider rails can be made longer without real difficulty.
The \ac{scara} or polar configuration run into problems with the arm lengths, as forces scale quadratically with their length.
\item{\emph{Speed}}\\
Except for the cable bot, all configurations score sufficient on speed.
The cable bot can reach high velocities, but the acceleration is limited, depending on the configuration, to the gravitational acceleration.
@@ -121,73 +139,70 @@
All systems require DC or stepper motors, but the cartesian setup also requires linear sliders which are expensive, especially for longer distances.
\item{\emph{Obstruction}}\\
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.
All systems except for the cable bot can move themself outside of the working area.
It is possible that the cables of the cable bot obstruct the view.
All systems except for the cable and combined configuration can move themself outside of the working area.
It is possible that the wires of the cable or combined configuration obstruct the view.
However, the wires are expected to be thin enough to not block any text.
\item{\emph{Scalability}}\\
For the scalability, only the cable bot scores high.
For the scalability, the cable bot and the combined system score 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.
For the polar system and \ac{scara}, the forces on the joints scale quadratically with the length of the arms.
However, the \ac{scara} can be build with counter balance making it scale less worse than the Polar system.
\item{\emph{Effective Area}}\\
With the effective area, the system is scored on the area it requires to operated versus the writable area.
The polar configuration has a low score due to the protruding arm.
\item{\emph{Interesting Dynamics}}\\
The last metric, scores the system on the complexity of the dynamics.
This is a more subjective metric, but also a very important one.
In the problem description, the complexity of the dynamics was determined as one of the core requirements.
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.
The combined configuration excels for this metric, as it has 4 degrees of freedom and the \ac{scara} movement can cause the carriage to swing.
\end{description}

\begin{table}[]
\caption{Table with comparison of the four proposed configurations and a combined configuration of the cable bot and the SCARA.}
\begin{table}[h]
\caption{Table with comparison of the four proposed configurations and a combined configuration of the cable bot and the \ac{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|}{Speed} & - & + & + & + + & + \\ \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
\rowcolors{2}{lightgray}{white!100}
\begin{tabular}{l c c c c c }
\toprule
& Cable bot & Cartesian & Polar & \ac{scara} & Combined \\
\midrule
\multicolumn{1}{l}{Range} & $+ +$ & $+ $ & $- -$ & $- $ & $+ +$ \\
\multicolumn{1}{l}{Speed} & $- $ & $+ $ & $+ $ & $+ +$ & $+ $ \\
\multicolumn{1}{l}{Cost} & $+ +$ & $- -$ & $+ $ & $+ $ & $+ $ \\
\multicolumn{1}{l}{Obstruction} & $- $ & $+ $ & $+ $ & $+ $ & $- $ \\
\multicolumn{1}{l}{Scalability} & $+ +$ & $- $ & $- -$ & $- $ & $+ $ \\
\multicolumn{1}{l}{\begin{tabular}[c]{@{}l@{}}Effective\\ area\end{tabular}} & $+ +$ & $+ $ & $- -$ & $+ $ & $+ +$ \\
\multicolumn{1}{l}{\begin{tabular}[c]{@{}l@{}}Interesting\\ dynamics\end{tabular}} & $- $ & $- -$ & $- $ & $+ $ & $+ +$ \\
\midrule
\hiderowcolors
\multicolumn{1}{l}{Total} & \multicolumn{1}{r}{$ +5$} & \multicolumn{1}{r}{$ -1$} & \multicolumn{1}{r}{$ -4$} & \multicolumn{1}{r}{$ +4$} & \multicolumn{1}{r}{$ +8$} \\
\bottomrule
\end{tabular}
\end{table}
Based on this comparison, I disqualified the cartesian and polar system.
The cartesian has no interesting dynamics and is expensive to build at the current scale.
The polar system is just not feasible, the arm length required to cover the writing area results forces that are too large.
Making a rotational joint that delivers the torque and velocity required for such an arm, is just out of the scope of this case study.
The two remaining configurations come with serious downsides as well.
The cable bot is slow, and the arm length for the SCARA is also likely to cause problems.
However, by combining both, it is possible to get a system that fits the requirements very well.
By building a small SCARA that is the suspended by the cable bot, it combines the best of both worlds.
The small SCARA is quick and accurate, 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}
\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. 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.
The comparison in \autoref{tab:initial_design} shows that the combined configuration as preferred.
Which is not surprising as it combines the advantages of both the cable bot and \ac{scara}.
Although those systems have a good score of their own, they have disadvantages.
The cable bot has low acceleration and no challenging dynamics.
The main difficulty for the \ac{scara} is being able to build it large enough.

The combined configurations, complement each other.
The range of the \ac{cdc} allows for a small \ac{scara}.
The small size of the \ac{scara} makes it quick.
This compensates for the low acceleration of the cable bot and removes the need for a \ac{scara} with long arms.
Therefore, the choice of configuration is the combined system of the \ac{scara} and \ac{cdc}.
\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.
In hind sight, it would have been useful to have this information during the requirements step.
However, as the requirements step are mainly on the "what" to solve, and specifically not on "how" to solve it, this information was avoided on purpose during the requirements step.

This step did result in an initial design that can be used in the next steps.
This step did result in an initial design that is 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.
For the problem description and the requirements 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.
Especially with complex system, it is unrealistic to create complete requirements before making design decisions.
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}.

+ 3
- 2
content/case_experiment_problem_description.tex Vedi File

@@ -2,7 +2,8 @@
\subsection{Problem Description}
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.
A specific requirement is that the system must be complex enough, such that the specific aspects of the design method are used.
These specific aspects are the ones that deal with complexity and are subject to the evaluation.
The system must meet the following requirements:
\begin{itemize}
\item Write a twitter message, or tweet, on a whiteboard.
@@ -18,5 +19,5 @@ As most of the work for the problem description was already done by choosing the
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.
However, this case study does only have one stakeholder, the author, defeating the purpose of getting everyone on the same line.
Creating a more elaborate problem description would not improve the evaluation of the design process, but it does cost valuable time.

+ 53
- 44
content/case_experiment_prototype.tex Vedi File

@@ -1,49 +1,62 @@
%&tex
To validate the dynamical and mechanical models, I will build a prototype of the current design.
To validate the dynamical and mechanical models, I have build a prototype of the current design.
For the mechanical design, the CAD model is used to print the custom parts.
Other components, such as steppers, microcontroller, screws and miscellaneous electronics, are ordered.
To test the dynamics, the steppers and servo have to be actuated.
To achieve this actuation a control law is written in software.
To achieve this actuation a control law has been written in software.

\subsection{Mechanical Construction}
With the 3D printed parts the SCARA was easy to construct.
The diameter of the holes in the parts were printed slightly undersized.
This was on purpose, such that the holes can be drilled to the specified size.
With the 3D printed parts the \ac{scara} was easy to construct.
To connect the bodies on the joints, a bolt with washers is used.
Although this is clearly not the ideal technique to build joints, it was by far the easiest option.
Although this is clearly not the ideal technique to build joints, it sufficed and was by far the easiest option.

During assembly I noticed that the bolts of a joint and those that hold the stepper motor in place collided.
This was possible because the bolts were not included in the CAD-model.
In hindsight this should have been included.
Fortunately there was enough clearance to mount the SCARA slightly further on the axle.
Resulting in an operating SCARA without having to redesign the mechanics.
Fortunately there was enough clearance to mount the \ac{scara} slightly further on the axle.
Resulting in an operating \ac{scara} without having to redesign the mechanics.

\subsection{Control of the SCARA}
\subsection{Control of the \ac{scara}}
Although the focus of the design plan was specifically not the software, it still forms an important part of the development.
To run the software, I chose for a STM32 \ac{mcu}, which is a powerful processor with sufficient IO available.
The servo motor is directly connected to the IO of the \ac{mcu} while the stepper motor is connected via a stepper driver board\footnote{IC with H-bridges to power the stepper motor.}, see \autoref{fig:signals}.
RIOT-OS was chosen as an operating system due to prior experience and available support.
To write characters on the board the following tasks are implemented in software:
\begin{itemize}
\item Software driver for the stepper controller
\item Software driver for servo motor
\item Inverse Kinematics Function
\item Control/Path planning
\end{itemize}
\begin{marginfigure}
\centering
\includegraphics[width=5cm]{graphics/electronics.pdf}
\caption{Hardware connections. The servo motor connected to a pwm-output. The stepper controller connected via UART and IO-pins. The stepper controller provides the correct current for the stepper motors.}
\caption{Hardware connections. The servo motor connected to an IO-output. The stepper controller connected via UART and IO-pins. The stepper controller provides the correct current for the stepper motors.}
\label{fig:signals}
\end{marginfigure}
Although the focus of the design plan was specifically not the software, it still forms a important part of the development.
To run the hardware, I chose for for a STM32 \ac{mcu}. This is a powerfull processor with sufficient IO available.
The servo motor is directly connected to the IO of the \ac{mcu} while the stepper motor is connected via a stepper controller board, see \autoref{fig:signals}.
RIOT-OS was chosen as an operating system due to prior experience and available support.
To be able to write characters on the board the following tasks have to be implemented in software:
\begin{itemize}
\item Driver for the stepper controller
\item Driver for servo motor
\item Inverse Kinematics
\item Control/Path planning
\end{itemize}

The stepper controller chip can be configured over UART and has two simple IO pins for step and direction signal.
To simplify the control, the software driver configures the stepper controller and includes functions to move the stepper motor to a certain angle.
Meaning that the feedforward control of the steppers is handled by the software driver class.
The angle of the servo motor is controlled by the pulse length of a square wave.
This signal is generated in the IO peripherals as a PWM signal.
The software driver has a toggle function that changes the pulse length. Making the maker lift from or lower on the board.
The code for the servo driver was already available as a module in RIOT-OS.
The task of the software driver is to handle the communication to the hardware stepper drivers.
At initialisation of the software, the hardware stepper driver is configured over hardware.
When a new set-point is set in the software driver, the time between each step is calculated.
The software driver creates a time-out event with a callback that sends a step signal to the hardware stepper driver.
The use of time-out events make it possible to run multiple stepper drivers in software asynchronous.

The set-point for the software driver is calculated by interpolating the path between the current position and the desired position.
This interpolation is necessary to draw a straight line between two points with the \ac{scara}, as a linear movement of the angle would create curved paths.
Because the software stepper driver counts the steps send to the stepper motor, which gives the current position of the \ac{scara}.
The calculation and update of the next set-point is done with a fixed interval.
To calculate the angles that are needed for the set-points a lookup table is used, which replaces expensive trigonometric calculation needed for inverse kinematics.
An advantage of this approach is that it can cope with missed or late event callbacks for the software stepper driver.

The path planning is responsible for the desired position.
This can be a rectangle or a set of three characters.
The font for the characters is made by \textcite{hudson_asteroids_2015} and consists of a header file with an array of coordinates for each character.
When the current position of the \ac{scara} is within range of the desired position, the desired position is updated with the next coordinate of the character.

There are two special elements in the array of coordinates: up and down.
These specify whether the marker should be lifted from or lowered on the board.
In the transition period of lifting or lowering, there is a short builtin wait for the stepper movement, to avoid unwanted drawing.
When the marker is lifted, the interpolation is disabled and the stepper drivers move directly to the position where the next line starts.
\begin{marginfigure}
\centering
\includegraphics[width=2.83cm]{graphics/code_objects.pdf}
@@ -51,21 +64,17 @@ The code for the servo driver was already available as a module in RIOT-OS.
\label{fig:objects}
\end{marginfigure}

The path planning is able to write three characters with the SCARA.
The font for the characters is made by \textcite{hudson_asteroids_2015}.
This font consists of a simple coordinates for characters and is written in C.
The path planning is updated with a fixed interval.
During the update, the set point is linearly interpolated, otherwise the lines are curved between set points.
To get the angle set points for the stepper motors, the $x,y$-coordinate set point is converted using the inverse kinematics.
The inverse kinematics is analogous to the model that is used in the development cycle of the SCARA.
The angle set points are updated for the stepper driver.
The data path is shown in \autoref{fig:objects}.
For the lifting of the marker the servo on the arm is used.
The angle of the servo motor is controlled by the pulse length of a square wave.
The software servo driver switches the pulse length when it is ordered to lift or lower the marker.
The code for the servo driver is a provide module in RIOT-OS.

In summary, the path planning uses the coordinates of the characters to determine the next desired position and the state of the marker.
When a line must be drawn the marker is lowered and the path to the end of the line is interpolated.
The position from the interpolation is then converted to angles using the look-up table.
The angles are pushed to the software stepper driver, which are used to calculate the interval between steps.
The data path for drawing a line is shown in \autoref{fig:objects}.

The stepper driver has a feedforward controller.
The driver limits the acceleration and speed to keep the motor within operating specifications and keeps track of the current status of the stepper motor.
When the angle set point is updated, the driver calculates the time interval between each step and sets a hardware timer to that interval.
This allows the controller and other drivers to be executed between each step.
This approach works only if the code executes fast enough.
During the testing, I found that the inverse kinematics calculation was too expensive, even with the integrated floating point unit.
As the \ac{mcu} has sufficient flash storage available, the inverse kinematics calculation is replaced by a lookup table.
\section{Result}
\input{content/case_evaluation_result.tex}


+ 67
- 49
content/case_experiment_scara.tex Vedi File

@@ -7,18 +7,21 @@
The implementation of the end-effector proved to be unfeasible and was therefore removed from the design.
This means that only two features are left.
\autoref{tab:featurestab2} shows an updated feature comparison.
Compared with the previous feature selection in \autoref{tab:firstfeatureselection}, the number of tests for the \ac{scara} decreased and the Risk/Time increased.
Compared with the previous feature selection in \autoref{tab:firstfeatureselection}, the number of tests for the \ac{scara} decreased and the \ac{cof}/Time increased.
This is because \autoref{test_tool_change} relied on both the \ac{scara} and the End-effector which is no longer applicable.
Based on the feature comparison, the next component to implement is the \ac{scara}.

\begin{table}[]
\begin{table}[h]
\caption{Comparison of the two remaining features in the design process. This table is an updated version of \autoref{tab:firstfeatureselection}.}
\label{tab:featurestab2}
\begin{tabular}{|l|l|l|l|l|l|}
\hline
Feature & Dependees & Tests & Risk & Time & Risk/Time \\ \hline
\ac{scara} & - & 2 & 50\% & 12 days & 4.2 \\ \hline
\ac{cdc} & - & 2 & 30\% & 10 days & 3 \\ \hline
\rowcolors{2}{white!100}{lightgray}
\begin{tabular}{llrrrr}
\toprule
Feature & Dependees & Tests & \ac{cof} & \multicolumn{1}{l}{Time} & \ac{cof}/Time \\
\midrule
\ac{scara} & $-$ & $2$ & $50\%$ & $12$ days & $4.2$ \\
\ac{cdc} & $-$ & $2$ & $30\%$ & $10$ days & $3$ \\
\bottomrule
\end{tabular}
\end{table}

@@ -26,7 +29,8 @@
The feature selection for the second cycle is an updated selection process of the first cycle (\autoref{sec:case_feature_selection_1}).
This resulted in a quick and effortless feature selection process, as most of the work was already done.

\subsection{Rapid Development for SCARA}
\subsection{Rapid Development for \acs{scara}}
\label{sec:rdfs}
The goal is to present a functional model of the \ac{scara}.
The requirements state that it must be able to write three characters within two seconds.
And to pass \autoref{test1} it must draw a \SI{50}{\milli\meter} by \SI{70}{\milli\meter} rectangle within one second.
@@ -34,33 +38,33 @@
For the lowest detail level of the design, I decided on a kinematics model.
The model is very simple as it does not implement any physics.
However, the model enables me to tinker with the design parameters, such as the lengths of the linkages and joint angles.
In the following steps, the level of detail is gradually increased to arrive at a competent model.
In the following steps, the level of detail is gradually increased to arrive at an elaborate model.
Planning all the different steps in advance is difficult as design decisions still need to be made.
Nonetheless, I can describe at least the following levels of detail for the model:
\begin{enumerate}
\item Basic kinematics model, no physics.
\item Basic physics model, ideal 2D physics.
\item Basic Motor behavior, 2D physics with non-ideal DC-motor.
\item Basic control law, path planning.
\item \textbf{Basic kinematics model:} forward and inverse kinematics, no physical behavior.
\item \textbf{Basic physics model:} ideal 2D physics, ideal joints and rigid bodies with mass and inertia.
\item \textbf{Basic motor behavior:} joint actuation with non-ideal DC motor.
\item \textbf{Basic control law:} path planning.
\end{enumerate}
After these steps the optimal order of implementation for the levels of detail becomes vague.
However, the following elements are required to make a competent model:
However, the following elements are required to make an elaborate model:
\begin{itemize}
\item Improved motor model
\item 3D physics model
\end{itemize}
When the first design decisions made, the succeeding levels of detail for these and other elements are laid out.
When the first design decisions are made, the succeeding levels of detail for these and other elements are laid out.


\subsubsection{Evaluation}
The current steps in the rapid development are difficult to perform.
There is, unsurprisingly, lack of a clear vision of the end-product.
Which makes an explicit description of every level of detail not realistic.
However, it was still possible to describe the initial steps in the level of detail of the design.
There is, unsurprisingly, lack of a clear vision of the end-product, which makes an explicit description of every level of detail not realistic.
However, it was still possible to describe steps for the initial levels of detail in the design.
The remaining elements, that are essential to the design, take shape in a later stage of the development.
Apart from this small deviation, the deliverables of this step are a good start of this development cycle.

\subsection{Variable Detail Approach}
\subsection{Variable-Detail Approach}
The following steps is to increase the level of detail of the model.
The initial model together with the set of steps in the detail level is inherited from the previous design step.
To start, I implement the basic model and implement the different levels of detail.
@@ -68,7 +72,7 @@
The decisions make it possible to plan the subsequent levels of detail.
Implementing these details results in a competent model.

\subsubsection{Basic Kinematics Model}
\subsubsection{Basic Design Implementation}
\begin{marginfigure}
\centering
\includegraphics[width=0.9\linewidth]{graphics/scara_arm_kinematics.pdf}
@@ -81,13 +85,13 @@
I tested if the \ac{scara} reaches the required operating area, to satisfy system requirement 14.
The operating area is a couple of centimeters away from the base of the \ac{scara}.
This is to avoid the singularity point that lies at the base of the \ac{scara}.
Resulting in longer arms than strictly necessary but reducing the operating angles of the joints, allowing for simpler construction.
Resulting in the arms being longer than strictly necessary but it reduces the operating range for the angles of the joints, allowing for simpler construction.
At this point, there are already multiple design decisions made about the position of the operating area and the arm lengths.
As second detail iteration the basic physics of the model are implemented.
The model is in the form of a double pendulum, with two actuated joints.
The ideal motors in the joints made give the \ac{scara} unlimited acceleration.
As the one of the goals is to get an indication on what the required torque for these joints is, the ideal motors are replaced with basic DC-motors.
The ideal motors in the joints give the \ac{scara} unlimited acceleration.
Replacing the ideal motors with a DC-motor gives an indication about the torque required for operation.
Implementing a simple PID-controller allows the \ac{scara} to follow the rectangular path as described in \autoref{test1}.
The simulation allowed me to determine the minimum requirements of the motors.
The motors must be able to deliver at least \SI{0.2}{\newton\meter} of torque and reach an angular velocity of at least \SI{12}{\radian\per\second}.
@@ -97,13 +101,14 @@
However, the current configuration is very simple but requires a motor in the joint.
In \autoref{fig:scaradesign}, this setup is shown as configuration 1.
The disadvantage is that a motorized joint is heavy, which has to be accelerated with the rest of the arm.

Other configurations in \autoref{fig:scaradesign} move the motor to a static position.
Configuration 2 is a double arm setup, but has quite limited operating range, caused by a singularity region in the system when both arms at the top are in line with each other.
Configuration 2 is a double arm setup, but has a limited operating range, caused by a singularity region in the system when both arms at the top are in line with each other.
Configuration 3 also has such a singularity, but due to the extended top arm this point of singularity is located outside of the operating range.
However, this configuration requires one axis with two motorized joints on it.
Even though this is possible, it does increase the complexity of the construction.
By adding an extra linkage, the actuation is split as shown in configuration 4.
Configuration 4 is the preferred option for the \ac{scara}
Configuration 4 is the preferred option for the \ac{scara}.
\begin{figure}
\centering
\includegraphics[width=0.875\linewidth]{graphics/scara_design.pdf}
@@ -111,30 +116,38 @@
\label{fig:scaradesign}
\end{figure}

The actuation of the arm is done with stepper motors, which have a strong advantage over DC-motors with their holding torque.
The holding torque removes the need for a feedback controller that compensates for external forces.
Allowing the stepper motors to be fully operated with a feedforward controller.
However, they are heavier and more expensive but the additional mass is beneficial as increased inertia of the base.
The extra inertia reduces the displacement which is caused by the reaction force of the \ac{scara} accelerating.
The extra costs are easily compensated as it saves development time due to the simplified control law, and the removed need for extra angle sensors used in feedback control.
The current implementation with DC-motors require a feedback controller that compensates for external forces.
Such feedback control requires a position sensor for each motor.
A simpler solution is to use stepper motors instead.
The advantage of a stepper motor is that it is designed to maintain a specific angle.
The stepper motors make it possible to use a feedforward controller.
This removes the need for a position sensor.
The stepper motors are havier than the DC-motors
However, as the new configuration places the motors on the \ac{cdc}, the additional mass is benificial.
The rapid movement of the \ac{scara} creates a reaction force on the \ac{cdc}.
With a heavier \ac{cdc}, the reaction force results in less movement of the \ac{cdc}

Unfortunately, the stepper motors are more expensive than simple DC-motors.
Nonetheless, the extra costs are easily compensated as it saves development time due to the simplified control law, and the removed need for extra angle sensors used in feedback control.

Due to the aborted implementation of the end-effector, the \ac{scara} must also lift the marker of the board.
With the fourth configuration (\autoref{fig:scaradesign}), it is possible to add an extra joint in the linkage.
As the marker only needs to be moved a couple of millimeters from the board, a simple hobby servo suffices.

\subsubsection{Advanced Detail Design}
\subsubsection{Advanced Detail Implementation}
The design decisions made in the previous sections, make it possible to plan the next steps of adding detail.
The following steps are an addition to the steps as described in the previous section:
The following steps are an addition to the steps as described in \autoref{sec:rdfs}:
\begin{enumerate}
\setcounter{enumi}{4}
\item Stepper motor behavior.
\item Updating physics model to 3D physics.
\item Marker lifting behavior, servo lifts marker of the board.
\item \textbf{Advanced motor behavior:} Stepper motor behavior.
\item \textbf{Advanced physics model:} Updating physics model to 3D physics.
\item \textbf{Advanced marker lifting:} Marker lifting behavior, servo lifts marker of the board.
\end{enumerate}
Starting by replacing the DC-motor with a stepper motor model, which is based on a model by \textcite{karadeniz_modelling_2018}.
The controller is updated as well, to accommodate for the behavior of the steppers.
The next step is to implement a dynamic model of configuration 4 in \autoref{fig:scaradesign}.
The dynamics of the \ac{scara} are based on a serial link structure \autocite{dresscher_modeling_2010}.
The dynamics of the \ac{scara} are based on a serial link structure \autocite{stramigioli_geometry_2001}.
This serial link structure makes it easy to add and extend joints, bodies and mass points to the system.
Therefore, the last detail, the marker lifting, was added without any difficulty.
The servo is connected via a linkage with the marker such that it rotates away from the board.
@@ -143,12 +156,15 @@
At this point the development has reached a detailed design together with a dynamic model representing that design.
The dynamic model is a useful tool to test and evaluate the system behavior.
However, it does not include the shapes of the components and can therefore not be used to evaluate clearance or collision between components.

By implementing the design using CAD software, it is possible to inspect for collisions.
Furthermore, this model is than also used to print the custom parts.
Furthermore, this model is then also used to print the custom parts.
For the mechanical part I used OpenSCAD as CAD software, based on prior experience with the software.
With this it was possible to implement all the custom components as well as the \ac{ots}-components.
Using the inverse kinematics model from the basic design of the \ac{scara}, the angles were directly applied on the components in system.
Allowing me to change the configuration of the \ac{scara} and inspect the clearance between each component.
To inspect how the components moved, the inverse kinematics model is implemented in the CAD drawing as well.
The inverse kinematics made it possible to insert cartesian coordinates, resulting in a dynamic CAD design.
Using different orientations of the end-effector allowed me to inspect the clearance between the different components.

Following the rectangular path as defined in \autoref{test1} revealed that collisions occurred between parts.
These collisions were resolved by adding an indentation in one linkage and moving another linkage.
These changes are shown in \autoref{fig:scad_clearance}
@@ -157,7 +173,7 @@
\centering
\includegraphics[width=0.8\linewidth]{graphics/scad_scara_circles.png}
\caption{
CAD of the \ac{scara} configuration, with the end-effector orientated in the lower left corner of the operating area.
CAD of the \ac{scara} configuration, with the end-effector oriented in the lower left corner of the operating area.
The configuration has been adapted at the two circled points, to resolve collisions in this orientation.
An indentation was made to ensure that the arm can make the required angle.
The bottom linkage was located above the joints as depicted in the fourth configuration in \autoref{fig:scaradesign}.
@@ -180,19 +196,21 @@
Prior to the design, it was possible to plan 4 levels of detail.
After implementing these levels of detail, the design decisions taken made it possible to define additional levels of detail.

In total there are seven predefined levels of detail in the design.
Meaning that there must also be seven test cycles.
However, I noticed that this number was significantly higher.
In total there are seven predefined levels of detail in the design, meaning that there must also be seven test cycles.
However, I noticed that testing occurred more often than seven times.
During the design, running the simulation of the dynamics is easy.
Resulting in extremely short feedback loops, sometimes even minutes.
For example, changing the arm lengths and evaluate the new behavior.
Did it improve? Is this as expected?
Implicitly, the system was very often tested and changed based on test results.

\subsection{Conclusion}
With the development of the \ac{scara} completed.
Following the design plan, the development has to be repeated for the design of the \ac{cdc}.
These small intermediate tests were often implicitly created and are not the tests as specified in the test protocol (\label{app:test_specification}).
Nonetheless, they provide insight that is valuable for the design process.
The interesting question here is whether these small tests should be part of the design process and what it would add to the design process.

\subsection{Conclusion of Development}
At this point, the development of the \ac{scara} is completed.
According to the design plan, the next step for the development is the implementation of the \ac{cdc} feature.
However, the evaluation of the development until this point resulted in enough information to draw conclusions about the design plan.
I expect that executing this development a third time is not beneficial to the case study, given the additional effort.
Time is better spent on the realization of a prototype and improving the current design method.
Time is better spent on the realization of a prototype and evaluating the current design method.
Therefore, the next section goes into the construction of the prototype instead of the development of the \ac{cdc}.

+ 11
- 12
content/case_experiment_specifications.tex Vedi File

@@ -1,25 +1,24 @@
%&tex
\subsection{Specifications}
\subsection{Requirements}
\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.
The next step is to create requirements based on the problem description.
The goal is to write and erase a tweet on the whiteboard.
Originally a tweet had a character limit of 140, but this was doubled to 280\autocite{rosen_tweeting_2017}.
However, the decision is made to keep the limit at 140, as it does not improve the case study but can increase the construction cost.
The text is limited to fifty characters per line, with a total of three lines.
This results in ten extra characters that are used for word wrapping.
For the readability, the distance to a whiteboard in a meeting room is taken as \SI{4}{\meter}.
For the readability, the distance to a whiteboard in a meeting room is taken as four meters.
The operating speed must allow the tweet to be written within three minutes.
Therefore, the goal is to write one character per second.
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:
Using \ac{ears} to define these requirements gives:
\begin{specification}
\begin{enumerate}
\setlength{\itemsep}{10pt}
\input{content/input/speclista.tex}
\end{enumerate}
\end{specification}
Some other specifications that are related to the operation of the system are:
Some other requirements that are related to the operation of the system are:
\begin{specification}
\begin{enumerate}
\setcounter{enumi}{8}
@@ -48,12 +47,12 @@
\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.
Due to the simplicity of the problem description, there were no contradictory requirements, which would complicate the specifications.
The requirements step was performed without problems.
Defining the requirements 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 requirements step.
Furthermore, a single stakeholder takes away any negotiation between stakeholders.
Where the stakeholders are a combination of engineers on the design team and/or the project client.

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.
Although the requirements itself are not difficult to define, ensuring that they are complete is difficult.
Discussion between team members and stakeholders helps 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.

+ 21
- 13
content/case_experiment_test_protocol.tex Vedi File

@@ -3,21 +3,23 @@
\label{sec:test_protocol}
The last step of the preparation phase is to implement a test protocol.
The tests are designed to validate if the system meets its requirements.

While defining the tests, it became clear that part of the requirements was not sufficiently defined.
The current requirements apply to the complete system and is not updated for the design choices made in the initial design.
If the tests are made based on the current requirements, they can only be performed when the complete design is implemented.
To create tests that apply to specific features or compoments, the requirements had to be updated.
This update adds order of operations and additional requirements and is explained in the following two sections.
This update adds order of operations and additional requirements, which are explained in the following two sections.
The third section explains how the tests are formed based on the up-to-date requirements.
%%% Reviewed tot hier.

\subsubsection{Defining the Order of Operation}
There are two modes of operation: writing and erasing.
Defining the order of operation also distributes the responsibility between the different components.
The writing operation consists of performing the following steps:
In these situations, the end-effector holds a writing or erasing tool respectively.
By defining the order of operation for each mode, specific requirements are assigned to the \ac{scara} and the \ac{cdc}.

The current design uses the \ac{scara} to write characters on the board at a static position.
When these characters are written the \ac{cdc} moves to the next position:
\begin{order}{Writing}
\emph{Precondition:} Marker as tool in end-effector.
\emph{Precondition:} Board marker as tool in end-effector.
\begin{enumerate}
\item Move \ac{cdc} to position of characters.
\item Write three characters with the \ac{scara}.
@@ -26,10 +28,11 @@
\end{enumerate}
\end{order}


The second order of operation is about the erasing.
Removing text from the board is done by the following steps:
\begin{order}{Erasing}
\emph{Precondition:} Wiper as tool in end-effector.
\emph{Precondition:} Board eraser as tool in end-effector.
\begin{enumerate}
\item Move \ac{cdc} to position of characters.
\item Clear the area in reach of the \ac{scara}.
@@ -37,13 +40,18 @@
\end{enumerate}
\end{order}

A possible third order of operation can be defined for tool switching.
This order of operation depends on how end-effector grabs and releases the tools.
A possible third order of operation is tool switching using the end-effector.
At this point, the design of the end-effector is not definitive enough to determine an order of operation.
Additionally, not having an order of operation for the end-effector did not hinder the definition of tests.

\subsubsection{Improving Requirements}
Based on the order of operations, the following requirements were added to the lists in \autoref{sec:specifications}:
The defined order of operations add more requirements to the system.
Two of the new requirements specify the operational behavior of the \ac{scara} and \ac{cdc}, based on the order specified above.
To ensure that the overall system can still write one character per second, the \ac{scara} and \ac{cdc} must both complete their task in three seconds.
Therefore, two seconds are assigned to the \ac{scara} to write three characters and the \ac{cdc} gets one second to move the \ac{scara} to the new position.

A fifth requirement is added because it was overlooked during the previous steps.
The five system requirements are in addition to those in \autoref{sec:specifications}:
\begin{specification}
\begin{enumerate}
\setcounter{enumi}{12}
@@ -51,10 +59,10 @@
\end{enumerate}
\end{specification}
These additional requirements take into account that the current design consists of a \ac{scara}, end-effector and \ac{cdc}.
Where each of these components have a different role and thus a different responsibility in the system.
Where each of these components has a different role and thus a different responsibility in the system.

\subsubsection{Setting up the tests}
Using the updated requirements, set of test cases is created.
Based on the updated requirements, a set of test cases is created.
In total there are five small and five large test cases.
The small tests cover a single compoment or feature and the large tests combine multiple features.
Each test specifies for which requirements they apply and include a description that explains the test.
@@ -75,7 +83,7 @@

\subsubsection{Evaluation}
This step was completed without many difficulties.
Which includes the revision of the earlier requirements and definition of orders of operation.
Eventhough this step included an unexpected revision of the earlier requirements and definition of order of operations.
Indicating that I overlooked details while defining the requirements in \autoref{sec:specifications}.
According to the design plan as described in \autoref{chap:analysis}, I have to go back and review those requirements.
Followed by reviewing all steps after the requirements.


+ 5
- 5
content/input/speclistc.tex Vedi File

@@ -1,5 +1,5 @@
\item While writing, the SCARA must 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 three characters at that position.
\item When the SCARA finished writing at their current position, the Cable bot 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 Cable bot shall perform this movement within one second.
\item When the system changes from writing to wiping or vice-versa, the SCARA and End-effector should change the tool within ten seconds.
\item While writing, the \ac{scara} must have a writing speed of at least 1.5 characters per second.
\item When the \ac{cdc} is at a static position, the \ac{scara} must be able to write at least three characters at that position.
\item When the \ac{scara} finished writing at their current position, the \ac{cdc} shall move the \ac{scara} to it's next position where it can write the subsequent characters.
\item When the \ac{scara} has to be moved to a new position, the \ac{cdc} shall perform this movement within one second.
\item When the system changes from writing to erasing or vice-versa, the \ac{scara} and End-effector should change the tool within ten seconds.

+ 1
- 1
content/input/systemtest1.tex Vedi File

@@ -5,7 +5,7 @@
\tcbline
\begin{description}
\item[Features:] SCARA
\item[Specifications:] 3, 7, 11, 13, 14
\item[Requirements:] 3, 7, 11, 13, 14
\item[Results:] The test passes when:
\begin{itemize}
\item Rectangle height is at least \SI{50}{\milli\meter}


+ 1
- 1
content/input/systemtest6.tex Vedi File

@@ -7,7 +7,7 @@
\tcbline
\begin{description}
\item[Features:] SCARA, Cable Bot
\item[Specifications:] 3, 4, 9, 11, (12)
\item[Requirements:] 3, 4, 9, 11, (12)
\item[Results:]
The test passes when:
\begin{itemize}


+ 1
- 1
graphics/design_flow.tex Vedi File

@@ -30,7 +30,7 @@ draw=black!50, thick, font=\footnotesize, fill=white},
\node (ss)[below=1 of tp] {Feature Selection};
\node (a1)[below=0.8 of ss,draw=none, fill=none] {};
\node (rd)[below=0.8 of a1] {Rapid Development};
\node (va)[right=1 of a1] {Variable Approach};
\node (va)[right=1 of a1] {Variable-detail Approach};
\path[->] (pd) edge (sp)
(sp) edge (id)
(id) edge (fs)


+ 1
- 1
graphics/design_flow_analysis.tex Vedi File

@@ -18,7 +18,7 @@ draw=black!50, thick, font=\footnotesize, fill=white},
\node (ss)[below=1 of tp] {Feature Selection};
\node (a1)[below=0.8 of ss,draw=none, fill=none] {};
\node (rd)[below=0.8 of a1] {Rapid Development};
\node (va)[right=1 of a1] {Variable Approach};
\node (va)[right=1 of a1] {Variable-detail Approach};
\node (pp)[above=0.8 of pd,draw=none,fill=none] {Preparation Phase};
\node (dc)[below=1.6 of va,draw=none,fill=none] {Development Cycle};
\path[->] (pd) edge (sp)


+ 1
- 1
graphics/electronics.tex Vedi File

@@ -11,7 +11,7 @@ draw=black!50, thick, font=\footnotesize, fill=white},
\node (mc) {Micro Controller};
\node (ha)[left=0.5 of mc,draw=none,fill=none]{};
\node (hb)[right=0.5 of mc,draw=none,fill=none]{};
\node (sc)[below=1 of hb] {Stepper Controller};
\node (sc)[below=1 of hb] {Hardware Stepper Driver};
\node (sm)[below=1 of sc] {Stepper Motor};
\node (sv)[below=1 of ha] {Servo Motor};
\path[->] (mc) edge (sc)


+ 1
- 1
include

@@ -1 +1 @@
Subproject commit 100951d197953549c8fa1d3d143b4e714c4525df
Subproject commit 5704aebb08b0f65f0d389aa82d29a891c71c2aae

Write Preview
Loading…
Annulla
Salva