Quote:
Originally Posted by Kevin Watson
It's been on the back burner for a while and someday I'll get around to finish coding it, but a really neat trick is to not measure the number of encoder ticks per unit time, but to measure the amount of time between ticks instead. Using your example, you could use the internal 10MHz timer to give you a one part in a thousand resolution in velocity at a control rate of 10KHz!. If you don't need to control at 10KHz, you can forward predict the number of ticks to accumulate for a, say, 100Hz control rate, which will give you an incredible velocity resolution of about one part in 100,000. I've used this technique in a few applications for my day gig, with pretty stellar results. Pretty cool, eh?
-Kevin
|
To continue my recent trend of totally sidetracking threads...
I've thought about going that route myself, actually, but I've been put off by the inherent difficulties of measuring
slow speeds with that method. Resolution at top speed is actually lower than resolution at slower speeds. If your top speed is 10 RPS and you've got a 100 pulse per rev encoder, the time between pulses would be 1 ms. So you prescale your timer to count at, say, 10 microseconds. That means your time to speed conversion is 1000/ticks = RPS. So at 100 ticks, speed = 10 RPS, at 101 ticks, speed = 9.9 RPS, 1 tick difference = .1 RPS. At 1000 ticks, 1 tick difference = .001 RPS. And at this conversion rate, the slowest speed you can measure (easily) is 1000/65536 = 0.015 RPS. That's a pretty good range, provided 1% resolution at your top end is adequate. The main problem with the concept as a whole is that your update rate slows down the slower you're moving. At 1 RPS, you'd be updating every 10 ms. Or once a control cycle if you're working at 100 Hz. At .25 RPS, it's once every fourth control cycle and so on. So I think it'd be optimistic to expect a PID based off this to maintain 0 velocity.
Programmatically, my main problem is that unless you've got extra logic in there, things get screwy if you're moving at less than 0.015 RPS. If you roll over the 16-bit timer, it suddenly looks like you've only taken 1 microsecond between pulses and you're suddenly traveling at ludicrous speed. So you'd have to have extra logic tracking how often you've rolled it over, etc. And, of course, the encoder jiggling while you're at rest would make it look like your robot was traveling at a fair clip as well, and etc, etc, etc.
So, mostly, it'd be a fair amount of effort to work up this code, I think. At least it would be to get it efficient and fast. That plus the prospect of a totally new and different control system next year has pretty much completely sapped me of any will to work on it. Except, of course, that composing this post already started the process of hammering out the logic and structure and working around at least some of the problems.... I'm actually pretty sure you could make it work fairly reliably off your Port B Encoder jiggle-resistant logic.....