Originally Posted by Kevin Sevcik
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.....
|