Richard,
Slow down, I can't keep up at the moment! ;-)
The PID routine works with the error between the desired motor position and the actual motor position, the error magnitude it's able to handle depends on how aggressively it's tuned. Ie with low gain it'll handle large errors without overflowing the internal registers, with high gains it won't be able to handle an equally large error. But generally speaking yes, it'll handle an error of 255 without problems.
If the PID is executed 1000 times per second "stepping it" 255 counts each tick would equal a velocity of 255000 encoder counts per second. Using a 500 line encoder that equals a velocity of 7650rpm, pretty decent.
Looking at the code in your latest post I can't seem to see where you specify the distance to be moved.... (?) But that says more about my abillity to read others code than anything else :-)
I appreciate your ideas very much but at this time I don't see how precalculating the move is going to work in real life. One move might last 100ms while another 100s. One move might travel 25 counts while another might travel 100000 counts.
An example:
I'm at position 0.
* I want to go to position 4690
* I want the velocity to be 123 counts per tick
* I want the acceleration to be 8 counts/tick/tick
Code:
Tick Accel Vel Pos
1 8 8 0
2 8 16 8
3 8 24 24
4 8 32 48
5 8 40 80
6 8 48 120
7 8 56 168
8 8 64 224
9 8 72 288
10 8 80 360
11 8 88 440
12 8 96 528
13 8 104 624
14 8 112 728
15 8 120 840
16 3 123 960 <---Velocity clamped at 123
At tick 16 increasing the velocity by the set acceleration would violate the set velocity so the velocity is clamped at that point. No problems with that or the code to do it.
At this point I know that it took 16 ticks and a total distance of 960 counts to get up to speed. So all that is needed is to start decelerating 960 counts from the desired target position, ie at position 4690-960=3730.
The problem is that when moving at 123 counts/tick the target position will never be exactly 3730 at a specific tick. It'll be either 3675 at tick 38 and 3798 at tick 39:
Code:
Tick Accel Vel Pos
17 0 123 1083
18 0 123 1206
19 0 123 1329
20 0 123 1452
21 0 123 1575
22 0 123 1698
23 0 123 1821
24 0 123 1944
25 0 123 2067
26 0 123 2190
27 0 123 2313
28 0 123 2436
29 0 123 2559
30 0 132 2682
31 0 123 2814
32 0 123 2937
33 0 123 3060
34 0 123 3183
35 0 123 3306
36 0 123 3429
37 0 123 3552
38 0 123 3675 <---Should I start here?
39 123 3798 <---Or should I start here?
So, if I start decelerating (8 counts/tick/tick) at position 3675 I end up short. If start accelerating (8 counts/tick/tick) at position 3798 I end up overshooting - that's the issue with this.
What I'm currently doing in my code is detecting when the distance to target is equal to or less than the distance traveled during the acceleration phase (that would be at tick 39 above) and then recalculate the needed acceleration (deceleration) in order to end up at target. That, however, isn't a one shot kind of thing since the needed acceleration (deceleration) might be 8.324 counts/tick/tick which obviously won't work with PBP. So, next tick I recalculate again and again and again - all the way to the end. The acceleration (deceleration) will toggle between 8 and 9, something like 8,8,8,8,9,8,8,8,9,8,8,8,8,9 - perhaps.
This seems to work in simulation, I have yet to try it on real hardware. The drawback of course is it takes a lot processing power due the division involved in the math.
The above numbers are just an example. The desired acceleration can be "any" number, the desired velocity can be "any" number and distance to move can be anything between 0 and several million counts. And they can change from one move to another.
Thanks Richard!
/Henrik.
Bookmarks