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.

[Andrew Blair]

you now have no clue where you're at cause your wheels have slid


Unfortunately for us, or maybe not, we can't slide. Our wheels simply do not allow it. If hit from the side we have two options: fall over with a loud crash, or start figuring out how to fix a dented side rail. I am interested in the flywheel idea; wouldn't it be better to place two accelerometers 90 degrees from each other to gauge hits?

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

[miketwalker]

Originally Posted by Andrew Blair

wouldn't it be better to place two accelerometers 90 degrees from each other to gauge hits?

I spent 4.5 weeks trying to get those accelerometers to work in a positioning system (I used 2 of them just like you're saying)... 3 days before ship I gave up. A) They're so sensitive and need to be so precise that it's hard to mount
B) The way it's values come back, it is majorly biased and doesn't measure rates equally on positive and negative because of wire resistance.

It's too much work imho.

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?

Pretty much what I'm doing (since I had to abandon the positioning system like I said above) to judge distances from tetras and goals... is using simple math to find how far away the tetra is. Think of depth... when an object is closer to you, it's bigger... further away smaller. So, in using the camera I just use the width to know the tetra is where I want it to be to pick up by doing a simple math calculation (cam.x2 - cam.x1), and you have to test with the bot and put it where you want it to be for picking it up and plug in the number. (If you are confused what cam.x2 and cam.x1 are, refer to the Start Here manual on pages 20 and 22). Then make sure your cam.x (the center of mass) is in the center of your view so you know your lined up with the tetra. Then, do the same with the yellow piece in the goal. Does that make sense? You'll have to play with it on the practice field, but it can be done.

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