|
|
|
@@ -1,14 +1,38 @@ |
|
|
|
To ensure that the design method resulted in a functional system, a prototype will be build from the current state of the design. |
|
|
|
Although the development resulted in only a partial design, I determined that a prototype is more valuable than repeating the development cycle for the next feature. |
|
|
|
For the construction of the prototype \ac{ots}-parts are used as much as possible and the mechanical linkages of the SCARA will be printed. |
|
|
|
To write characters on a whiteboard; drivers and controlloop are implemented in software. |
|
|
|
|
|
|
|
%&tex |
|
|
|
To validate the dynamical and mechanical models, I will 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. |
|
|
|
|
|
|
|
\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. |
|
|
|
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. |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
\subsection{Control of the SCARA} |
|
|
|
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. |
|
|
|
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 Control/Path planning |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
\subsection{Implementing Behavior} |
|
|
|
Now with a physical SCARA, the last step is to implement the behavior. |
|
|
|
The stepper motors are powered via a stepper controller. |
|
|
|
The path planning for the SCARA and the operation of the stepper controller is implemented on a \ac{mcu}. |
|
|
|
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 duty cycle of a \SI{50}{\hertz} PWM signal. |
|
|
|
The PWM signal generation is offloaded to the IO peripherals and the software driver has a toggle function to lift the marker from the board. |
|
|
|
Most of the code for the software driver was already available as a module in RIOT-OS. |
|
|
|
|
