DC Geared Motor Slow driving

[miguel76]

Hi Everyone,

I am currently working on a undergraduate robotics project, I am tasked to build an autonomous mapping robot.

I am pretty much finished an d my robot is mapping, but I am struggling with motor control using PWM. I am using a wild thumper chassis with 34:1 geared DC motors, here is a link to the specifications (http://www.communica.co.za/catalog/Details/P4158806527). My motors initial startup voltage is 2V and once running can run slowly below 2V using PWM. I am struggling with the PI controller as I need really slow driving and this initial startup is giving me a problem. Is there anyway using pwm on an arduino based motor controller to achieve slow driving while overcoming the initail voltage. Or any techniques for slow driving with A 34:1 geared DC motor, I know a higher gear ratio will be better for slow driving but I have to do with what I have.

[jwatte]

Is there anyway using pwm on an arduino based motor controller to achieve slow driving while overcoming the initail voltage.

With PWM, the voltage is always the same, only the duty cycle is different.
Is it the case that when you say "2V" you really mean a 25% duty cycle, so that a volt meter might show an average of 2V?

I'm using the Wild Thumper, too, for robomagellan navigation. However, I have modified it to add 34:1 motors with encoders on the two center wheels, this lets me know when the chassis is moving versus not.
If that's an option for you, that's a fun thing to do!
(I also use RoboClaw motor controllers that have built-in PID control for driving the motors based on the encoders)

[miguel76]

With PWM, the voltage is always the same, only the duty cycle is different.
Is it the case that when you say "2V" you really mean a 25% duty cycle, so that a volt meter might show an average of 2V?

I'm using the Wild Thumper, too, for robomagellan navigation. However, I have modified it to add 34:1 motors with encoders on the two center wheels, this lets me know when the chassis is moving versus not.
If that's an option for you, that's a fun thing to do!
(I also use RoboClaw motor controllers that have built-in PID control for driving the motors based on the encoders)

Yes sorry thats what I meant by 2V. I am using encoders on the centre two wheels, which are working well. The tuning of my PID controller on the other hand is very difficult due to this initial voltage level required. To get it to react fast enough is very difficult.

My idea is to find out if there is any technique, for instance alternating the PWM signal to a higher level every 50Hz to just to pulse the power to over come this initial torque. The issue is mainly that once the motors are actually going you can easily drive slowly but not from the start.

[jwatte]

Cranking up the "I" term of the PID controller is intended to take care of this, although with that "bump" you will probably then overshoot.

The best thing I can recommend would be to add another term to the PID controller which is an "impulse response compensator."
Measure how much "extra oomph" you need to change the speed from standing-still (say, how long does it need to be 100% to break standing still?) and manually add that to the output when you detect that the base speed is "standing still" rather than "moving slowly."
The trick is to add this compensation after the output of the PID, so that the big oomph isn't "seen" by it and doesn't take the time to "confuse" it.

[miguel76]

Cranking up the "I" term of the PID controller is intended to take care of this, although with that "bump" you will probably then overshoot.

The best thing I can recommend would be to add another term to the PID controller which is an "impulse response compensator."
Measure how much "extra oomph" you need to change the speed from standing-still (say, how long does it need to be 100% to break standing still?) and manually add that to the output when you detect that the base speed is "standing still" rather than "moving slowly."
The trick is to add this compensation after the output of the PID, so that the big oomph isn't "seen" by it and doesn't take the time to "confuse" it.

Ive tried to ramp up the "I" term but yea i get a lot of overshoot. What difference would the "D" term adjustment have?

Yea this was the thought in the back of my head, my control systems knowledge is not great so it would entail quite a bit of research. DO you know of any similar implementations that I could use as an example?

[jwatte]

What difference would the "D" term adjustment have?

It won't really reduce the overshoot, but it will make the system recover smootoher -- not "ring"

know of any similar implementations that I could use as an example

At that point you're into nonlinear systems (because the response of the "hump" is nonlinear) and the match is both scary and rather "ad hoc."

I'd suggest you have a bit of code after your PID controller that simply says this:

if ((actual_speed < SMALL_MINIMUM_SPEED) && (desired_speed > SMALL_MINIMUM_SPEED)) {
    pwm_duty_cycle = max(CONSTANT, pwm_duty_cycle);
}

"CONSTANT" could be 100%, or perhaps as low as 30% if that's enough to get over the hump. As soon as the speed is actually bigger than the small-minimum-speed threshold, the "artificial boost" will go away.

[miguel76]

It won't really reduce the overshoot, but it will make the system recover smootoher -- not "ring"



At that point you're into nonlinear systems (because the response of the "hump" is nonlinear) and the match is both scary and rather "ad hoc."

I'd suggest you have a bit of code after your PID controller that simply says this:

if ((actual_speed < SMALL_MINIMUM_SPEED) && (desired_speed > SMALL_MINIMUM_SPEED)) {
    pwm_duty_cycle = max(CONSTANT, pwm_duty_cycle);
}

"CONSTANT" could be 100%, or perhaps as low as 30% if that's enough to get over the hump. As soon as the speed is actually bigger than the small-minimum-speed threshold, the "artificial boost" will go away.

Thank you that makes a lot of sense! I will give it a try as soon as I get a chance.