View Single Post
  #28   Spotlight this post!  
Unread 17-04-2012, 14:13
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: High Speed Encoder Problem

Quote:
Originally Posted by dcherba View Post
the problem is the time between updates can vary. In our c++ program we execute every 20 to 100 millisec. That means if we were doing the count divided by time there could be a 1-5 range of counts. The best thing to do is get the period of the last cycle. That will be in seconds and will not depend on the cycle time of the calls to the actual program.

For those with good control they used a a custom painted code wheel with one or three cycles to get the longest possible period with the highest quality of timer counts to calculate the speed.

Wow 20-100 ms... what are you guys processing (video imaging?)

Anyhow... it should not matter if you have uneven time delta's as the rate will still work out correctly. Now then our problem is a bit unique in that using the GetDistance() technique... the actual pulses got updated irratically where 1 out of every 3 iterations it would update. I suspect this is because we used 4x setting, and I'll need to test with 1x or 2x to see if this behavior changes. Fortunately, our last years robot produces a fluent rate as I'd expect. In which case dividing by time works really well.

Check out this Encoder Test attachment... l1 = left wheels using GetRate(), l2=left wheels using GetDistance(). The r1 and r2 same for the right side. As you can see these are virtually identical, as these units are in RPS. The iteration intervals are around 10-11 ms, but it wouldn't matter what their size is as the rate would still be the same.
Attached Files
File Type: txt EncoderTest.txt (5.9 KB, 7 views)