[gnormhurst]

Originally Posted by Don Reid

Yes, we saw something similar. Our solution was to set the velocity for the startup, is several steps to ramp up the speed, then when the distance is close, switch to position.

As long as your outputs never limit, then that solution avoids the "open loop" problem.

Originally Posted by Don Reid

It is common for PID implementations to inhibit accumulating an integral of the error when the output is clamped to a limit (high or low). You can put in code like:

         // Only integrate if not driving at a limit
         if ((motor_info[motor].pwm < (MAX_PWM-PWM_ZERO)) &&
             (motor_info[motor].pwm > (MIN_PWM-PWM_ZERO))){
             motor_info[motor].vel_error_i += motor_info[motor].vel_error;
             }

Interesting idea. It seems, though, that once the outputs are up against the stops (limits), stopping further integration won't necessarily get it back off the stops. And the loop has no control if anything is clipping.

I didn't get any time today to experiment with integration for the PID position mode. I notice that the default code has the integrator turned off (KI_P is zero):

#define KP_P (50)
#define KI_P (0)
#define KD_P (10)
#define DIV_P (50)

I also noticed that he is dividing the (apparently unused) integrator by the "pid_time" (counts since invoking CMD_DRIVE).

    motor_info[motor].pwm = (KP_P * motor_info[motor].pos_error) + 
                           ((KI_P * motor_info[motor].pos_error_i)/pid_time) + 
                            (KD_P * motor_info[motor].pos_error_d);

I guess this was an attempt to stabilize the loop before he gave up and set KI_P to zero.

Has anyone tried using integration with the position mode?

-norm