## 13 Comments on the Buildlog.net Forum

A couple people have been using my slider design, but wanted a simple controller. I made a simple Arduino program that can control a stepper motor. It allows you to program speed and acceleration for each move. You can even store a 2 dozen line move program in EEPROM to later activate in the field. There is a cheesy video showing it in use. View the video in hi res and full screw if you want to be able to read the Arduino Menu.

The code (linked in post) might also be a starting point for other simple motor control applications on the Arduino.

It uses a timer interrupt to keep the motion very smooth and reliable.

http://www.buildlog.net/blog/2011/12/ma ... l-program/

I'm really very impressed by this. The demo video looks very professional.

Any thoughts about rotating the camera as it goes down the slide in order to keep it centered on an object of interest? Basically interpolating PositionA/AngleA to PositionB/AngleB.

**Edit - The arduino coding part doesn't worry me (particularly) and I have experience with serial/USB interface programming (Mac), but I'm not confident to make the hardware for the above.

Even without rotation, I'm wanting do experiments with this doing some product shot videography. Going see if I can get my employer to these toys for me

The way I wrote the Arduino program, it is more than capable of coordinating several several items at once. For example it could coordinate the moving carriage, a rotating camera and a time lapse shot interval.

The program is written for the most basic Arduino using the stock Arduino libraries and IDE. Therefore, it only uses one simple Timer interrupt and does all the complex setup before each move. This means the coordination has to be somewhat linear. The camera could rotate in coordination with the move like ... while moving 4 feet forward, rotate 30 degrees.

In Theory: You will probably find in some situations that does not get you exactly what you need. If you want to aim directly at an item while driving in a straight line, you will find that the rotation speed needs to be greater the closer you are to the object. The graph of the required speed vs time would like like a polynomial curve. The effect may be subtle and the slight drift of the object in the frame may not be objectionable.

It is all solvable, especially if you use a stronger Arduino like a Mega with more timers, but you would also need a simple CAM program to plug in the geometry and determine the curve to follow.

I would probably use a hobby serve to do the camera rotation.

Thank you for you reply. You made me think for a few minutes about how the angle isn't a straight interpolation.

Though I'm wondering if a computer is really necessary for any of it.

I checked the Arduino reference manual, and I see sin/cos/tan functions, which gives me what I need to solve a triangle given an elementary Angle Side Angle problem. If I slide down the rail a ways, the problem (find the new angle pointing at the object) switches to a Side Angle Side problem.

I'm imagining a user interface to set position A (X1 and Angle1) with a button, use another button or two to slide left/right to run it down the rail and set position B. During runtime, for each increment from X1 to X2 it would do one equation to get a new angle to our fixed point (knowing the distance X it's traveled - thus the SAS problem). I wonder if the hardware is fast enough, I wonder about how I'd input a time from A to B, and this pretty much means that you always let it set the positions (Setting A or B by hand wouldn't work).

This seemingly would work even if you wanted to pan between two objects as you slide down a rail. The controller wouldn't care that the two objects were apart from each other - the triangle it would make would have a point half way between them and closer to the rail (well, at least closer than the farthest of the two points).

I suggested the PC because I did not know a good way for a menu driven interface to work for entering all the geometry, but your post makes me wonder if it could be done interactively.

Jog the slider to the start point, aim the camera and tell the Ardunio the start point is set. Do the same for the end point. You have two angles and a distance, which should be enough explain the geometry. The question is, can the calculation be done faster than whatever your timer rate is. Those trig functions take a lot of cycles.

If you use two timers on a larger Arduino that might help. The required frequency update on the angle would many orders of magnitude less than the step frequency. You may even be able to do the calculations in the main loop in the 'background' to be ready when it is time to move.

I have the timer running at 40kHz now, but it actually run fine at 25KHz, but with a little less top speed. The true applications are probably at lower speeds anyway.

I really liked this project when I saw it too. It's one of the things I'd like to do as soon as the extrusion can be purchased. (I only wish I could have been in on the kickstarter project).

