Single Color Tracking Strategies...

[TedLarson]

I finally have my pan-tilt head setup and working properly. The frame rate on the camera seems very good. I can really wiggle a target around in front of the head and it tracks very well. Seems much faster than the CMUcam2.

Here is an interesting problem. Lets say I am only tracking one color, say orange, and it tracks it very well. When I don't have any orange in the frame, I get no data from the camera at all. Again, I am used to the CMUcam, which always gives me a data stream, no matter what, I just get a zero confidence level on the color I am looking for. So, the problem is, knowing when the color enters the frame. You would have to continually time out over and over checking the camera for a data stream.

So, my question is...what is the best strategy for handling this? One thought I had was to add a broad spectrum color to the color map, so ET would be triggering all the time, but this doesn't seem sure-fire. Any hints on how to avoid timing out when the color you want is not tracking?

Thanks,

-Ted

[Guest]

Glad to hear that the AVRcam is up and working as expected. I haven't had the chance to compare its responsiveness to the CMUcam2, but compared to the original CMUcam, I also found it to be more responsive. So your tests with the CMUcam2 is a good data point.

Regarding a method to be informed of when a color in the color map has been found...it sounds like you have an application set up to receive the packets from the AVRcam already, and that it is expecting to get packets on a regularly timed basis. So there are a couple of options here:

1) The AVRcam firmware could easily be modified to generate a tracking packet with a number of tracked objects set to 0 (the ICD states that this is an acceptable condition). This would only be a few lines to change in the firmware, and I could even send you the file with the mods if you'd like. Another option would be that I could send you a pre-programmed mega8 with this update. But to be honest, I don't think this is the correct approach...

2) I think that updating the receiving application so that it isn't dependent on the tracking packets always arriving makes more sense. In the past, I have set up simple frameworks on a host platform that receives serial bytes in an ISR, dumps them into a buffer, and posts a message that data has been received. Then, a secondary task comes through and processes the buffer in an attempt to build a well formatted tracking packet. When a properly formatted tracking packet is complete, a final handler is called to parse the data in the packet and respond accordingly (drive a servo, etc.). Now, I'm sure you have already played through this solution in your head and there is probably another reason why you may not want to procede in this direction. But for the benefit of others, I thought I would call this solution out.

3) The solution you mentioned regarding setting up one of the tracked colors to cover the full spectrum, and thus always having a trackable color within view, won't work as far as I can tell. The reason here is that if you have a color range set up for all possible colors, you'll end up getting a single tracked object that encompasses the entire field of view. When a "real" object comes into view, it won't be separated out since it obviously falls within the entire range of colors previously set up, and thus will be considered part of it. Another reason this would be a problem is because you would end up having non-unique mappings of RGB triplets to colors (more than a single bit would be set in the final "color" check after the lookup tables had been processed). This is an error condition essentially, and will lead to invalid results.

All this being said, I'd still say to play around and try out some of these ideas to see how the system works. There may be another solution lurking that will be farily elegant.

Keep us posted

[TedLarson]

I think I am going to do something like #1. I downloaded the source, and I started browsing through it, and I can see a number of things I would like to fiddle with that might help my specific application. It is so nice it is open like this, and I am really looking forward to diving in a little deeper.

Which leads me to my next question....what is your favorite AVR programming dongle? There seem to be a number of ways to go on this.

Thanks,

-Ted

[Guest]

Hi Ted,
There are a number of different routes to go here. I sell a basic parallel-port AVR ISP dongle for $15 through JROBOT. There are also a ton of schematics for programmers you can find on the web if you'd like to build your own.

Check out:
http://www.iready.org/projects/uinternet/ispdongle.pdf

to find a simple schematic for a programmer.

I'm glad you're going the route of option #1. I think it will end up being the best since it gives you ultimate flexibility (and it will give you a taste of playing with the AVRs...I've seen that you have a strong affinity for PICs)

Keep us posted...

(....sorry, I wasn't logged in when I posted originally)

[TedLarson]

Hi Ted,
I'm glad you're going the route of option #1. I think it will end up being the best since it gives you ultimate flexibility (and it will give you a taste of playing with the AVRs...I've seen that you have a strong affinity for PICs)

Here we go! I have successfully reprogrammed my AVRcam to output the tracking data, even when there are zero objects. Hardly a masterful feat of programming...1 line code change, and a few Makefile tweaks to get it to work on my setup. Anyway, at least I have a build and program environment set up that works now, so I can start fooling with more internals.

Here is a video clip of my AVRcam in-action on the pan-tilt head. Still a bit jerky....it needs some better tuning parameters on the closed-loop control, but it works nonetheless. Tracking is much faster than the CMUcam, so I am quite pleased.

http://www.tedlarson.com/robots/video/AVRcamhead1.wmv

A few more hourse of effort, and I will have it all back working better than it did before, tracking the box and putting it in the goal.

Thanks for the tips!

-Ted

[Guest]

Cool video Ted! Very nice job on the "head". Glad to hear that you had a chance to dig into the code and play around...as I said before, I think this will serve you best in the long run.

Is this for a specific competition? Just curious...if you make further progress, I'd love to hear about it/watch more videos...keep us posted!

[TedLarson]

Is this for a specific competition? Just curious...if you make further progress, I'd love to hear about it/watch more videos...keep us posted!

This is for our club table-bot challenge. The goal is to build a robot that can find a 2x2" box on a table, and push it into a shoebox (goal), at the end of the table, all without falling off the table. I had completed the challenge once before, but with a CMUcam1, and it spent alot of time re-looking for the box once it lost track of it when it started pusing the box around. So, I am hoping to have it work much better now with the higher frame rate.

Also....I am about to order another one of these AVRcams to try out on our RoboMagellan robot to use it for cone finding. We are currently using a CMUcam2 with an OV7620. The high resolution is great, we can see the cone from about 60 feet away, however, the crummy frame rate makes it hard to keep track of it when driving toward it. So, I am again hoping that the higher frame rate will help here too.

Thanks,

-Ted

[Ringo]

Can you post the code you changed? It would be helpful for testing my setup to have constant data coming out.
Thanks
Ringo