|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
|||||
|
|||||
|
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.
|
|
#17
|
|||
|
|||
|
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.
|
|
#18
|
|||
|
|||
|
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.
|
|
#19
|
||||
|
||||
|
Re: "mouse encoders"
Quote:
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. |
|
#20
|
||||
|
||||
|
Re: "mouse encoders"
Quote:
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. |
|
#21
|
|||
|
|||
|
Re: "mouse encoders"
Quote:
|
|
#22
|
||||
|
||||
|
Re: "mouse encoders"
Quote:
|
|
#23
|
|||||
|
|||||
|
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
|
|
#24
|
||||
|
||||
|
Re: "mouse encoders"
Quote:
|
|
#25
|
|||
|
|||
|
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.
|
|
#26
|
|||
|
|||
|
Re: "mouse encoders"
Quote:
|
|
#27
|
||||
|
||||
|
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.
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Championship Event - Where the "Random" Match Sorting Really "Shines" | Travis Hoffman | Championship Event | 57 | 19-04-2007 08:06 |
| New NEMO White Papers! "Creating a Killer Packet" and "25 Ways to Sponsor" | Jessica Boucher | Team Organization | 0 | 10-08-2005 10:55 |
| "Thunderbirds" Vs. "Team America" Which one will rule the box office? | Elgin Clock | Chit-Chat | 3 | 07-09-2004 19:53 |
| Conflict between "Initialize_Tracker()" and "pwm13 & pwm15"? Kevin? | gnormhurst | Programming | 3 | 22-02-2004 02:55 |
| how tall is the ramp when in "up" and "balanced" position??? | archiver | 2001 | 1 | 24-06-2002 00:54 |