Keeping two motors in sync

[Kevin Sevcik]

Originally Posted by GeeTwo

I am wondering about the slave part:

Are you intentionally basing the P value on the error from the set point, but the I value on the error from the master? If so, I'm going to have to puzzle a bit as to what would happen if the master jammed.

That's Ether's proposed master-slave dual PID from the thread I linked above. The consequences of the master jamming would depend on the max setpoint error and the P and I values.
If P*error < i2bLimit, then the I term will halt the slave, quickly or slowly depending on I and possibly reverse it and drag it back down to e1pos. Things would obviously settle down somewhere near where P*error = i2bLimit, or at e1pos, once the I term stopped oscillating around e1pos.
If P*error > i2bLimit, then e2is going to go past e1pos and stabilize wherever P*error finds drops down below i2bLimit.

Ether,
I think your pseudo code implements your proposed controller correctly, I'm just not entirely certain the actual dynamics would work as intended. I think it'd take a good deal of tweaking to get your slave's I value tuned well enough that it's going to fight that RLPC trying to drag it upwards with ever increasing error.

Here's something that just popped into my head. What if you limit the RLPC sort of how you limit the integral error? Since we're not doing proper servoing with fatal following errors or anything, we can just choose to slow down (or stop) the ramp if a motor gets in a bind. Super Pseudo code:
1. Calculate RLPC as above, probably saving the change value / actual increment.
2. Calculate output commands for both motors as 2 standard independent PIDs following the RLPC.
3. If both motor outputs are less than abs(1.0) then you're done and you set values and wait for the next loop.
4. If a motor value is >= abs(1.0), then you back calculate the necessary incremental change to hit 1.0 output on the limited motor. Go back to step 1, but with your new (temporary) rate limit (which may be 0). Make sure you only loop back at most twice. Any more would be pointless since you've already tried to reduce things for both motors.

It's a good bit trickier with the back calculating and all, but I think it accomplishes our actual goal. If I'm thinking about it correctly, then what should happen is if either side gets stuck, the RLPC just stops moving. The free side will servo up to the RLPC, obviously, but the RLPC should only be a small-ish distance ahead. Whatever error it takes to get the stuck side to hit 1.0 output. (Possibly we ignore the I and D terms when figuring this.) I think initial moves from standstill and reversals would be interesting, since limiting the rate to only what's currently achievable by the motor would act as a defacto soft-ish start. With an RLPC controller (which is the modified PID I've already implemented) the starts can be a little bumpy, since you can pretty quickly hit maximum output cause your setpoint has infinite acceleration and the motors don't. The setpoint can get far ahead of the normal steady state error, so the motors can over shoot once they break free and start moving.

Mind you, it'll run a little strange what with the speeding up and slowing down, but I think if your PIDs are already pretty stable, it shouldn't add any weird oscillations from the two systems interacting with each other through mechanical delay. Worst case is the RLPC just stops moving completely because the two sides are oscillating around it out of phase and at max command values. You'd have to throw up your hands and curse me for peddling hare-brained poorly thought out control algorithms, but your system would probably survive.

[Ether]

Originally Posted by Kevin Sevcik

Ether,
I think your pseudo code implements your proposed controller correctly, I'm just not entirely certain the actual dynamics would work as intended. I think it'd take a good deal of tweaking to get your slave's I value tuned well enough that it's going to fight that RLPC trying to drag it upwards with ever increasing error.

The purpose of the position command rate-limiting (RLPC) is to help M2's integrator keep up. Yes it's an integrator so it's going to lag somewhat, but don't forget the contribution of M2's proportional action which has no lag.

The best way to settle the matter I guess is to run it on hardware or a simulation.

[Jared Russell]

This is fundamentally no different than getting a differential drive robot to drive straight. You want both sides of the mechanism to end up in the same place at the same time.

In drivetrains people often use a controller that is something like:

output_steering = PID(steering_error)
output_throttle = PID(distance_error)

left_command = output_throttle + output_steering
right_command = output_throttle - output_steering

PID() could be any feedback (or feedforward + feedback) controller you want, and the steering and throttle controllers would have different gains.

distance_error is usually computed as:

distance_error = desired_distance - (left_distance + right_distance) / 2

...and steering error could be calculated by a gyro, or by integrating encoder values over time.

This has worked well on hundreds of FIRST robots for driving, and generalizes as a simple way for coordinating two separate mechanisms. You just need to be careful with how you handle saturation/integral windup and you're golden.

[Ether]

Originally Posted by Jared Russell

You want both sides of the mechanism to end up in the same place at the same time.

That's half the problem. The other half is keeping the sides synchronized while doing so.

For an elevator the synchronization is important because of binding. For drivetrains it's important because the final location of the robot depends on the sides staying in sync during the journey..

In drivetrains people often use a controller that is something like:

output_steering = PID(steering_error)
output_throttle = PID(distance_error)

left_command = output_throttle + output_steering
right_command = output_throttle - output_steering

Nice and symmetric. No master/slave.

distance_error is usually computed as:

distance_error = desired_distance - (left_distance + right_distance) / 2

I think that's a big part of making this work, so that the throttle and steer controllers don't fight each other. They can be satisfied independently.

...and steering error could be calculated by a gyro, or by integrating encoder values over time.

Could you elaborate on what you mean here by "integrating encoder values over time"? Could it be as simple as just using encoder counts instead of rate?