They scraped the camera :-(

[Kev]

Originally Posted by David Fort

For example, here is a piece of <R36>
The item must not be a part custom made for the FIRST competition and provided in the
Kit Of Parts for a previous FIRST Robotics Competition (e.g. 2006 FRC transmissions,
custom-made motor couplers, custom sensor strips, 2006 IFI CMUcam II modules, etc.
are not permitted)

This camera is not a custom built part for FIRST Competition - it was already an existing piece of equipment. I see no issue with using old cameras from old kits.

[RyanW]

2006 IFI CMUcam II modules, etc. are not permitted

That sounds rather unambiguous to me.

[dlavery]

Originally Posted by Kev

This camera is not a custom built part for FIRST Competition - it was already an existing piece of equipment. I see no issue with using old cameras from old kits.

The CMUcam provided in the FIRST Kit Of Parts is indeed a custom part. The board was custom-spun by IFI, under license from CMU. It is NOT the same as the commercial versions of the CMUcan (version I, II or III) that are available. So you might want to be careful about compliance with this rule.

-dave



.

[Uberbots]

Originally Posted by Mark Pendergast

Sorry to spoil the party, but I am glad the camera is gone (at least for a while.) We have never been able to get the camera to work consistently. We have a small team and have never had the time or resources to debug it. We had autonomous software that would have worked if the camera was not checking out the overhead lights or other points of interest, but we rarely got a consistent lock on anything. I believe that has been the experience of the majority of teams.

<RANT >
From what I have seen, the camera has been a failure. It is balky and unreliable. In 2006 and 2007 very few teams at the Boilermaker were able to make it work consistently. (Even with the 'best' teams at IRI in 2007, autonomous ringers were few and far between.)

Also, they have not made a big difference in the game. In 2006, most teams used dead reckoning - ignoring the camera. In 2007, very few teams even tried to score, let alone made a ringer - and the advantage for doing so was minimal.
</RANT>

I am excited about the new IR challenge. I hope that it will be reliable than the camera.

someone didn't read the guidelines to configuring the camera... there was a process you had to go through to configure the camera to see the light. it involved using the LabVIEW application to read/set camera values, and then you copied them into your code... or something like that.

[Chris_Elston]

Originally Posted by Mark Pendergast

<RANT >
From what I have seen, the camera has been a failure. It is balky and unreliable. In 2006 and 2007 very few teams at the Boilermaker were able to make it work consistently.
</RANT>

I disagree. The camera is not a "Failure". It a great sensor to use.

In the "real world" vision systems are 90% about lighting. I use Cognex vision systems in an industrial setting. Excellent vision system by the way, it's based on an Excel platform...awesome stuff...anyway...
http://www.cognex.com

1501 in 2005, the problem I saw was the tetra plaque was very hard to see, even from a vision stand point. It was not illuminated, however we still managed to find the vision tetra at Boilermaker in 2005.

Video 2005:
http://www.youtube.com/watch?v=i1t_WIyBBDE

1501 in 2006, we had AWESOME great time with the camera. I am sure the GDC understood the "lighting" problems in 2005 and learned, so they gave us an illuminated target. That was the best thing they did for us to help the camera. When we fired up the CMU the first time with the green light, it was like a night and day difference from 2005 and 2006. The ability to see the target, again is 90% of your vision application solved with the lighting problem we where able to find and use the CMUcam very effectively.

Here is a video in 2006, in this video you'll notice the opposite team hits us from the side, (it was a redo match 4 times), but they hit us and knocked us off course, we stopped shooting. The camera found the light again, corrected the robot, locked on and started shooting again. Alot of teams thought we did this with "dead reckoning". This was not the case for 1501.

Video 2006:
http://www.youtube.com/watch?v=o2SgDRhX9Kg

In a second video "same match" we had 4 REDO matches in Match 10....anyway, you'll see that the opposite team did a good job stopping us, and the camera knew it. It stopped shooting and held on to the balls, until tele-mode.

Video 2006 #2:
http://www.youtube.com/watch?v=0W90F4V7EXQ

We also had in tele-operated mode, the ability to pull the trigger and the camera would take over the drive system and align the shooter for the drive team automatically. This was very effective because when you approached the goal from different angles it was very hard for the drive team to figure out if you was aligned with the hole or not, so pulling on the trigger in tele-mode used the vision to align to the light.

Video 2006 great match showing auto, and auto aim "tm":
http://www.youtube.com/watch?v=lYUOC3icGPk

Here is the source code for that robot if you would like to see the software used:
http://www.frcsoft.com/forums/index.php?download=11

1501 in 2007, did not use the camera because we did not have an arm. We were a lift bot.

Video 2007:
http://www.youtube.com/watch?v=cJuxH_nHp8w

1501 in 2008, is once again looking at the camera. Of course, we are back to the lighting PROBLEM again above in 2005. There is no illuminate target to make it easy to see. It's not the camera's fault. It's the "application's fault". A challenge? Yes in deed but more realistic in today's world. If I have a green light to look at in the real world, it would be too easy.

The point I'd like to make is it's not the camera's fault. The camera works and works well when you can control certain elements.

Sorry that it didn't work out for you, but feel free to contact me about the camera and I will try and help you out the best way I can. You can only eat an elephant one bite at a time. Look at the CMU cam in this way. It's alot to chew on.

Here is part of an e-mail I sent to another team that gives the low down on the camera:
I also reference tracking the BLUE BALL in this years game
(I reference EasyC, because that is what we use to teach new programmers)

MY QUOTE:
The Java Tool is the easiest tool to get setup to pick a color and get the "color value" you want to track. You take that color value, and you put it in the Camera Table in EasyC. When you drag and drop the camera initialization function, you'll see a "table" that you need to configure. In there you input the color settings etc. By default, EasyC has the table #1 configured to track the GREEN LIGHT. So you don't have to change any of the numbers in the table to track the green light. However since I assume you want to track a BLUE BALL, your going to need to test the camera under the java tool, pick the color from the screen grab, and take that and change the default table. EasyC supports 10 tables. I "assume", you'll be teaching TWO TABLES, one for blue ball, one for red ball. Then when you know what color you want to track, you have dump the camera configuration and load the correct settings "table" per what ball you want to track.

The java tool was PRE-EASYC, released in 2005, so all the settings to populate the table ARE NOT SUPPORT in the JAVA TOOL....
Here is a download to get Java tool
http://www.cs.cmu.edu/~cmucam2/CMUcam2GUI.zip
I dunno if the above is NEWER or SAME as what you got now.....

The Java Tool GUI manual can be found here:
http://www.cs.cmu.edu/~cmucam2/downloads.html

PS: Or you can download all the camera documents and java tool here:
http://www.frcsoft.com/forums/index.php?download=17

So if you want the best compatibility from teaching the camera the color tracking, then you need to install National Instruments Labview, then download these applications:

CMUCam Labview Application
http://www.frcsoft.com/forums/index.php?download=32

Danny Diaz is a good guy to get LabView help, installing, running....if you need help
http://www.chiefdelphi.com/forums/member.php?u=11247

If you get the application loaded and running in Labview, then you can track the color in Labview (your doing the same thing in Java) and it actually spits out a CFG file. That is the same file you need for EASYC. You can have Labview dump the CFG file, then go to EasyC and load the CFG file. Pretty nice when you get it working....

Step #1 - teach camera the color values. (either Java or Labview application)
Step #2 - input color values and settings into EasyC table using manual entry or load the CFG file from Labview
Step #3 - load and initialize the camera in your EasyC software code.
Step #4 - camera should start tracking and streaming data of centroid to you via TTL RS-232. (red LED light on camera indicates that it sees the tracking configuration you loaded it)
Step #5 - map over variables from camera tracking nd write a program or download Adams: example here:
http://www.chiefdelphi.com/forums/sh...highlight=code

My word of advice:

Spend alot of time in Labview with the camera, changing the gains, settings. Make people walk in front of the camera, throw different colored balls in front of it. Use photo filters or gel filters. Don't go to the robot software until you have mastered the object you are tracking. If you can't see the object "consistently" in Labview, then you might as well stop because your vision application is only as good as it gets right at the camera level, don't cheap out your camera settings and send garbage data to your robot controller. A camera is like your vision, you can't see in the dark, the camera can't either. Give your camera 20/20 vision.

Hope that helps.