slow line follower

This forum is used for discussing hardware, software, and technical details of the AVRcam embedded system.

slow line follower

Postby Guest » Thu Dec 16, 2004 12:51 pm

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.
Guest
 

Postby Guest » Fri Dec 17, 2004 7:45 am

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).
Guest
 

poor contrast

Postby rfhaley » Sat Dec 18, 2004 6:45 pm

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.
rfhaley
 
Posts: 5
Joined: Mon Dec 06, 2004 1:14 pm
Location: Edmonton, CANADA

Postby Guest » Sat Dec 18, 2004 10:19 pm

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...
Guest
 

assembly of AVRcam

Postby rfhaley » Mon Dec 20, 2004 5:18 pm

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
rfhaley
 
Posts: 5
Joined: Mon Dec 06, 2004 1:14 pm
Location: Edmonton, CANADA

Postby Guest » Mon Dec 20, 2004 6:03 pm

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.
Guest
 

lockups while dumping frames

Postby rfhaley » Tue Dec 21, 2004 3:07 pm

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.
rfhaley
 
Posts: 5
Joined: Mon Dec 06, 2004 1:14 pm
Location: Edmonton, CANADA

Clocking the 3088

Postby rfhaley » Tue Dec 21, 2004 4:28 pm

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?
rfhaley
 
Posts: 5
Joined: Mon Dec 06, 2004 1:14 pm
Location: Edmonton, CANADA

Postby Guest » Tue Dec 21, 2004 4:51 pm

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.
Guest
 

lockup solved

Postby rfhaley » Tue Dec 21, 2004 8:45 pm

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'.
rfhaley
 
Posts: 5
Joined: Mon Dec 06, 2004 1:14 pm
Location: Edmonton, CANADA


Return to AVRcam Embedded System

Who is online

Users browsing this forum: No registered users and 9 guests

cron