Tracking in YCrCb?

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

Tracking in YCrCb?

Postby sam0737 » Sat Dec 11, 2004 7:34 am

I have registered to a robotic competition, it requires the robot to travel in White Line grids with green background. Previous experience tells us IR Sensorz aren't going to work. I want to give a try on AVRCAM for that.

The question I want to ask is, will it give more accurate/stabler result if the tracking is done in YCrCb color space? Because we are worry about the lightning condition in the competition field, and heard that if it's done in YCrCb, it's more resistence to illumination changes, is that the case?

And if YCrCb really gives better result, what is needed to change in AVRCam to make a switch? Is that simpily modify the Cam Register to ask the Cam Module to gives YCrCb and it's done? (Put aside that the AVRCamVIEW will give strange framedump)
sam0737
 
Posts: 4
Joined: Sat Dec 11, 2004 7:27 am

Postby Guest » Sat Dec 11, 2004 10:32 am

Hello,
The AVRcam does a great job at detecting distinct colors such as white on green. In this case, I bet you will be fine in the normal RGB mode of tracking. This is what I used at the Chibots line-following competition last month, and it worked exactly as I had intended. I only wish I had spent a little more time on the algorithm to ignore any seemingly "white" part of the image that wasn't connected to the line I was tracking (in this case, there were some reflections from an overhead skylight that screwed me up...the AVRcam reported them back as trackable objects, and I should have done a better job in my main controller application to ignore them).

The question I want to ask is, will it give more accurate/stabler result if the tracking is done in YCrCb color space? Because we are worry about the lightning condition in the competition field, and heard that if it's done in YCrCb, it's more resistence to illumination changes, is that the case?


Yes, YCrCb is more resistant to changes in the lighting conditions. I have toyed around with this a bit, because, as you said, it is as easy as setting a register on the OV6620 to change its output to this color model. It seems to work ok, but since its hard for me to natually envision luma/chroma data, I have been sticking with the RGB model for now. This is definitely an area where some experimentation would be useful though.

(Put aside that the AVRCamVIEW will give strange framedump)

Again, correct. AVRcamVIEW does display a "funny" version of the image, but you can still make out what the objects are.

One other thing to note about using the AVRcam for line tracking...the stock software on the mega8 will track up to 8 objects, but when tracking a line, the entire line appears as one contiguous object (because it is). This results in one bounding box being returned over the user-interface. I made a one-line change to the firmware that set the maximum height of an object to around 17 pixels. Any time an object over 17 pixels "tall" was encountered, a new tracked object had to be added in, instead of just adjusting the current tracked object. This allowed the system to break the tracked line up into 8 chunks, and report back the bounding-box info for each chunk. So when the object turned to the left or right, the AVRcam reported back a nice progression of tracked chunks that mapped to the contour of the line. Let me know and I can send you the single line change to make this work (or maybe I should just post it to the Download section, if more people would be interested in it).

Good luck, and keep us posted...
Guest
 

Postby Guest » Sat Dec 11, 2004 10:55 am

(or maybe I should just post it to the Download section, if more people would be interested in it).

It would be nice :)

but when tracking a line, the entire line appears as one contiguous object (because it is).

I think I would be tracking the green background instead of the line. (The camera would be facing downward)
The plan is - from the background fragments to figure out where the line is and how it's coordinated and hopefully we can make the robot running freely on the field, not just sticking on the grids.~

ar. By the way, I can't find the AVRCamView - compiled version? Would you mind posting that?
Besides, the source tar-gz included the absolute path which confused my decompressor - PowerArchiever for Windows.

May be I will order a kit around christmas, after exam ;-)
It's really a wonderful project, thank you so much in making this...keep on :)
Guest
 

Postby Guest » Sat Dec 11, 2004 12:52 pm

I think I would be tracking the green background instead of the line. (The camera would be facing downward)
The plan is - from the background fragments to figure out where the line is and how it's coordinated and hopefully we can make the robot running freely on the field, not just sticking on the grids.~


Ok, that should work too...but remember...you're getting up to 8 bounding boxes to encapsulate whatever color blobs are found by the AVRcam. Thus, if you have an actual grid, with a green background + 5 horizontal lines and 5 vertical lines, all intersecting, you have at least 25 distinct regions (25 distinct, segregates squares), and the AVRcam would only track the first 8 that it found. I'm not exactly sure how the grid is set up for your competition, but be aware of this fact.

By the way, I can't find the AVRCamView - compiled version? Would you mind posting that?

I'll hopefully post the entire ISO image of the AVRcam Software Suite CD by the end of the weekend. This will have, among other things, the installer for the AVRcamVIEW executable.

Besides, the source tar-gz included the absolute path which confused my decompressor - PowerArchiever for Windows.

Do me a favor...could you post the issue you had to the AVRcamVIEW discussion group? My friend Brent Taylor who wrote the AVRcamVIEW application is monitoring that group, and he should be able to respond.

Thanks...
Guest
 

It's just one line of code...

Postby davej » Tue Mar 01, 2005 1:52 pm

ajo115 wrote:... I made a one-line change to the firmware that set the maximum height of an object to around 17 pixels. Any time an object over 17 pixels "tall" was encountered, a new tracked object had to be added in, instead of just adjusting the current tracked object. This allowed the system to break the tracked line up into 8 chunks, and report back the bounding-box info for each chunk. ... (or maybe I should just post it to the Download section, if more people would be interested in it).


John, you mentioned posting this in the download section, but I couldn't find anything in either the current or past-versions pages. Could you post it?

Maybe I just couldn't find it after spending a lot of time under a magnifying glass soldering my AVRcam board. :)

BTW, mine is working great (I'm running software from the 1.03 version of the CD).

--dave
davej
 
Posts: 1
Joined: Tue Mar 01, 2005 1:36 pm
Location: Near Chicago, IL

Postby Guest » Tue Mar 01, 2005 7:59 pm

Ok...the updated FrameMgr.c (called FrameMgr_for_line_following.c) file is up at the Download section of the website. This file will create a new tracked object in the trackedObjectTable after the current tracked object reaches a height of 17 pixels. This allows a tracked line to be broken up into 8 different objects that follow the contour of the line ahead.

The one-line change is in the findConnectedness() routine, in case you want to see how simple it really is.

So Dave...are you getting a line-follower ready for the next Chibots competition????

Have fun...
Guest
 


Return to AVRcam Embedded System

Who is online

Users browsing this forum: No registered users and 15 guests

cron