Where is the multi object tracking code for the RC?

[joe250]

Originally Posted by Donut

I'm not sure how many of the teams have gotten to the camera yet. Our team does mainly design and field elements the first week, so we haven't touched the camera yet.

We are in a similar situation, and I was hoping to begin camera work this week. Kevin, I'm actually glad that you've decided not to release your camera code right away and have instead just gently prodded () us in the right direction. Though your code is phenomenal and a big help, it has been a lot of fun this year to try to figure out some possible alternative solutions (especially for such an interesting problem).

To all the people who have proposed methods other than the one used by the EasyC code: would you care to share any test results or code for those methods? It would be very time consuming for everyone to test every method for its viability, so perhaps some collaboration would be useful.

I'll try to post some LabView Code and C source if I can test the VW thin-slicing method soon. Thanks again to Kevin and everyone else's input on this topic

[maniac_2040]

Originally Posted by Kevin Watson

I've been making suggestions on how this could be done in the hope that someone would modify my code (tracking.c) and discuss their modifications here. Given the lack of actual discussion taking place, I'm not sure if teams just went into their "Skunk Works" mode or if teams are just throwing-up their collective hands and not working on it.

Anyway, I have an idea for an algorithm that I'll have time to test out over the next few evenings. If it works well, I'll post it on my website. As all good engineers keep a backup plan in their pocket, you might consider implementing one of the other algorithms discussed in the forums, or invent your own. Either way, your time won't be wasted thinking about the problem.

-Kevin

Well, it's not like I wasn't/haven't been thinking about this. I only asked because I was about to start hardcoding and wanted to know if I should wait. It would be stupid to code up a whole solution if I knew that one would already be available in a few days(no need to reinvent the wheel). I have been thinking about this quite a bit.

[Brad Voracek]

Originally Posted by Kevin Watson

.... Basically, range = (green light height - camera height)/tan(tilt angle), ... tilt angle is the calculated tilt angle derived from the tilt PWM value when the tracking software has a good solution. ...

-Kevin

My question, what is the best way to change those PWM outputs to a tangible angle for the tangent function to use? Our team didn't get to test the camera much last year... So it's all sort of new for me. Obviously it has to be in radians, because, correct me if I'm wrong the tan function in C is based off of radians.

I've thought about ways to do this, and it isn't all too complicated... I just need to test it out, and make sure 127 would be the camera pointing parallel with the ground. I'll get to testing it, but I'm wondering what you guys have come up with for this?

[Alan Anderson]

Originally Posted by Brad Voracek

My question, what is the best way to change those PWM outputs to a tangible angle for the tangent function to use?

I believe the best way is not to use the tangent function on an angle in the code. It's both easier and quicker to use a small lookup table that turns the camera tilt PWM value into a distance.

You can use a tangent function when you create the lookup table, of course. Or you can fill in the table empirically by repeatedly placing the robot a known distance from the target and observing the tilt angle.

[Bharat Nain]

Originally Posted by maniac_2040

Well, it's not like I wasn't/haven't been thinking about this. I only asked because I was about to start hardcoding and wanted to know if I should wait. It would be stupid to code up a whole solution if I knew that one would already be available in a few days(no need to reinvent the wheel). I have been thinking about this quite a bit.

You might as well start experimenting. Neither Kevin, nor anyone else(apart from maybe GDC) knows how autonomous will turn up. If Kevin comes up with a better solution for your purpose, use it.

[JBotAlan]

I am confused; I didn't even know that the *hardware* supported multiple objects. I'll have to have a look-see at that code to figure out how multi-tracking works.

JBot

[Kevin Watson]

Originally Posted by JBotAlan

I am confused; I didn't even know that the *hardware* supported multiple objects. I'll have to have a look-see at that code to figure out how multi-tracking works.

JBot

The hardware doesn't support tracking of multiple objects. The code that Dave mentioned, written by FIRST's Neil Rosenberg, infers the location of a "spider leg" by looking at the size of the image. If there are two lights in the scene -- which is not always the case -- the camera returns a blob size that is far too big to be from one light. If the blob size is small, you know that there is only one light in the scene and there is a spider leg directly underneath.

-Kevin

[DanDon]

Kevin,

If you did write code (I hope I'm not misinterpreting your post), do you have an approximate release date?

[robind]

Bump? It sounds like Kevin's leading us on a little, but I would love love love to have that code.

[Kingofl337]

Kevin, if your 2007 code can has the tracking similar to what Neil wrote then I apologize as I was misinformed.

Kevin is 100% correct the CMU can't track multiple objects the code just looks at the size of the target region and if its over a certain size prints that its looking a 2 targets. In the demo they used a terminal emulation program and used VT100 calls. We made our own custom terminal window and function to do the same thing in easyC PRO.

WPILIB is 100% compatible with MPLAB, and Eclipse. Infact it's currently being written and maintained in Eclipse,
WPI has been using it since 2005 on their FRC robots.

[arshacker]

any reason why easyc can't open bds file for the multi-object tracking code??

[Ctrl Alt Delete]

OK, so we have to use WPILib to get the tracking code? We were going to use FusionEdit and not easyC.

[Astronouth7303]

The way the camera works is that it takes a picture, finds all the pixels that fall into a color range, and finds information about them. The information I've used in the past is:

• bounding box (x1, y1, x2, y2)
• The median point (mx, my)
• The pan/tilt (see note)
• a "confidence" (basically a ratio of the color blob area to the area of the image)
• IIRC, some statistical information about the color is also provided.

Note: In 2005, the camera would drive its own servos and report their values. In 2006, the code would not configure this way, instead relying on the RC to do it. (I changed this to the 2005 behavior in my own code.) I do not know yet what the behavior is this year.

I do not remember if the camera provides the number of separate blobs in the default information. If it does not, the communication overhead and computation requirements would likely be prohibitive. If it does, there is a good chance that you can not get the separate bounding box/median information for each blob.

Of course, I'm likely to eat my words when the actual code gets around.

EDIT: Wow. How much discussion occurs while I post!

[Kevin Watson]

Originally Posted by Astronouth7303

I do not remember if the camera provides the number of separate blobs in the default information. If it does not, the communication overhead and computation requirements would likely be prohibitive. If it does, there is a good chance that you can not get the separate bounding box/median information for each blob.

Yes you can, but the RC needs to control the pan/tilt servos...

-Kevin

[Eclipse]

How exactly does one access the data pertaining to the individual blobs? I didn't remember ever seeing anything like that in the code...