%&tex
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 has been written in software.

\subsection{Mechanical Construction}
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 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 \ac{scara} slightly further on the axle.
Resulting in an operating \ac{scara} without having to redesign the mechanics.

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

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}
    \caption{Simplified data flow in the software. The path planning generates a vector to the next set point. The interpolation reduces the length of this vector. With the inverse kinematics the required stepper motor angles are generated. These angles are set as new set point for the stepper driver.}
    \label{fig:objects}
\end{marginfigure}

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

\input{content/case_evaluation_result.tex}

