View Single Post
  #9   Spotlight this post!  
Unread 18-11-2015, 18:32
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 339
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: Using navX MXP to get robot velocity

Quote:
Originally Posted by Alan Anderson View Post
Frame rate wouldn't seem to be relevant. Our test system could track the carpet at more than 20 feet per second from about 2.5 cm, and at least 30 feet per second at 4-5 cm. The problem wasn't related to the speed of horizontal tracking, it was because the vertical distance between sensor and carpet was varying. Moving the sensor upward or downward by less than a millimeter, corresponding to about 2-4 percent of the separation, would throw off the distance measurements by about 5-10 percent. We thought about trying to mount the mouse much higher to make the error a lower percentage, but we didn't have the lenses available to get the focus to work.

The vibration on our test rig was induced by a 2004-vintage Thomas air compressor (we used a pneumatic linear actuator to move a strip of carpet a known distance), at I'd guess a few dozen Hertz. When we tried to use the sensors on an actual robot, the roughness of the wheels and the compliance of the carpet induced enough bounce and other vertical "noise" to make the readings nearly useless.
Got it, thanks, hadn't been taking small-scale vertical variation into account. Moving the lens farther from the floor should help as you say, which also might impact the illumination requirements a bit, but also requires greater depth of field (and wider FOV and higher resolution sensing) to handle faster motion and detect sufficient structure in carpet. It's a fascinating problem...

If we back up to the OP's question about velocity for motion profiling (rather than calculating displacement), do you think your test rig showed promise for velocity vector estimation that would rival or exceed encoders?