Autonomous: CMUCam or dead reckoning?

[Andrew Blair]

As far as I can see, the CMUCam doesn't have any real depth perception, so programming it seems like a waste when you still have to put in you're forward commands. Since the tetras are always in a couple positions, wouldn't it make more sense to have a few variable autonomous modes on switches, using the Hall-Effect sensors to guide? It seems you would need to limit the CMUCam anyway in order to avoid collisions with teammates going for the same tetra.

[Elgin Clock]

I tend to disagree. We have successfully gotten the robot to seek the tetra with teh CMU cam, at different locations on the field, pick it up, find a goal, and stack.

Not that hard to do..

In theory anyways, then again.. I'm not on the programming team, so it looked simple from a bystanders perspective.
Then again again, It may change at the actual venue, as opposed to the conditions during testing. But it did work, and I hope it does during competition as well.. Cause that would be sweet.

[Mike]

Originally Posted by Elgin Clock

In theory anyways, then again.. I'm not on the programming team, so it looked simple from a bystanders perspective.

I wish the code was as simple as it looked, Elgin.

[miketwalker]

Originally Posted by Andrew Blair

wouldn't it make more sense to have a few variable autonomous modes on switches, using the Hall-Effect sensors to guide?

Like Elgin said, it can be done with the programming on the CMUCam. As to what you're saying with just using hall-effect sensors... think bout this... I am a defensive robot... I run across the field and drive around trying to bump things *whoops* I hit you from the side... you now have no clue where you're at cause your wheels have slid... and your robot doesn't know where it's at. Now, there are two solutions to this... you make a positioning system using free spinning wheels and a gyro and such, or just the camera (or both if you want full control). Plus... the positions of the tetras are over a pretty broad area, in 15 seconds I'd doubt you could cover half of them even by just driving around, and thats if you don't hit anything.

[Andrew Blair]

We weren't thinking about grabbing more than 1 tetra during an autonomous period. We're pretty strapped as far as programmers go, having none of them, and myself and another team member have taken it upon ourselves to do. I was considering the value of programming and using the CMUCam cam vs. simply using dead reckoning, not considering the possibility of an occasional bump. I'm pretty sure, except if an alliance partner goes haywire, that a calculated strike like the one you metioned would be penalized by the officials. I'm not sure about in autonomous, but the offensive high speed ramming is in the rules for the human controlled period.

[Cody Carey]

Okay, excuse my friend and my ignorance, we have no idea what we're doing with programming the CMUCam, so he was trying to find a way to do basically the same thing whithout using it . I would like to point out, Andrew, that it would not have to be a "calculated strike" to have the described effect.
Also, could you describe to us what we would have to put in our programming to get the CMUCam to judge depth?

[Cody Carey]

and does anyone know how it judges depth without two lenses?

[Mike Betts]

Originally Posted by Cody C

...Also, could you describe to us what we would have to put in our programming to get the CMUCam to judge depth?

elevation...

[Mike Ounsworth]

From what the programmers have explained to me I think that the best way to have the CMUcam judge distance is to calculate the area of green that it sees by what % of teh field os vision it occupies and compare that to the actual area of the pannel. Hope this makes sense :S

[Andrew Blair]

Thanks much guys! We are completly devoid of programming knowledge and anything helps! I was wondering about the object getting bigger thing. I had asked a mentor about it, but they had thought that we couldn't do it.
Obviously it's possible!

[miketwalker]

Originally Posted by Andrew Blair

Thanks much guys! We are completly devoid of programming knowledge and anything helps! I was wondering about the object getting bigger thing. I had asked a mentor about it, but they had thought that we couldn't do it.
Obviously it's possible!

I've been focusing on using a positioning system, a range sensor to detect range from 3"-60" and just using the CMUcam for color... but when the positioning system went out the window, I found and was pretty quickly able to program the camera to do the object width trick. If you run into any issues, feel free to send me a PM or an e-mail. If you read through the coding section of the manual I talked about, it should explain pretty well how to make your code retrieve the data from the camera you need, then all you need to code is how to work with it (telling the robot to turn to find the objects, moving an arm up and down at the right time, etc.). I hope this helps.

[EricH]

From what I know (admittedly not much as I am not on the camera/accelerometer/gyro crew), our camera guys managed to use the camera as a rangefinder. The theory as I heard it is something like "the camera is at z angle at x height, the vision panels are at y height, so we can use the camera to find distance"- apparently using trig. As for accelerometers, we have two at right angles to each other, but I don't know what the status is on the program. It also helps that we have an onboard processor for incoming data from the camera, gyro, and accelerometer department that sends the data to the RC. I don't know how well it will work- or if it will work- yet because I haven't been around when the program was tested.

[Greg Marra]

Wow, did you guys really manage to judge distance based on the size of what the camera is seeing? I'm impressed.

We did it by mounting the camera about three feet up and using trig to calculate the distance to the tetra based on the angle of depression to it.

[EricH]

Originally Posted by Greg Marra

Wow, did you guys really manage to judge distance based on the size of what the camera is seeing? I'm impressed.

We did it by mounting the camera about three feet up and using trig to calculate the distance to the tetra based on the angle of depression to it.

As far as I know, it isn't the size. It's the position that counts. Size may have something to do with it, but I don't think so.

[miketwalker]

Originally Posted by Greg Marra

Wow, did you guys really manage to judge distance based on the size of what the camera is seeing? I'm impressed.

We did it by mounting the camera about three feet up and using trig to calculate the distance to the tetra based on the angle of depression to it.

If you think bout it... from any angle the tetra (or goal for that matter) is turned... the width is about the same, not enough off to make any significant difference. Thus, when lookin at it and having the camera straight on at the same angle every time... you can say "once the thing is this wide, stop and lift your arm". Both the trig way and this way work similar from what I can tell, I just figured A) without servos theres one less thing to mechanically go wrong and B) dont need to waste precious variable and programming space on trig functions.