## Motor calibration

### Quote

Here is a little manual describing how to find the correct motor calibration value for your setup – the mathematical and most precise way. This can now also be found in the documentation:

The miniEngine 2 offers the possibility to calibrate the motors you are using. This calibration takes the motor and its specifications itself as well as the rig it is driving into account. This chapter is aiming at helping you finding the correct calibration value for your motor(s). The calibration values needed, should be given with the following units:

• steps per centimeter for linear movements
• steps per degree for radial movements

As stepper motors come in a variety of form factors and specifications we need to add the most important of these specs to our calibrations. This is the degrees been moved by one full motor step. The most common one is 1.8°. This means that such a motor needs 200 full steps to do one full revelation:

$\frac{360^{\circ}}{1.8^{\circ}} = 200$

Because we are using multi-stepping to achieve a finer resolution, we need to multiply this full-step-value with the amount of sub-steps done. In this example we are using 1/16th stepping (which is the default for the recommended Big Easydriver):

$200{\times}16 = 3200$

..or if you prefer the full version

$\frac{200}{(\frac{1}{16})} = 3200$

Ok – so we need 3200 steps to do a full revelation with the stepper motor in micro- stepping-mode. Now let‘s add the rig that this motor is driving to the calculation. For now we are assuming we are driving a toothed belt with the stepper. The gearwheel has a circumference of 3.5cm. This means that 1 stepper revelation moves the belt 3.5cm. Here is how we get how much steps are needed for 1cm – which is also our final calibration value:

$\frac{1cm}{3.5cm}\times{3200}=914.29$

Now we can enter 914.29 steps / cm as the calibration value into the system.

If we had a motor that would do a radial move, the calibration-calculation would just differ in the last step. Assuming you are not using the motor to rotate your axis 1:1 but with a reduction of 1:4 (four revelations of the motor rotate the axis one time) , the final calculation-step would look like this:

$4\times\frac{3200}{360}=35.56$

The final calibration value for the radial setup is 35.56 steps / degree.

I hope someone finds this useful.

Have fun!
Airic

# Software update to 2.0.3

Thank you all for submitting feedback and bugs! This allowed me to improve the software and here it is: alpha version 2.0.3! This release fixes some bugs and even adds some new stuff. I highly recommend updating to this release (Don’t forget to update the libraries too)! These are the changes:

Documentation
•  updated the documentation (added small system-user-manual)
Software
•  fixed a bug which started moves from the wrong position if not moved to home before
• fixed a bug that moved the motor in the wrong direction when using the function “Move home (all)”
• fixed a bug which caused the motor direction to change sporadically during motor jogging
• added a new menu font and a font-option to the settings
• Minor user interface changes
• added all needed libraries into the repository

The biggest change, which you will see immediately, is the new font. I thought it might be nice to have a more readable and clear option. There is a new option for choosing the font so that you can go back to the old one if you like:

I also started working on a Windows client for creating keyframe-based moves. This is in the very early stages but I hope to be able to release it before the summer. Main focus will be defining the bezier-curve based moves and then either save them as a files or directly submit the data to the USB-connected miniEngine.

…and as always – Have fun!
Airic

# Shades – a time-lapse movie

Hello everyone,

I finally got enough clips for a 4min time-lapse video. I spent the last 1 ½ years on refining my equipment and shooting some clips when possible. Here is the result:

It was shot using the miniEngine – bot with motion control as well as simply on a tripod. All 3 existing version were used.

For those with some interest how my time-lapse workflow looks like – it includes the following tools:

• Adobe Lightroom for the development of the single RAW pictures / video frames
• LRTimelapse for de-flickering
• Quicktime Pro for combining the frames to video-clips
• Final Cut Pro for the video cut

Surely this is just one of many, many possible workflows but this is how I do it.

I hope you enjoy it!
Cheers,
Airic

# Documentation graphics

Hello everyone,

here is one of the graphics, I created for the documentation that I am currently writing. I thought some of you might find that interesting.

[Click me for full resolution view]

I’m planning to open the shop this Sunday (2013-12-15).

Cheers,
Airic

# miniE v2 update 4.1

Hello everyone,

this is just a quick update on the Bezier-motor-control engine. I worked the last days pretty much all of my free time on the new “core” system and can say that it is more or less done. I now can define moves based one Bézier curves – or in other words by defining 4 points (2-dimensional: time; position) per curve. The engine is then processing the data to a list of linear segments (based on linear functions). So every curve becomes 200 linear segments. To get a smooth move, I developed an algorithm, that uses a finer granularity where the curve bends the most. In the picture below you can see the segmentation (in this case 100 segments):

Every motor-movement in the next version will be based on this new methodology as it allows detailed planning of the motors position in time. I even allows to get information about the speed of the motors at any time. On top of that is the motor movement much smoother as it was with the old delay-based engine. It also allows much greater speeds. I was able to move my dolly along my 100 cm (4 foot) track (this one) in 6 seconds with nice speed-ramping on both sides.

Because the DUE is fast enough and the motor position calculation is based on an easy linear function, there should be plenty of processing power for doing all this for 2 motors simultaneously. Right now there are approx. 0.05 motors steps done per processing loop. This means that the DUE only needs to step the motor every 20 processing loops. [Edit: Running 2 different curves with 2 motors simultaneously is tested and working perfectly.]

The only drawback is that this new control-methodology is making extensive use of the 96kb RAM that that the Arduino DUE has to offer. One of the curves with its 200 linear sub-segments is taking 2400 bytes of RAM. That means that in theory 40 of these curves can be stored in the DUE’s memory. Because the systems itself needs some of the memory too, lets say that 20-25 curves can be stored. I think that this is a good amount to design some pretty complex video-moves. Here is another example of how such a move can look like:

It consists of 3 curves and here is the actual source-code to define such a move by hand:

// x coordinate = time in ms
// y coordinate = motor position in cm
curve[0].p0 = Point( 0, 0);
curve[0].p1 = Point( 6000, 0);
curve[0].p2 = Point( 10000, 50);
curve[0].p3 = Point( 20000, 50);

curve[1].p0 = Point( 20000, 50);
curve[1].p1 = Point( 30000, 50);
curve[1].p2 = Point( 31000, 35);
curve[1].p3 = Point( 40000, 35);

curve[2].p0 = Point( 40000, 35);
curve[2].p1 = Point( 51000, 35);
curve[2].p2 = Point( 51000, 100);
curve[2].p3 = Point( 70000, 100);


The cool thing is that I can read the motor position for any time I want. This will end up in a feature to kind of fast preview the programmed move – for example with 16x speed.

I guess I need a good user interface for editing these curves on the system now!

Cheers,
Airic