Issues
15-11-2005, 18:13
This is obviously subjective to opinion and different schemes work better on different robots, but do you guys use the default drive code or a variation? We have used tank driving so the last few years the default code seemed sufficient, but last year our robot was really jerky. I decided that I would write some code to smooth the acceleration out a bit.
My first scheme used the old code to set the value, but it also retained the old pwm out puts. Instead of outputting the new output from the general code it would output the old pwm value plus an increment that was initialized at one. The value of the increment could be increased or decrease with the joystick auxiliary buttons. So it was like a linear increase
My second scheme was similar to the first, except that it would set the needed increment by looking at the difference between the old and new pwm values and multiplying it by a constant. So the increase in the pwm value in this case was proportional to the difference. I could be wrong, but I think this is logistic acceleration because if you put it into a differential equation, it looks like Newton’s law of cooling.
y= pwm value t= time
(dy/dt)= k(N-O)
Where k is the constant you set N is the new value and O is the old value, except for the fact that O is not constant and it might change with every loop.
My third scheme was to use the second to set the values, but also to use input from the encoders to change the pwm values so the speeds of the wheels are the same. I only use the encoders though while the person is trying to drive straight.
So I guess my questions are
What driving scheme do you use? (Not necessarily one above)
If you were to use my third scheme...
How often would you adjust the pwm values? I have it so it changes it about every half a second. I haven’t got the opportunity to test it out, but instinct tells me that will be too slow, but isn't it true that as the sampling rate of the speed increases, so does the error in speed calculation unless you have a great amount of interrupts in one revolution?
My first scheme used the old code to set the value, but it also retained the old pwm out puts. Instead of outputting the new output from the general code it would output the old pwm value plus an increment that was initialized at one. The value of the increment could be increased or decrease with the joystick auxiliary buttons. So it was like a linear increase
My second scheme was similar to the first, except that it would set the needed increment by looking at the difference between the old and new pwm values and multiplying it by a constant. So the increase in the pwm value in this case was proportional to the difference. I could be wrong, but I think this is logistic acceleration because if you put it into a differential equation, it looks like Newton’s law of cooling.
y= pwm value t= time
(dy/dt)= k(N-O)
Where k is the constant you set N is the new value and O is the old value, except for the fact that O is not constant and it might change with every loop.
My third scheme was to use the second to set the values, but also to use input from the encoders to change the pwm values so the speeds of the wheels are the same. I only use the encoders though while the person is trying to drive straight.
So I guess my questions are
What driving scheme do you use? (Not necessarily one above)
If you were to use my third scheme...
How often would you adjust the pwm values? I have it so it changes it about every half a second. I haven’t got the opportunity to test it out, but instinct tells me that will be too slow, but isn't it true that as the sampling rate of the speed increases, so does the error in speed calculation unless you have a great amount of interrupts in one revolution?