With the preparation phase completed, the development cycle is next.
This consists of three steps: Feature selection, Rapid Development and Variable 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.
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.

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

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

        \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.
            This early failure resulted in changes for other components.
            But as none of the components were implemented yet, no work was lost.
