Ideas distingushing between middle goals?

[Zalumaskov]

I was just wondering about how to get the robot cam to find the middle of the three goals. I am considering having it scan for all three and use the middle pan value to get the center goal. Does anyone have any suggestions/other ideas?

[Bharat Nain]

Originally Posted by Zalumaskov

I was just wondering about how to get the robot cam to find the middle of the three goals. I am considering having it scan for all three and use the middle pan value to get the center goal. Does anyone have any suggestions/other ideas?

I just thought of it, the height. I have to look at the drawings, which I can't right now. Can someone check up and tell me if the height is different?

[jgannon]

Originally Posted by Bharat Nain

I just thought of it, the height. I have to look at the drawings, which I can't right now. Can someone check up and tell me if the height is different?

The camera would be finding the yellow triangle under the goal, not the goal itself, so the height wouldn't help. AFAIK, the triangles under each goal are identical.

I plan on using other sensors to find the goal. I have a bad feeling about trying to use those yellow triangles.

[Chris Bright]

I don't know if you have heard of wildstang's stangps but i thought of tracking our position using trig while the camera is leading the bot to the goal. Once the robot picks up the tetra you will know where you are and you will know where you have to go. It might be a little complex though.

[russell]

Do you mean you are going to use the camera servo values for trig? Because those are not very acurate, at least not if you are just using slightly modified (or unmodified) default camera code. Does anyone know how I can change the servo resolution in default camera code?

[jgannon]

Originally Posted by Chris Bright

I don't know if you have heard of wildstang's stangps but i thought of tracking our position using trig while the camera is leading the bot to the goal.

Using something like StangPS would be an effective strategy for finding the goal every time (hint, hint), but I wouldn't use the camera for that, because as russell noted, it's really not accurate enough for that.

Originally Posted by russell

Does anyone know how I can change the servo resolution in default camera code?

From what I can tell, that's in the firmware of the camera board, not in the user code. I would love it if someone could prove me wrong, though.

[Billfred]

Originally Posted by Zalumaskov

I was just wondering about how to get the robot cam to find the middle of the three goals. I am considering having it scan for all three and use the middle pan value to get the center goal. Does anyone have any suggestions/other ideas?

This is something I kinda cooked up--season to taste:

Step 1: Know where you're starting, and make sure the robot knows, too. (A couple of switches on the digital inputs will solve that.)
Step 2: Via dead-reckoning or counting revolutions or something like that, get somewhere in the ballpark of the center goal. (Your robot should, after all, know how to get within a few feet, even if you're bumping a tetra out of the way.)
Step 3: Now let the camera do its thing.

As long as you don't have a really huge field of view, I'm willing to bet you should be good to go when it comes to the center goal.

Hope this helps!

[jgannon]

Originally Posted by Billfred

This is something I kinda cooked up--season to taste:

Step 1: Know where you're starting, and make sure the robot knows, too. (A couple of switches on the digital inputs will solve that.)
Step 2: Via dead-reckoning or counting revolutions or something like that, get somewhere in the ballpark of the center goal. (Your robot should, after all, know how to get within a few feet, even if you're bumping a tetra out of the way.)
Step 3: Now let the camera do its thing.

As long as you don't have a really huge field of view, I'm willing to bet you should be good to go when it comes to the center goal.

Hope this helps!

I would suggest (read: I will be) reversing steps two and three. Measure where you are (with encoders, or an absolute positioning system like StangPS) WHILE letting the camera track. Then, once you've got the vision tetra, you should be able to figure out what you have to do to get over the center goal.

[russell]

That is what I was thinking before I realised that there are yellow triangles in the goals. Our problem comes from using 4wd with skid steer, which I cannot immagine would work very well with dead reckoning stuff. Am I right on that, or do robots tend to always skid the same way?

[jgannon]

Originally Posted by russell

That is what I was thinking before I realised that there are yellow triangles in the goals. Our problem comes from using 4wd with skid steer, which I cannot immagine would work very well with dead reckoning stuff. Am I right on that, or do robots tend to always skid the same way?

Blind dead reckoning works with any kind of robot, because its path is determined experimentally. Unfortunately, while that would have worked great last year, and it will work fine this year for knocking down the hanging tetras, it won't do you any good for finding the vision tetra. You do get a lot of inaccuracy with encoders and skid steer, because your powered wheels do a lot of slipping, and it's hard to estimate how much they are actually going to slip.

[Chris Bright]

Originally Posted by russell

Do you mean you are going to use the camera servo values for trig? Because those are not very acurate, at least not if you are just using slightly modified (or unmodified) default camera code. Does anyone know how I can change the servo resolution in default camera code?

I don't think my post was very clear lol. The camera would just be tracking the tetra. While the camera is tracking we would be keeping tabs on our position with quadrature encoders and a gyro. We would use the position they gave us after we pickup the tetra. I also thought of creating a boundary around the goal so if the robot crossed we would switch back to the camera from trig tracking. So basically the would be two separate systems.

[gnormhurst]

Originally Posted by jgannon

Blind dead reckoning works with any kind of robot, because its path is determined experimentally. Unfortunately, while that would have worked great last year, and it will work fine this year for knocking down the hanging tetras, it won't do you any good for finding the vision tetra. You do get a lot of inaccuracy with encoders and skid steer, because your powered wheels do a lot of slipping, and it's hard to estimate how much they are actually going to slip.

This is a great example of why the software and hardware design teams need to talk to each other. As the software guy, I told the hardware design guys that I strongly preferred using wheel encoders, which meant I wanted a drive system that did not have wheel slippage inherent in the design. Four-wheel drive systems must slip when turning, unless special measures are taken (like car-steering or those crazy roller wheels that slide sideways).

Two wheel systems are very easy to drive and control, and they don't slip while turning, so wheel encoders have a chance of being useful.