Vision tracking: Did they get it right?

[Greg McKaskle]

Since it is not possible to support all type of robot bases with the current WPILib, it controls what is probably the most common. At one level it computes an angle to rotate, then uses robot drive to rotate. It should be pretty easy to map to alternate drive bases. Of course you will likely want it to move forward, kick, line up with another, etc.

Greg McKaskle

[Paul Copioli]

Is vision needed in this game?

Is the goal stationary? YES
Do you know the location of the balls prior to Auton? YES
Do you know your robot location prior to Auton? YES
Is there potential defense in auton? NO
Can a human score without camera? YES


Is vision needed in this game? NO

We are all for using the camera, when the effort is worth it. We used it in 06, because it was worth it. We will not use it this year because it is not worth it.

[Racer26]

Originally Posted by rjbarra

It uses RobertDrive class which does not support crab drive

I assume you're referring to the "RobotDrive" class.

It would be easy enough to create your own CrabDrive class which extends the RobotDrive class. This would allow you to pass a CrabDrive to the vision code and have it work properly.

class CrabDrive : RobotDrive {
 //build your class here. 
}

Yay for inheritance and OOP!

[Jon236]

Our drivers were very impressed by a demo of the system. They feel that they can drive and play with the camera alone!

This should be an interesting game!

[jspatz1]

Originally Posted by Chris is me

The reason auton scoring is beneficial, in my opinion, is that the goals will be completely undefended. You might not even need to camera track to score in them.

Not necessarily. A defensive bot's autonomous mode may be to block a goal.

[Chris is me]

Originally Posted by jspatz1

Not necessarily. A defensive bot's autonomous mode may be to block a goal.

Nope. Penalty for crossing the white line and penalty for each game piece the robot touched.

[EricH]

Originally Posted by Chris is me

Nope. Penalty for crossing the white line and penalty for each game piece the robot touched.

Actually, it's a double penalty for crossing, double penalty + yellow for the first ball/robot hit after crossing, and double penalty per contact after that. That was a nice understatement, Chris.

But there is a goal on your side of the line that you could block.

[fabalafae]

Is there any starter camera tracking code for LabVIEW yet? I looked through the examples, but those are only for color recognition- not for shapes.

[jhersh]

Originally Posted by fabalafae

Is there any starter camera tracking code for LabVIEW yet? I looked through the examples, but those are only for color recognition- not for shapes.

The starter code for LabVIEW is actually built into the default template. This means that when you create a new robot project, it already contains some sample vision code for finding the target.

[davidalln]

Originally Posted by fabalafae

Is there any starter camera tracking code for LabVIEW yet? I looked through the examples, but those are only for color recognition- not for shapes.

The LabVIEW off the CD does not have it (probably to keep the people compiling the CD from getting a hint about the game early). You have to download the update here: http://joule.ni.com/nidu/cds/view/p/lang/en/id/1534

I think that, because the targets are stationary rather than moving like last year, there is definitely an opportunity to score in autonomous using the camera to track. Long range shooting was impossible last year because of the moving targets and the unpredictable floor, but this year I can see it make a comeback (although it might have been nice to see a point increase for a long range goal... sort of like a 3-pointer in basketball. Oh well...)

[TD-Linux]

I've only looked at the C++ vision code so far, but I would imagine the labview code to be similar.

I am going to test it tomorrow with the old robot, but there are a few things that worry me:

- While the ellipse detection only uses luminance data for detecting edges, it does so by allocating memory, mixing the image down, processing it, then freeing the memory. I don't know how efficient vxworks' malloc is, but this seems like a rather bad idea.

- From what I can tell, the ellipse detection uses the edges of ellipses - meaning that it will detect two ellipses around the inner and outer edges of the black circle. While this is perfectly acceptable when one bases navigation of the center of the circles, it has to potential to throw a wrench into distance algorithms (e.g. inverse perspective transform). Some sort of algorithm will be needed to pick one of the edges (preferably the outer one).

- The tracking algorithm only samples the image once, then bases all further turning on the gyro without sampling any more images. There are both problems with this approach, as well as problems in the implementation. I won't elaborate on this point, as it probably deserves its own separate thread.

I'm impressed that they created a decently working camera example for teams to start with, though it definitely is not a perfect solution. I have to wonder if they did this on purpose - after all, it would be no fun if everyone's robot ran the same code.

[jhersh]

Originally Posted by TD-Linux

- While the ellipse detection only uses luminance data for detecting edges, it does so by allocating memory, mixing the image down, processing it, then freeing the memory. I don't know how efficient vxworks' malloc is, but this seems like a rather bad idea.

You are absolutely correct. And no... malloc on VxWorks is not amazingly fast or anything. It is a bad idea and any patch you'd like to submit to address the issue would be greatly appreciated. I hear the AxisCamera2010 does the same thing, but with C++ new! (hint hint)

Originally Posted by TD-Linux

- The tracking algorithm only samples the image once, then bases all further turning on the gyro without sampling any more images. There are both problems with this approach, as well as problems in the implementation. I won't elaborate on this point, as it probably deserves its own separate thread.

This is intentional... when you are moving, your image is usually very blury, meaning that you are unlikely to be able to find high contrast edges. By using the gyro, you are able to get higher bandwidth data to move you pretty close to your target. Since your target is not moving, you will likely be pointed very close to the target when the gyro is at the detected angle and the next update will be a minor adjustment.

This method is more reliable and typically faster when homing in on stationary targets.

If you'd like to discuss it further, feel free to start another thread.

-Joe

[davidalln]

Originally Posted by TD-Linux

- From what I can tell, the ellipse detection uses the edges of ellipses - meaning that it will detect two ellipses around the inner and outer edges of the black circle. While this is perfectly acceptable when one bases navigation of the center of the circles, it has to potential to throw a wrench into distance algorithms (e.g. inverse perspective transform). Some sort of algorithm will be needed to pick one of the edges (preferably the outer one).

Correct me if I'm wrong as I don't have the code in front of me, but doesn't the example find the target based on locating two concentric ellipses and then find the data such as the height and width and (x,y)? Therefore, the target will essentially act as one circle that can be used for distance algorithms.

[Paradise1165]

perhaps. this year doesnt so sound so imortant or controlable this year. if we had this camera last year and these cool little laptops, yeha this would make it a whoooooooooooooole lots better.

[GGCO]

Originally Posted by Chris is me

The reason auton scoring is beneficial, in my opinion, is that the goals will be completely undefended. You might not even need to camera track to score in them.

What I meant by that was it is pointless to use the camera to score in auton, not that it's pointless altogether.

I totally agree, you could use encoders to score really effectively.