|
|
|
@@ -19,20 +19,53 @@ Fortunately there was enough clearance to mount the SCARA slightly further on th |
|
|
|
Resulting in an operating SCARA without having to redesign the mechanics. |
|
|
|
|
|
|
|
\subsection{Control of the SCARA} |
|
|
|
\begin{marginfigure} |
|
|
|
\centering |
|
|
|
\includegraphics[width=5cm]{graphics/electronics.pdf} |
|
|
|
\caption{Hardware connections. The servo motor connected to a pwm-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} |
|
|
|
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. |
|
|
|
The servo motor is directly connected to the IO of the \ac{mcu} while the stepper motor is connected via a stepper controller board, see \autoref{fig:signals}. |
|
|
|
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 Inverse Kinematics |
|
|
|
\item Control/Path planning |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
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. |
|
|
|
The angle of the servo motor is controlled by the pulse length of a square wave. |
|
|
|
This signal is generated in the IO peripherals as a PWM signal. |
|
|
|
The software driver has a toggle function that changes the pulse length. Making the maker lift from or lower on the board. |
|
|
|
The code for the servo driver was already available as a module in RIOT-OS. |
|
|
|
\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} |
|
|
|
|
|
|
|
The path planning is able to write three characters with the SCARA. |
|
|
|
The font for the characters is made by \textcite{hudson_asteroids_2015}. |
|
|
|
This font consists of a simple coordinates for characters and is written in C. |
|
|
|
The path planning is updated with a fixed interval. |
|
|
|
During the update, the set point is linearly interpolated, otherwise the lines are curved between set points. |
|
|
|
To get the angle set points for the stepper motors, the $x,y$-coordinate set point is converted using the inverse kinematics. |
|
|
|
The inverse kinematics is analogous to the model that is used in the development cycle of the SCARA. |
|
|
|
The angle set points are updated for the stepper driver. |
|
|
|
The data path is shown in \autoref{fig:objects}. |
|
|
|
|
|
|
|
The stepper driver has a feedforward controller. |
|
|
|
The driver limits the acceleration and speed to keep the motor within operating specifications and keeps track of the current status of the stepper motor. |
|
|
|
When the angle set point is updated, the driver calculates the time interval between each step and sets a hardware timer to that interval. |
|
|
|
This allows the controller and other drivers to be executed between each step. |
|
|
|
This approach works only if the code executes fast enough. |
|
|
|
During the testing, I found that the inverse kinematics calculation was too expensive, even with the integrated floating point unit. |
|
|
|
As the \ac{mcu} has sufficient flash storage available, the inverse kinematics calculation is replaced by a lookup table. |
|
|
|
|
