Time-Lapse Automaton

Forum 2005-2010 (read only) General Exhibition
1

So, my first arduino project, erm, well, my first robotics project of any sort ;D just had to be a complicated one... Hehe, I even had to build myself a little workshop to deal with the metal, cutting, filing, drilling, etc.

But, it's coming a long, far enough to show you guys some progress now.

Here's the concept:

Automate time-lapse motion. Easy enough, eh? Well, I could've just bought one of those cheap telescope heads, but they only offer pan/tilt, and they tend to only move in ratios related to the rotation of the earth - not the kind of control I wanted. I wanted to add at least one more axis of motion (lateral/trucking), and will most likely add a 4th (rotate the lateral motion track) when done (I have one PWM pin left free =). Additionally, I wanted it to be highly controllable (field-programmable, multiple stored programs), and capable of going extremely slow speeds -- it currently can truck at a rate as slow as 0.01 inch/minute, and pan at a rate as slow as 1 degree every nine hours.

It doesn't yet work as an intervalometer, as I have one of those already, and would need to add another arduino to handle that function (which I will later). The tilt servo will come later, running low on cash right now =)

I've been doing blog posts about it, with videos here: http://roamingdrone.wordpress.com

In addition to the arduino, it has:

Sparkfun keypad
16x2 LCD screen
L298 Motor controller
Home-made 12v->6v converter
Dayton gear motor
Servo City pan servo kit
... and a bunch of metal/acrylic =)

A little deviation from the videos due to some work since the last video was posted: I cannot print the current track position status, as the delays in writing to the LCD cause jitter in the servo. If anyone has any suggestions as to how to overcome the delay when printing to the LCD (with LCD4bit), I'd be greatly appreciated.

Once I get everything working properly and smoothly, I will set up a web page and share the code, schematics, etc.

Any feedback would be greatly appreciated!

!c

2

That's a really nice project!

I had a similar problem with an LCD interfering with servos and found two solutions that worked for me.

The first is to use uses Peter Fleury's LCD library here:
http://homepage.hispeed.ch/peterfleury/lcdlibrary.zip

It is many times faster than any of the Arduino lcd code in the playground. It uses and direct port i/o and the RW line to minimize delays. You need to map arduino pin numbers to the ATmega port values in the h file, but this is easy to using information here: Arduino Reference - Arduino Reference
And here: Arduino Playground - PortManipulation

The other method if you have a second arduino is to send the data using i2c. I can share the code I use for this if you want. I considered using a serial LCD but the arduino i2c solution was much cheaper and more flexible

3

Thanks mem - I'll check out that LCD library. I'm definitely going to use a second arduino for the motor control now, as I need more pins than I did before, I'm happy to look at the i2c, but I have to ask - other than the issues with blocking, why would i2c be better than serial communication between the two?

Thanks,
!c

4

i2c is capable of transferring data at a higher rate and leaves the asynchronous serial port available for uploading sketches and/or debugging. But if that doesn't matter for your application then no reason not to use async serial.

The disadvantage of i2c is that it needs two pins (plus ground) even if the communication is one way, and the i2c pins must be analog pins 4 and 5, so thats two less analog inputs available.

5

i2c is capable of transferring data at a higher rate and leaves the asynchronous serial port available for uploading sketches and/or debugging. But if that doesn't matter for your application then no reason not to use async serial.

The disadvantage of i2c is that it needs two pins (plus ground) even if the communication is one way, and the i2c pins must be analog pins 4 and 5, so thats two less analog inputs available.

Ah, cool, the ability to send a large amount of data quickly is a bonus, as once I'm done w/ all the basic stuff, I'm intending to do a computer-interface that allows me to upload the program as a series of points in 3d-space (e.g. move to here, stop, wait until the other motor is in this position, and start again at this speed until this point, etc.). The number of pins is fine, as I was thinking of using some dedicated pins already to trigger certain motor actions (e.g. the IO/UI controller can start the program on the motor controller by bring pin 5 high, rather than sending some fairly complex command that needs to be deciphered.)

Especially since that would leave my serial interface free on the UI controller to upload programming sequences while communicating w/ the motor controller, I see the value in this now.

I'd like the code, if you could share it.

Thanks,
!c

6

I just had a look at the code and think it's more complicated than you need. It consists of the following modules

A library called ioMessage that provides an abstraction layer allowing tagged message packets to be sent and received.

A collection of stubs to be included in the sender sketch, the ones for the lcd match the fluery library and are as follows:
void lcd_init();
void lcd_putc(const byte c);
void lcd_puts(const char * string);
void lcd_clrscr();
void lcd_gotoxy(byte column, byte row);

The receive sketch uses case statements to decode the received messages and calls the appropriate LCD functions in the fluery library.

The stuff is not richly documented and my sketches pass much more information to the slave arduino than just lcd messages so it's a little complicated than you need. But if it sounds useful I will try to create a version without the non LCD code over the weekend and send it to you.

Oh, I almost forgot. The code uses a patch to the wire library that will be added to the next arduino release but you will need to make the change to wire.cpp on your machine if running version 0011 or earlier.

If you PM me your email address I can send you the code as is if your feeling adventurous

7

Ok, time for an update - the stage 1 prototype is done, and fully functional. I have some new photos of the rig at my blog (http://roamingdrone.wordpress.com ) but here's a little snapshot:

Over the next few days, I'll be describing the software and capabilities in detail, but it's been entirely re-designed (andm I mean, everything!) since my last post. It now uses stepper motors, two arduinos (one for motor/camera/etc. control, and one for UI/ program planning) that communicate via i2c, and allows for almost any speed motion at any camera fire rate (e.g. panning a total of 1/2 degree over fourteen days and a thousand shots, moving 1' laterally over an hour and 3600 shots, etc.) and guarantees to never move a motor while the shutter is open, and blurring the photo. It also does best case intervalometer timing even when requested motion goes beyond intervalometer time. e.g.: if it's programmed to take a shot every half second, and movement takes 501 ms, the camera shot time occurs at ~ 501 ms (vs. motor control time + delay time == 1001 ms, which pure delay()-oriented timing would provide.).

Any feedback is always appreciated.

!c