|
- %&tex
- As the previous development cycle was aborted prematurely, the development cycle is repeated for the next feature.
- Starting with a feature selection process. Followed by the rapid development.
-
-
- \subsection{Feature Selection}
- 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 \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}[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}
- \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}
-
- \subsubsection{Evaluation}
- 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 \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.
- The basic design principle is based on the initial design as shown in \autoref{fig:combined}.
- 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 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 \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 an elaborate model:
- \begin{itemize}
- \item Improved motor model
- \item 3D physics model
- \end{itemize}
- 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 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}
- 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.
- Based on the model after those steps, it is possible to make more detailed design decisions.
- The decisions make it possible to plan the subsequent levels of detail.
- Implementing these details results in a competent model.
-
- \subsubsection{Basic Design Implementation}
- \begin{marginfigure}
- \centering
- \includegraphics[width=0.9\linewidth]{graphics/scara_arm_kinematics.pdf}
- \caption{Basic kinematics of the \ac{scara}. The arm consists of two linkages $a$ and $b$; two joints $\alpha$ and $\beta$; and a point mass $m$ which represents the end-effector/tool.}
- \label{fig:scaraarm}
- \end{marginfigure}
- The development starts with the basic model shown in \autoref{fig:scaraarm}.
- The model consists of the forward and inverse kinematics of the design.
- With this kinematics model it was easy to find a suitable configuration of the \ac{scara}.
- 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 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 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}.
-
- \subsubsection{Detailed design decisions}
- The basic model gave some valuable insight about the dynamic behavior of the system.
- 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 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}.
- \begin{figure}
- \centering
- \includegraphics[width=0.875\linewidth]{graphics/scara_design.pdf}
- \caption{Four different \ac{scara} configurations. The colored circles mark which of the joints are actuated. Configuration 3 has two independently actuated joints on the same position.}
- \label{fig:scaradesign}
- \end{figure}
-
- 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 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 \autoref{sec:rdfs}:
- \begin{enumerate}
- \setcounter{enumi}{4}
- \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{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.
-
- \subsubsection{Component Design}
- 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 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.
- 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}
- The complete setup with the custom parts and the \ac{ots}-components, such as stepper motors, servo and marker, is shown in \autoref{fig:scad_carriage}.
- \begin{figure}
- \centering
- \includegraphics[width=0.8\linewidth]{graphics/scad_scara_circles.png}
- \caption{
- 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}.
- This was moved to below the actuated joints as it did collide with the end-effector.
- }
- \label{fig:scad_clearance}
- \end{figure}
-
- \begin{figure}
- \centering
- \includegraphics[width=0.8\linewidth]{graphics/scad_carriage.png}
- \caption{Rendered 3D model of the \ac{scara}, including steppers, marker and servo.}
- \label{fig:scad_carriage}
- \end{figure}
-
- \subsubsection{Evaluation}
- The complete development was rather smooth.
- However, this was not without deviating from the original design plan.
- It was not feasible to define all different levels of detail before the start of the development.
- 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 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?
-
- 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 evaluating the current design method.
- Therefore, the next section goes into the construction of the prototype instead of the development of the \ac{cdc}.
|
