Tracking Rectangles

[RyanCahoon]

Originally Posted by JewishDan18

on the motors (fan, hard drive, etc)

Originally Posted by R48

The only motors and actuators permitted on 2012 FRC Robots include: [...] K. drive motors or fans that are part of a speed controller or COTS computing device

Originally Posted by JewishDan18

power source (no batteries but the kit one, all power goes through distribution board).

Originally Posted by R36

Batteries integral to and part of a COTS computing device are also permitted (i.e. laptop batteries), provided they’re only used to power the COTS computing device.

Luckily they've made this rather easier the last few years than when I tried it in 2008.

[mikegrundvig]

My team is currently considering a single-board computer on the robot. You can get an excellent multi-core Intel Atom-based computer from http://www.logicsupply.com/ for a few hundred dollars. We've already checked with one of our regional inspectors and this would be completely allowed. The design would be:

Axis M1011 --> D-Link --> Atom (MJPEG stream)
Axis M1011 --> D-Link --> Wireless --> Driver Station (MJPEG stream)
Atom --> D-Link --> CRIO
CRIO <--> D-Link <--> Wireless <--> Driver Station
CRIO --> Robot electro/mechanical bits

The Atom would run a program (Labview, custom, whatever) that processes the image feed in real time and uses the network to talk to the CRIO. The CRIO would use this information internally to determine shooting solutions and send needed data down to the driver station so drivers know what's going on and what it's thinking.

The idea behind this is that it removes both the wireless network and the CRIO from the image processing loop at the expense of another piece of electronics in the system. The added horsepower comes at added complexity. The assumption though, correct or otherwise, is that an industrial-ish single-board PC is reliable and the code on the CRIO and driver station can still work great even if image processing fails. The specific configuration I listed above also keeps us with video feed unless the camera itself fails.

Only time will tell if it's a good idea or not

-Mike

[rich2202]

Originally Posted by mikegrundvig

My team is currently considering a single-board computer on the robot.

I thought about that. The only downside is that it is no longer "batteries integral to and part of a COTS computing device ...". Thus, you have to run off the main battery.

The board may be COTS, but the battery is no longer "integral to and part of", and thus not an allowable battery.

[PaulDavis1968]

Originally Posted by rich2202

I thought about that. The only downside is that it is no longer "batteries integral to and part of a COTS computing device ...". Thus, you have to run off the main battery.

The board may be COTS, but the battery is no longer "integral to and part of", and thus not an allowable battery.

I don't necessarily agree with that. I think a ruling on that would be needed.

[mikegrundvig]

Actually, many single board computers have a power supply designed for car use where they can take from 6v to 24v. The power supply we are using does this for instance, making it well suited to the robot.

-Mike

[yash101]

I have wanted to design a vision system to work like that and calculate the distance from the target without range sensors or any other sensors. I also wanted to skip the Kinect because of how hard it is to interface to the robot, and it's slow speed. This is exactly the routine that I wanted to do. Now, I know how to implement it. Thank You!
Also, if I am not wrong, does it follow the laws of perspective that explain how an image looks smaller as it is farther away from your eyes, in this case, the camera.

Here's and O: O
Look at it up close. doesn't it look large?
Now look at it five feet away. It should look much smaller now.
If I am not wrong, I think that is how this is supposed to work!

[faust1706]

Originally Posted by yash101

I have wanted to design a vision system to work like that and calculate the distance from the target without range sensors or any other sensors. I also wanted to skip the Kinect because of how hard it is to interface to the robot, and it's slow speed. This is exactly the routine that I wanted to do. Now, I know how to implement it. Thank You!
Also, if I am not wrong, does it follow the laws of perspective that explain how an image looks smaller as it is farther away from your eyes, in this case, the camera.

Here's and O: O
Look at it up close. doesn't it look large?
Now look at it five feet away. It should look much smaller now.
If I am not wrong, I think that is how this is supposed to work!

