JRobot

Waiting for my AVRcam and wondering what all that code is about.
I have been asked to produce - one-of plus a spare...
... build a line follower to keep another detector over a 200 foot weld as a pipe rolls down a testing jig. I would imagine the sideways velocity of the line will never be very significant and will tend to twist in the same direction (this is a straight weld but the pipe is not prevented from rolling around it's axis). I do not, yet, know how I will be interfacing with somebody else's axial-rotating assembly. I want to leave myself open to a left/none/right signal (perhaps thru the rs232) or some PWM. I am a hardware guy with PIC, robot and R/C experience not adept in soft things.
Are there any outputs left over on the AVR board? Anybody like to suggest any options?
My CMUcam seems to slam the servo hard to one side or the other instead of jittering closer as I move the target.

As I had mentioned before, my first "real-world" test of the AVRcam was to strap it on to my EyeBo robot, and enter it into the Chibots line-following contest. You can find some details here:

http://www.jrobot.net/Projects/EyeBo.html

It worked very well, and yes, a chunk of the time DEFINITELY needs to be allocated to working on the control algorithm to follow the line (just using a bang-bang control system often results in continual oscillation around the line instead of following it nice and tight. I have found that the slew-rate at which you allow your steering to adjust relative to how far from "center" the line appears to be is a critical component that I had overlooked in the past).

Now my login should show. I am expecting my line to have poor contrast - grayongray. I'll need to do some auto exposure and enhancment I presume.

One other point to note: The AVRcam, by its very nature, is an experimental system that doesn't provide any sort of warranty or fitness for any particular purpose. It was intended for the hobbyist/experimenter to use or build upon for their own projects. Its not to say that one couldn't take the system and put it through more rigorous testing to ensure that it would fit a particular application, but that onus is on the end-user (and again, not warrantied by JROBOT in any way shape or form).

With that said, good luck applying it to your problem...

I assembled my new toy today. Well done on the instructions. Everything went as advertised an I am up and tracking a yellow card. I do lock up often but it goes away when I kill the window and restart. A wonky rs232 perhaps?
I still have to choose between a linear array and a low res camera for tracking a center. Then I'll look at better reliability parts. My Fundamental reason for buying the AVRcam is - I can't modify stuff if I don't know how it works. Source code makes that possible. Thanks and merry christmas

I do lock up often but it goes away when I kill the window and restart. A wonky rs232 perhaps?

Is the lockup occuring while tracking, or while dumping an image? I don't think I've ever seen it lockup while tracking...only when dumping lots of dumps.

One other interesting thing to note: I was playing with the system more this past weekend, trying to get to the root cause of the occasional lockup. I found that one mega8 was MUCH more succeptible to locking up (i.e., one mega8 seemed to take 40 frame dumps in a row without locking up, with tracking sessions intermixed and I flat-out could not get it to lock up...another mega8 seemed to only make it about 10 or 15 frame dumps before it locked up...this was consistent). I am starting to wonder if overclocking the system to 17.7 MHz is a problem here. I can't wait to get my hands on the mega88 PDIP version, which should be a drop-in replacement for the mega8 (with slight tweaks here and there) and good up to 20 MHz.

excellent points. I was looking at mulitiple dumps and it tended to choke after 3. Sometimes on the left frame but more often I would not get a right frame. Tracking seems fine so far.
I'm glad it worked yesterday! Today I can barely get one frame.
ten tries yielded two functional sets of images. Two died at Frame Data(22) and two more at (7). The rest were one image but not both.
I can see I'll need a watchdog to reboot every so often to be sure in the field.

Is there any reason not to remove the camera xtal and put either a 16MHz xtal or an external 16 MHz clock and re-do the baud rate timer?.
If we don't have a PAL or NTSC output anyway does anybody care what the precise clock rate is since the AVR is on the same clock?

Today I can barely get one frame.
ten tries yielded two functional sets of images. Two died at Frame Data(22) and two more at (7).

This seems really bizarre to me. I don't think I have ever seen the frame dumps cause an issue after only a few dumps....especially not at a rate of 2 successes in 10 tries (and I assume you mean a power-cycle between tries here). I'd be able to better diagnose what is going on if I had a board in front of me that was exhibiting this behavior. Maybe I can send you one of my assembled ones and you could send me this one that seems to be flaky...I'll contact you off the list tonight...

Is there any reason not to remove the camera xtal and put either a 16MHz xtal or an external 16 MHz clock and re-do the baud rate timer?.

There is no issue in doing this, other than the baud-rate re-calculation as you mentioned. The original version of the system actually piped a 16 MHz crystal hooked up to the mega8 over to the OV6620, and this seemed to work fine. The only annoying thing here is that it requires the user to unsolder the crystal on the camera. Maybe I'll play with this some more tonight to see if it makes a difference.

It would appear to be my fault as usual (ask my wife). MY USB to serial adapter doesn't like the AVRcam. I tried direct to com1 and dumped 60 frames interspersed with ping and track commands, even register set commands - no lockups at all. I closed and reopened the program and dumped 3, jammed, restarted and dumped 60 more, all OK.
When it did lockup I had to restart the AVRcam. AVRCamView timed out on 'ping'.