Anyway, you're correct that linear interpolation wouldn't suffice as the rotational velocity is non-linear. The first thing that came to my mind was to use spline interpolation. And that's what most CAM program's calculations are based on anyway, only your right in that it'd be interactive and you'd get to experiment until you got it good enough. But with a little spline math you could simply code an algorithm that takes as it's inputs the distance to travel and the distance to the object. From that you'd generate a spline representing your non-linear rotational velocities. The advantage of this approach would be that the rotational velocities could be pre-calculated into a lookup table, freeing up plenty of cycles when you're in motion. You'd just step through the table as you travel.

However, while writing this I just realized a much simpler approach. We've already solved this calculation in computer graphics. If you have enough cycles to to calculate as you travel, simply use a 2d lookAt function. =)

I'm pretty sure the Arduino doesn't have the horsepower to do any trig calculations at 40kHz. However it should be possible to cheat a bunch by using an iterative version of the function, since we know the change between calculations is minimal. There's a great article about atan2() implementations on ARM hardware (Nintendo Gameboy) here, which I found searching for the CORDIC version I wrote years ago when I was playing with DS homebrew.

I took the Slider to the Chicago hackerspace (Pumping Station 1). Several good Arduino programmers gathered around and we brainstormed ideas for rotational control. I think the general consensus was that it was doable.

Realistically hobby servos have 8 to 10 bits of resolution. If you use the full range of the servo on a run, you only have to calculate the angle about 1000 times across the whole run. The idea was to calculate the next angle and at what distance to use the new angle in the main loop and have the results ready for when it is needed in the interrupt function. The interrupt would only need watch for the next angle point and implement the angle.

The real work is now designing a rotation platform for the camera. I don't have time for that right now. I may just stick a servo down with a big plastic arrow on it just to prove the concept.

The way the gigapan works, which might be a good way to follow, is to aim the camera to where you want it to start via the arrow buttons. This drives the built-in servos/motors to aim the camera. Then you hit next and aim the camera via the arrows to the last frame and store that. It then calculates the amount of photos needed and the overlap based on a previous setting.

I could image having a small display on the arduino with some buttons. You move the head on the slider and aim the camera using the arduino driving the motors and hit "start" then move the camera to the end position and hit "end". Then the arduino could figure out the tweening positions and move through them smoothly for a video shoot or with intervals and trigger the shutter for a time-lapse. You would probably want to add a speed setting or an delay setting between shots or maybe a "time to complete motion" to have it calculate the interval time.

To me this seems like a really simple solution that could be adapted for a lot of different rigs, cameras and end results.

The only other type of calculation that might be wanted is a ramp-in ramp-out where you could ease into the motion and out. Maybe that could just be an onscreen value you could change.

BTW there are lots of Pan/tilt units already worked out at ServoCity. http://www.servocity.com/html/pan_tilt_ ... ories.html

And for a camera trigger with intervalometer there is this that might come in handy. I have one but haven't had time to play with it yet.
http://www.dpcav.com/xcart/product.php? ... 253&page=1

Both of these above use standard RC servos which means they will work fine with the arduino too.

cheers
-david

Only issue I would see with doing a single start and end point for rotation is it can then only interpolate a linear rotation. The object will not remain in the exact same location through the travel, especially if the track is close to the object. You would have to have at least three aiming points in the setup.

With two aiming points you describe the whole triangle to the controller. It can figure out each new aiming point on its own. It is not linear, but solvable in real time. Half the math is done once, and the other is done on the fly as you go. Realistically the angle is changing rather slowly compared to the linear motion of the carriage.

I know someone is going to throw real time tilt into the mix now. That adds a whole new level of complexity, but again, probably doable.

If there's enough memory, look up tables can be produced before the motion starts and are really fast.

A third or forth order polynomial (spline) could be fit for each axis and would probably work for each move segment. The math to do the fit is more intensive, but it scales nicely for many axes and is much faster than trig functions.

Also, the standard trig functions usually compute to the precision of the machine, which is way overkill for some applications. I implemented sin and cos functions using taylor series to a few terms and it was plenty fast for that project (http://www.me.gatech.edu/me6405/Projects/Fall03/Group1/index.html). That was on an old HC11 with a 2 MHz clock, the arduino should have no problem with it.

Just curious if anyone has modified Bart's program for an EasyDriver? If someone has I can save myself some time before I start comparing the available pins to the code (and since this is my first Arduino project, it may take some time).
http://www.schmalzhaus.com/EasyDriver/