is it still too late to contribute? I've been teaching those interested in my team during this preseason computer vision. I posted a white paper on here describing my methods of using camera pose estimation for rebound rumble (note, this is very complicated mathematics, I don't recommend it unless you are up for a big challenge) Pose could have been used for this year, too, but that pesky pyramid, so basic trig sufficed. I'm in the process of writing a scholarly (I guess you'd call it) paper describing my program from ultimate ascent (for the purpose of submitting it to our the missouri symposium and have it compete at Intel ISEF and ISWEEEP, the kid who won isef was on daily show last night) You can view our vision system set up from our website if you like. *we used a single board computer, O-Droid X2. It is our toy now essentially. So much fun to play with.

Anyways. Is anyone doing anything with vision this preseason? I've been working with some professors at wash u, Missouri s&t, and harvey mudd to make a camera pose estimation with a known rotation matrix. Turned out to be a lot more math intensive than the 3 of us first thought...the program will be done before build season and I'll have it up online somewhere so whoever is welcome can look at it. I'll make it as....educational as I can with comments, but comments can only do so much (which turns out to be a lot). If it is another game where there is reflective tape that can be used to assist in scoring, which there has been every year I've been in FIRST (starting with logomotion), then I'll put up a working vision code that returns distance on the x-z plane and x-rotation to the center of the target at a reasonable time during build season.

[Ginto8]

Originally Posted by faust1706

Anyways. Is anyone doing anything with vision this preseason? I've been working with some professors at wash u, Missouri s&t, and harvey mudd to make a camera pose estimation with a known rotation matrix. Turned out to be a lot more math intensive than the 3 of us first thought...the program will be done before build season and I'll have it up online somewhere so whoever is welcome can look at it. I'll make it as....educational as I can with comments, but comments can only do so much (which turns out to be a lot). If it is another game where there is reflective tape that can be used to assist in scoring, which there has been every year I've been in FIRST (starting with logomotion), then I'll put up a working vision code that returns distance on the x-z plane and x-rotation to the center of the target at a reasonable time during build season.

I wrote my team's vision system last year, but this preseason (and hopefully build season), it's in the hands of one of the newer team members -- I'm graduating this year. Your pose estimation project sounds quite interesting to me, though. Thinking through it a little, it seems that for a rectangular target you could use the ratios in length of opposite edges to find the Euler angles of its plane. To figure out the formula to calculate that, though, I'd need some paper and a lot of pacing. I'd definitely like to see your work once it's complete!

[faust1706]

Originally Posted by Ginto8

Thinking through it a little, it seems that for a rectangular target you could use the ratios in length of opposite edges to find the Euler angles of its plane. To figure out the formula to calculate that, though, I'd need some paper and a lot of pacing. I'd definitely like to see your work once it's complete!

If you sit down and think about it for a second, you realize that the whole rotation matrix can be solved without doing pose. the object points are all on a single plane, which in itself makes things simpler, but it also IS the YZ, and it doesn't go into the XY plane at all, which is nice. That means that roll is constant. You can calculate pitch and yaw by proportions with the FOV vs image resolution. Great, now we have the rotation and camera matrix known. the only thing to solve for is the translation matrix. Hurray! This can be done in 2 ways, "plugging in" the rotation matrix into the standard pose equations, or using geometry. I did the geometry approach already, it works. Coded and everything. Currently doing the linear algebra approach. I want to know which one is quicker fps wise. Then, since my team loves gyros but hates the gyro climb, I'm going to use my "pose" as a check on the gyro. So when I have a pose solution, it will fix the gyro readings. I trust my linear algebra more than a gyro that has climbed over 10 rps in the pits.

[yash101]

To isolate the rectangle, could I use a very high exposure rate camera, to reduce blur and to reduce the extraneous light, and have a very powerful light highlight the goals? Thresholding should get rid of the spare pieces, then binary conversion, then erode and dilate, then the other stuff done to find one box?