Where is the multi object tracking code for the RC?

[Kevin Watson]

Originally Posted by maniac_2040

Our team is coming across the same dilemma. However, do you really need four wheel drive to do a turn in place? My team is using a forklift style drive this year(two drive wheels in the front, steering wheels in the back). The engineers of my team told me that we can turn in place by just turning the steering wheels almost perpedicular to the front and spinning the front wheels in opposite directions(ie- to turn left in place, spin the left wheel backwards and the right wheel forward). I am sceptical of this method. Will it really work?

It's more complex mechanically, and the software will be a pain, but once dialed-in, it should work fairly well.

Originally Posted by maniac_2040

But also, I have an idea of how to determine the orientation of the rack/vision target from information from the camera and would like to know the feasibility of it. It draws on the fact that the blob size is proportional to the angle that your approaching the target from. the blob size will be "thinner" if you're approaching from an angle, and larger if you're approaching head on. Do you think it would be possible to determine the angle of the rack based on this information, and the distance?

It will be hard to do this because you have too few pixels to work with. As an example, from the closest starting distance possible (~180 inches), the light at 0 degrees only lights-up 12 pixels, at 25 degrees 8 pixels are illuminated. I think you're better off with a scoring mechanism that will work over greater range of angles.

-Kevin

[Uberbots]

Ive looked through this a bit and basically conceptualized a couple of ways to go about this. First off... if you look at kevin's old camera code you will see that all of the data that you could ever need it within the t_packet_data structure. The bounding box corners are there, along with the centroid location.

the way that i am conceptualizing going about this is pretty much to use size and confidence in order to determine the number of targets. the way i see it, the confidence will decrease when you have a low amount of tracked pixels within a large bounding box. When this confidence goes below a certain threshold, the code will know that only one target is in sight. The next challenge is finding the centroid of each target.

Ok, you know that the camera's X boundaries (but not necessarily the y boundaries) will mark the left edge of the left target, and the right edge of the right target. you will not know the height from this data, but you will not need to. the targets are in a fixed aspect ratio (like 2:1 w:h i believe), and you know the tracked pixels that you have. With this data, by dividing the tracked pixels by two and conforming each dividend to the aspect ratio, you can get an approximate X location of each target.

if you combine this method with the frame differencing data you could probably get the approximate Y value of each target as well. I will have to play around with this method a bit more in labView before i am able to come up with a conclusive algorithm... but that is what i have for now.

[Kevin Watson]

Originally Posted by Uberbots

Ive looked through this a bit and basically conceptualized a couple of ways to go about this. First off... if you look at kevin's old camera code you will see that all of the data that you could ever need it within the t_packet_data structure. The bounding box corners are there, along with the centroid location.

Yes, it's true! Thanks for noticing.

Originally Posted by Uberbots

the way that i am conceptualizing going about this is pretty much to use size and confidence in order to determine the number of targets. the way i see it, the confidence will decrease when you have a low amount of tracked pixels within a large bounding box. When this confidence goes below a certain threshold, the code will know that only one target is in sight. The next challenge is finding the centroid of each target.

Ok, you know that the camera's X boundaries (but not necessarily the y boundaries) will mark the left edge of the left target, and the right edge of the right target. you will not know the height from this data, but you will not need to. the targets are in a fixed aspect ratio (like 2:1 w:h i believe), and you know the tracked pixels that you have. With this data, by dividing the tracked pixels by two and conforming each dividend to the aspect ratio, you can get an approximate X location of each target.

if you combine this method with the frame differencing data you could probably get the approximate Y value of each target as well. I will have to play around with this method a bit more in labView before i am able to come up with a conclusive algorithm... but that is what i have for now.

Excellent analysis. Another bit of data you can use is the location of the centroid within the bounding rectangle. The centroid will be closer to the side of the rectangle with the nearest green light.

-Kevin

[Kevin Watson]

Originally Posted by gnirts

...I am still having a hard time figuring out how you can approach the spider leg head on (not at an angle).

One way to do it is illustrated in the attached illustration.

-Kevin

[gnirts]

Originally Posted by Kevin Watson

One way to do it is illustrated in the attached illustration.

-Kevin

Yes, but you can't line up your robot exactly facing forward or the judges can move it. And the rack can be translated and rotated, too. So nothing is a given. I'll know by tomorrow whether our manipulator can handle oblique angles or not. [crosses fingers]

Thanks,
Robinson

[Uberbots]

Yes, but you can't line up your robot exactly facing forward or the judges can move it. And the rack can be translated and rotated, too. So nothing is a given. I'll know by tomorrow whether our manipulator can handle oblique angles or not. [crosses fingers]

if you load your tube so that it is parallel to the floor, you can essentially load it at any angle. I'm not sure if this should be posted here, but you asked the question. it really is a bad idea to mount it dead on... there are too many accuracy woes to worry about.

[maniac_2040]

Originally Posted by gnirts

Yes, but you can't line up your robot exactly facing forward or the judges can move it. And the rack can be translated and rotated, too. So nothing is a given. I'll know by tomorrow whether our manipulator can handle oblique angles or not. [crosses fingers]

Thanks,
Robinson

Who said that you can't line up your robot exactly facing forward?
I thought the general rule was that you couldn't come on the field with tape measure and other measuring tools to precisely position your robot. Other than that, you can place it however you want. That is the whole point. Last year, you could aim your robot "exactly" facing toward the corner or center goal so you could score.

[gnirts]

Originally Posted by Uberbots

if you load your tube so that it is parallel to the floor, you can essentially load it at any angle. I'm not sure if this should be posted here, but you asked the question. it really is a bad idea to mount it dead on... there are too many accuracy woes to worry about.

This is exactly what I am pushing for. However, I am on a robotics team, and if the rest of the team decides that the other alternative on the drawing board (a gripper claw that grips from the inside, and loads perpendicular to the floor) is better/easier to make, then so be it. It becomes a software problem. I should know my fate by tomorrow afternoon.

[michniewski]

The multi-object tracking cmucamera 2 code shown in the 2007 kickoff can be downloaded here:
http://first.wpi.edu/FRC/25814.htm

This link was also accessible from the usfirst.org programming resource library accessible from usfirst.org. Anyways, I'm posting this because the intelitek webisite link ( http://www.intelitekdownloads.com/easyCPRO/ ) that was posted earlier, while containing the same code I beleive, is currently down due to exceeding their bandwidth.

Michael
1353, Spartans

[maniac_2040]

Originally Posted by Kevin Watson

Really?

-Kevin

So...IS there going to be multi-object tracking code available?(Not the EasyC) Or do we have to modify the existing camera code ourselves?

[EHaskins]

Originally Posted by maniac_2040

So...IS there going to be multi-object tracking code available?(Not the EasyC) Or do we have to modify the existing camera code ourselves?

If you look at the EasyC code it is very simple. All the information from the camera is available through Kevin's code. I think it took me about 2-3 to get it working.

[Kevin Watson]

Originally Posted by maniac_2040

...Or do we have to modify the existing camera code ourselves?

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

[Donut]

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

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.

Sounds like we're all thinking along the same track.

Lets say the rack is turned so an unlighted sided is directly in front of the robot. The two lights will be on the opposite sides of the tracking box and the centroid about in the middle. So keep the centroid in the middle and march to the unlighted goal. Too Simple??? perhaps.

BC

[Donut]

Another method for approaching the spider leg head on is to know your position on the field (meaning you have to get a gyro and accelerometer/encoder combo working in addition to the camera). If you know your position and the angle of the light you're tracking relative to you, you can determine what angle the light is facing and thus what angle you need to go in at.