Quote:
Originally Posted by Mentor_Mike
Well, I'd love to tell you all exactly how this was pulled off, but I'm honestly not sure how much detail I"m allowed to reveal. (We haven't had a discussion with the team about this yet, so I don't want to jump the gun.)
Here's what I can tell you though:
- We use two encoders, one per side, in addition to another type of sensor.
- We found the accelerometers WAY too noisey, especially with the bumpy playing surface.
- All four (well, 3 and a bit wheels) are driven, we have no idlers.
- Haven't worked out (unfortunately) how to implement any type of optical sensor to figure out linear velocity. [I'm convinced those new-fangled "gamer mouses" would work, but we don't have the $$$ to test this theory.]
That video is no where near the final product btw. We have to calibrate and optimize for the playing surface and the weight of the trainer.
Anyway, I'll tell you what I can. Please feel free to ask quesitons. If anyone can guess what we did I'd be happy to PM you with our solution. It can be a game of sorts.
BUT, I'll probably have a white paper drawn out by our first regional (Toronto) and it'll be posted for all to see.
M_M
|
The method you're using appears to be the TLS method, in which the speed of the driven wheels is compared with the speed of the undriven wheels. However, since no wheels are idle than there must be another way of sensing your speed. You aren't using an optical sensor or an accelerometer, and ultrasonic sensors would get too much interference from other robots.
My only other idea would be attaching a free-swinging pendulum to the robot. An encoder or Gyro attached to the axel of this device could then be used exactly the same as an accelerometer but without the noise. This does seem like a lot of work though. Does anyone else have a simpler solution to detecting speed?