Quote:
Originally Posted by martschr
I will have to find out exactly, but I think we went with using circumference of the wheels times number of rotations. We used the x and y separately. we measured how far forward we went to change sections in the code. Ex: after x many feet forward we would then execute our turn. Then we measured how far over we went to know what lane we were in. In our hybrid we gave it the signal of what lane the ball was in and the rest relied on the encoders and gyro. If needed I'm sure there is a way of using the x and y together in this same setup, but i don't know the math needed to do it. I will talk to one of our mentors, and try to find a better answer for you.
|
I would be interested in what you guys did for your omni-wheel encoders, I had thought of playing with that.
We used drive wheel encoders and a gyro. It would constantly be calculating our x/y position on the field using trig. Then we used a way point routines to tell the bot to go to a new x/y so we could quickly change where we would want the bot to do also if the bot got hit it could adjust.
It worked well but I feel we had too much gyro problems and too much slippage of the wheels the encoders were connected to. So a different way to track position would be great.