With the preparation phase completed, the development cycle is next. 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 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 in the design, this attempted implementation did provide valuable insight in the desing process. \subsection{Feature Selection} \label{sec:case_feature_selection_1} 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} \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} 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} 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 deemed insignificant. The testing number is directly the number of tests that apply to that feature. 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 \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 \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} \label{sec:case_development_cycle_1} This section explains the process of the development of the end-effector. 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 \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. \subsubsection{Initial design} 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}. \begin{figure*} \centering \includegraphics[width=151mm]{graphics/end-effector.pdf} \caption{Operation of the end-effector. The clamp is forced open against the holder to release the marker. Instead of releasing, the marker is grabbed by reversing the order of executing for these steps.} \label{fig:gripper} \end{figure*} \subsubsection{Behavior Modelling} The next step is to implement this design with the corresponding behavior in a dynamic model. The challenge in this case is the modelling of the contact dynamics. 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. 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 \ac{cof} per time analysis. This early failure resulted in changes for other components. But as none of the other components are implemented yet, no work is lost.