Re: "mouse encoders"
 

Our 2005 Triple Play robot had three miniature omniwheel "follower" encoders. There was one in front and one in back to measure sideways motion and turning, and one in the middle to measure forward motion. It worked great on carpet. On vinyl or tile or concrete, not so great.

Re: "mouse encoders"
 

How did you measure rotation with them? Ive been looking at a similar concept but couldnt come up with a way to do it without a ton of floating point math/look up tables.

Re: "mouse encoders"
 

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.

Re: "mouse encoders"
 

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.

Re: "mouse encoders"
 

We experimented with using two of the new large VeX omni wheels mounted at right angles to one another. Each of the wheels directly drove a 64 count per revolution greyhill shaft encoder. The Y (front/back) wheel was close to the center of the robot and the X wheel was mounted just inside the back chassis member. The following is an excerpt from the "test report" that is attached. - This report also includes ultrasonic and gyro data. The gyro data in this report was with a 150degree/second 2006 KOP gyro (illegal for 2008) - we ended up using the 2008 KOP gyro for our first regional (VCU) and then the AD 300 degree/sec gyro for NY and Nationals... Oh this is an mecanum system using the 6" AM wheels. We figured we could not tell with the gyro and drive wheel shaft encoders what direction the robot was really moving without the odometry wheels. When all was said and done we used the ultrasonic range to the center wall to control strafe to keep/move the robot to the right lane. I have data sets from our matches with some interesting/puzzling ultrasonic data, not sure how enlightining it would be for others but most of the time the ultrasonic sensor worked well other times it just plain gave us bad data and it is not at all clear if the problem was an intermittent sensor failure or interference.

Oh yeah, I have a bunch of optical parts the controls hardware guys ordered in the basement - it will be a summer project. I haven't had the time to do a sanity check on the design or optics but I think that it will not keep up as well. I think this is the design reference http://home.roadrunner.com/~maccody/...ouse_hack.html With the old controller we would have had to use a microcontroller to do the USB to serial conversion but if this works it might interface more easily to the cRIO?


Hope this data is helpful,

Greg

This is the result of the odometry wheels for the linear run. The measured distance for this run was 22’8” whereas the predicted Y distance from the Y odometry wheel was 22’7.44” – almost perfect. The measured X displacement however was 11.5” but the predicted X displacement from the odometry wheel was only 1.68” showing that the wheels do not provide accurate displacement information when the direction of motion is almost parallel with their axel. I think this makes sense given the roller pattern on the wheels.

Re: "mouse encoders"
 

If you look at the picture David Brinza put in the thread earlier you can get a good idea of our setup. Basically there were two omniwheels connected by a shaft that was attached to one encoder. This was used as to determine distance of forward motion. In the back of that is one omniwheel perpendicular to the other two, and attached directly to a encoder. This was to give us info on how far over we moved. If we moved diagonally it would register both distances to give us our position (10 feet forward and 5 feet to the right). The biggest problem we had was mounting it, however this would have been easier if we haden't been a flopbot.

Re: "mouse encoders"
 

I saw the picture, big question did it work well, how much loss was there. Ours worked well but it started to having a lot of loss once a half lap was done, so you could not have lots of accruacy that you could depend on.

Re: "mouse encoders"
 

as far as i know, the Razer Lachesis is the fastest mouse, i have one, and ive tested it and have not been able to max out its speed

Re: "mouse encoders"
 

Looks impressive, hard to believe it could do 10fps. How would you interface to it? Any specs on the connection and how to connect to it via various ports or even using usb with non-window machines.

Re: "mouse encoders"
 

The encoders were accurate everywhere except for turns. As you can imagine the two wheels being connected caused a bit of fight around a turn. The encoders do work well going strait though. It would be possible to make alterations to make it work better going around turns, such as having all three wheels on separate encoders where none of the wheels are tied together. The outside wheel would have a greater distance traveled than the inside wheel, but if you consider that into your math then it should work fine. We did not have a need to measure our distance while going around the turn. We used our gyro to make the turn. Our main purpose with the encoders were to know what lane we were in, and to have an assigned distance to travel forward before moving on to the next section of the code. Because of this we did not have a need to further develop the "mouse" to measure through a turn, but it could be done.

Re: "mouse encoders"
 

Well it says it can do 100 inches per second max, which is 8.3 feet per second. This year, our robot reached 15fps.

Re: "mouse encoders"
 

I doubt many teams went 15fps in autonomous, but ours and others went faster than 8fps, thus this would not be a good option.