Where is the multi object tracking code for the RC?

[Kingofl337]

They are not individual blobs they are a single large blob. The camera just draws a box around the target pixels.

If you load up easyC PRO we have a program in the Sample Code that
shows what the camera is seeing. It draws a box around the blob and shows an "X" for the centriod (center of blob) and shows the data the camera is showing.

If your not using easyC the CMU JavaApp also can show you the region. I don't know if labview can show this data.

[joe250]

Originally Posted by Kevin Watson

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

-Kevin

If one were to use the VW command (virtual window, see page 55 of the CMUCam2 manual), processing could be done on a particular chunk of the camera's view. By examining a 50px wide window and then repeatedly sliding that window over by a given number of pixels and re-processing, one could reconstruct the two distinct blobs and make an estimate of the number of pixels between them.

Of course if you used this method, the camera's servos would have to be driven by the RC because otherwise resetting the virtual window would cause the camera to track/center on that particular portion of the window. (I'm pretty sure anyways, haven't ever actually tested out the command).

Can anyone verify that using the VW window causes the camera to re-process only that chunk of the view? Also I'm not sure if a sliding window would be too slow. Eagerly anticipating any more hints from Kevin!

[Kevin Watson]

Originally Posted by joe250

If one were to use the VW command (virtual window, see page 55 of the CMUCam2 manual), processing could be done on a particular chunk of the camera's view. By examining a 50px wide window and then repeatedly sliding that window over by a given number of pixels and re-processing, one could reconstruct the two distinct blobs and make an estimate of the number of pixels between them.

Of course if you used this method, the camera's servos would have to be driven by the RC because otherwise resetting the virtual window would cause the camera to track/center on that particular portion of the window. (I'm pretty sure anyways, haven't ever actually tested out the command).

Can anyone verify that using the VW window causes the camera to re-process only that chunk of the view? Also I'm not sure if a sliding window would be too slow. Eagerly anticipating any more hints from Kevin!

Yes, this is one of the cooler approaches that you could try. A simpler way might be to rotate the camera fully clockwise, call Track_Color() and then rotate the camera counter-clockwise until the camera detects the light. Then continue to rotate counter-clockwise until the entire blob is in frame (i.e., the blob isn't touching the edge of the image). Now you know where the right most blob is and its size. Do this again to find the left most blob. A little math, and you should know where the closest scoring location is.

It's a fun problem <evil grin>.

-Kevin

[drakesword]

i had a solution which i do not think is legal but would be cool.

Parts
CMU Cam 2 x2
Basic Stamp Or Javilin
BOE Programming Board

Serial data into the free pins. Program the stamp to tack on a L or R to the packet befor sending it to the robot. That would allow for multi cameras but i dont think you can use a stamp. Maby a pic though.

[gnirts]

Originally Posted by Kevin Watson

A little math, and you should know where the closest scoring location is.

Any chance you could elaborate on this math? Even if you know the relative headings of two lights, I am still having a hard time figuring out how you can approach the spider leg head on (not at an angle).

Thanks in advance,
Robinson

[Kevin Watson]

Originally Posted by gnirts

Any chance you could elaborate on this math? Even if you know the relative headings of two lights, I am still having a hard time figuring out how you can approach the spider leg head on (not at an angle).

Thanks in advance,
Robinson

You don't need to approach the spider leg head on to score (I'm told that is was designed to be fairly forgiving). One bit of math that will come in handy is the equation that allows you to calculate range to the light from the camera tilt angle then it is pointed directly at the light. This method was described in a post last year. This year the centroid of the light will be about 116 inches above the floor.

-Kevin

[gnirts]

Originally Posted by Kevin Watson

You don't need to approach the spider leg head on to score (I'm told that is was designed to be fairly forgiving). One bit of math that will come in handy is the equation that allows you to calculate range to the light from the camera tilt angle then it is pointed directly at the light. This method was described in a post last year. This year the centroid of the light will be about 116 inches above the floor.

I'm familiar with the method for calculating range, but I'm afraid that the mechanical subteam may win in the war to have a manipulator that is (or isn't) robust enough to accommodate any approach to the target except for a head on one.

While I would like it if we weren't angle sensitive, if we are, what math is necessary to figure out your approach angle to the target (eg. head on, coming in at 20*, etc.)?

Thanks in advance,
Robinson

[Kevin Watson]

Originally Posted by gnirts

I'm familiar with the method for calculating range, but I'm afraid that the mechanical subteam may win in the war to have a manipulator that is (or isn't) robust enough to accommodate any approach to the target except for a head on one.

While I would like it if we weren't angle sensitive, if we are, what math is necessary to figure out your approach angle to the target (eg. head on, coming in at 20*, etc.)?

Thanks in advance,
Robinson

It's not an easy problem because you'll need a very agile robot that, at the very least, will need to be four wheel drive so that you can do a turn-in-place (of course, several high school students will read this and grin because they've thought of a cool way to solve the problem that the NASA guy didn't think of -- it happens every year <grin>). If I were you, I'd push back and let the mechanism folks know that their solution for delivering a scoring piece needs to be more robust so the 'bot can approach at more oblique angles. To help visualize how you might accomplish the task, here's a link to a PDF containing a scale Visio drawing of the field: http://kevin.org/frc/2007_frc_field.pdf.

-Kevin

[maniac_2040]

Originally Posted by Kevin Watson

It's not an easy problem because you'll need a very agile robot that, at the very least, will need to be four wheel drive so that you can do a turn-in-place (of course, several high school students will read this and grin because they've thought of a cool way to solve the problem that the NASA guy didn't think of -- it happens every year <grin>). If I were you, I'd push back and let the mechanism folks know that their solution for delivering a scoring piece needs to be more robust so the 'bot can approach at more oblique angles. To help visualize how you might accomplish the task, here's a link to a PDF containing a scale Visio drawing of the field: http://kevin.org/frc/frc_2007_field.pdf.

-Kevin

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?

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 seems that our robot will only be able to score(feasibly) head on.

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

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

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

[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