Where is the multi object tracking code for the RC?

[Guy Davidson]

We're currently looking at a number of things. Of particular interest to us is the relationship between the location of the centroid and the locations of the top-left and lower-right corners. We're hoping to use the fact that the centroid is closer to the light with a smaller angle to the robot in order to write a function that takes those three locations and tells us enough about where the lights are to either lock-in on one of them or on the middle.

-Guy

[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?

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

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

[Brad Voracek]

Originally Posted by Alan Anderson

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.

Ahh, that makes a lot of sense. Thanks.

[Kevin Watson]

Originally Posted by Brad Voracek

Ahh, that makes a lot of sense. Thanks.

Just FYI, you can create that table, and read from it using the EEPROM code at http://kevin.org/frc.

Edit: I also wrote some example code that creates an 8- and/or 16-bit sine table in EEPROM with one piece of code and then allows you to quickly do a sin() or cos() lookup using another piece of code (stuff written to EEPROM is permanent until you erase it). I haven't written any formal documentation yet, but I think the code is fairly readable. The code can be found here: http://kevin.org/frc/frc_trig.zip.

-Kevin