|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
||||
|
||||
|
Re: Keeping two motors in sync
Quote:
Quote:
|
|
#17
|
|||||
|
|||||
|
Re: Keeping two motors in sync
Quote:
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. Last edited by Kevin Sevcik : 18-02-2015 at 18:48. |
|
#18
|
||||
|
||||
|
Re: Keeping two motors in sync
Quote:
|
|
#19
|
||||
|
||||
|
Re: Keeping two motors in sync
Quote:
The best way to settle the matter I guess is to run it on hardware or a simulation. |
|
#20
|
|||||
|
|||||
|
Re: Keeping two motors in sync
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: Code:
output_steering = PID(steering_error) output_throttle = PID(distance_error) left_command = output_throttle + output_steering right_command = output_throttle - output_steering distance_error is usually computed as: Code:
distance_error = desired_distance - (left_distance + right_distance) / 2 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. |
|
#21
|
||||
|
||||
|
Re: Keeping two motors in sync
Quote:
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.. Quote:
Quote:
Quote:
|
|
#22
|
||||
|
||||
|
Re: Keeping two motors in sync
Yes I do! We have a guide/spacer at the crossing point to ensure the chain doesn't hit itself.
|
|
#23
|
|||||
|
|||||
|
Re: Keeping two motors in sync
Quote:
In the generalized motor synchronization case, using (left_distance - right_distance) would be fine. Using a trajectory generator to make nice smooth, non-saturated position setpoint profiles is a great way to help solve the saturation/windup problem. |
|
#24
|
|||||
|
|||||
|
Re: Keeping two motors in sync
What's the angle between the two axles? Teeth on each sprocket? Distance between axles' CPA? Chain size? We're trying to do a figure 8 roller chain at a massive scale for our team motto, "Infinite Possibilities", and could use a bit of help in art of the possible here. Our team logo is a 7-tooth sprocket, so we're really limited in how much horizontal spacing we get for any given angle. Our massive scale last year didn't work out so well - we went with about an 8" pitch on the chain (don't quote me; I wasn't part of the team on this) using masonite board. At some point, the chain fell on the floor and shattered. We turned off the motor and just put up the two sprockets with the "tiger eye" in the center hole. It still looked cool, but not nearly as cool as we'd hoped.
|
|
#25
|
|||||
|
|||||
|
Re: Keeping two motors in sync
So here's a stripped down version of our robot code with just the lift stuff and the rate controlled PID that I worked up.
There's some features I added to the PID class that may not be relevant to your system. I added a Kv term for velocity feedforward based on whatever your ramp rate is. There's also limit switches integrated in there so the PID stops if a limit is hit in the direction you're moving. It both prohibits motor command in that direction, and updates the target setpoint to whatever the current position is when you run into a limit. If you're not using limits, just leave those blank or set to NULL and that logic will be skipped. To accommodate different wiring practices, the bool limitHit parameter sets what value indicates that a limit has been hit/tripped. There's a few others as well, so ask if there's any confusion |
|
#26
|
||||
|
||||
|
Re: Keeping two motors in sync
Quote:
Edit: moved attachments here. Last edited by Ether : 19-02-2015 at 23:43. |
|
#27
|
||||
|
||||
|
Re: Keeping two motors in sync
This is amazing. I am learned so much. Kevin, Ether, and Jared. You have helped more than you know. I wish I had more to say but I am busy reading whay you wrote and this site which has helped me wrap myhead around the variables and acronyms you have been using. Thanks.
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|