Previous posts

Post 1 - Introduction

Post 2 - Installing OpenCV - Prerequisites

Post 3 - Installing OpenCV

Post 4 - Installing Pygaze

Post 5 - Installing eye tracker

Post 6 - SPI communication

# Post 7 - SPI communication in Python

EyePrints - Post 8 - Getting started with Kinetis

It’s now time to think a bit in more in detail about the mechanical part of this project

First of all, the Kinetis Motor Suite can generate a motor control application with three different control algorithms

1. Sensored position
2. Sensorless speed
3. Sensored speed

So there are plenty of options to choose from…

I don’t know exactly the kind of motor provided with the FRDM-KV-LVPMSM board, but, just to stay on the safe side, let’s assume that the motor is sensorless. This leads to an obvious choice: the control algorithm will control the speed of a sensorless motor

That said, the overall mechanical design is as follow

There are two threaded rods that will be driven by the BLDC motors. Threaded rod’s rotation will make a bolt move up and down. The bolt will have a string tied that will move the plotter on the drawing board. The idea of the threaded rod is just a “trick” to keep cost down: it replaces a gear box at the cost of a bigger structure layout. However, it also have one advantage. All the polargraph projects (this is the name of the drawing machine I’m building) suffer of a major problem. They have a wheel where the string is winded and unwinded. But the string slips over the wheel, thus reducing precision. From a mechanical point of view, my solution should be more precise.

The equation to determine the position the cursors have to move to in order to place the plotter at a given (x, y) location, is shown in figure below

Basically, we have two equations with two unknown values (the position of the two cursors) that have to be solved.

From here, I can either determine the time needed to move the cursor when the position and RPMs are given, or the RPMs required to move the cursor when the position and the time are given. My idea is that the Raspberry Pi will send out updated coordinates at a fixed rate, so the best option is to keep the time constant (and equal to the coordinates update rate) and determine the RPMs as a consequence.