Two Motors on the same mechanism: risks and mitigations

Dig if you will the picture.

Ball pickup assembly with two arms parallel to the sides of the chassis one on each side. At the outermost point of the arms there is a roller assembly. Each arm is mounted to a motor/gearbox that is used to raise/lower the pickup mechanism. It rotates one direction to go up over frame perimeter and the other direction to go down to pickup.

The concern is that it will be difficult to synchronize control of the two motors and that there will be ‘racking’ problems resulting in the two sides raising and lowering unevenly and/or fighting with each other.

Would you a) build with no concerns over this particular risk, b) proceed with caution or c) abandon hope and find another configuration?

What control schemes would you suggest for best results?

The proposed plan is to use a master / slave configuration. This would feature an encoder (pot) on one arm which will close a PID on that motor. The command to the other motor is a mirror of the first (same magnitude adjusted for rotation).

Thoughts? Suggestions? Lessons Learned?

We used a similar type of set up in 2013 for our climbing robot. Because it was such a compact design, our climbing hooks couldnt be mechanically synchronized. We ended up using encoders on both sets of hooks to have one controlled with pid for position while the other side tries to follow the master side. Overall it worked out fine as long as they started in the same place. Whatever you decide to do, I recommend against a potentiometer. That way if you are using any belts or chains, you dont have to worry about slippage or skipping and having to re adjust the sensor or code.

‘a)’ shouldn’t be an option! What you’re describing sounds good. We have a similar setup right now. We haven’t had any real issues. We’ve also been testing it since week 2 with the motors and parts we are going to use at competition.

If you’re using chain to drive the assembly you need to be wary of skipping after an impact. Then one of the two motors can get out of sync.

I am a big fan of mechanical synchronization if you can get it – hex shaft and hex bearings have really made this a much easier task…

…but if you can’t get it to work, putting the computer in the middle doing the sync can be made to work.

I would actually suggest that you stay away from Master/Slave idea. I would put in independent PIDF loops to control each arm but I would have the RoboRio monitor the situation and take action if the two arms get more than X different.

As to sensors, I am going the opposite direct that Rangel(kf7fdb), absolute encoders like pots are your friend rather than incremental. You’ll want your code to be tolerate of pot adjustments (e.g. have a simple way to offset the pots in code rather than forcing you to chase your tail tweaking pot position). The main reason I don’t like encoders is that the have the problem of loosing position information when the RoboRio is not paying attention. You’ll have to start the arms in exactly the same position each time. If your robot goes brain dead during a match you’ll lose your arm position…

That’s my two cents anyway.

Dr. Joe J.

While a mechanical linkage between the two to keep them in sync would be even better, your plan sounds good. Do some stress testing before bagging (or at least before competition) to determine how closely one arm follows the other; you may have to limit the top speed or acceleration of the master through all or part of the raise/lower cycle to stay in adequate sync.

I may have neglected to mention that the reduction on each side is 324 to 1. This means that the gears will not back drive easily if at all and therefore linking will not be a practical way to sync them.

Consider this instead,

using x(t) motion profile for RLPC.

Ether,

Thanks, I was secretly hoping that you would chime in.

Question about the notation: is each of those four blocks is a separate PID with sp being the command and pv being the feedback?

Did you just come up with this now or is this a scheme that you have known about for some time and if so do you know of any cases where this has been used successfully?

They are separate closed-loop controllers. You can use PID if you like.

Block#1 (the top one) and Block#3 are identical (but separate) and should have similar tuning parameters.

Block#2 and Block#4 (the bottom one) are identical (but separate) and should have similar tuning parameters.

EDIT: Get one side working by tuning Block#1. Then use the same type of controller (and gains) to drive Block#3. Then add Block#2 and Block#4 and tune them to make the sides synchronous, using the same gains in each.

with sp being the command and pv being the feedback?

Yes. sp is SetPoint (command) and pv is ProcessVariable (feedback).

Did you just come up with this now or is this a scheme that you have known about for some time and if so do you know of any cases where this has been used successfully?

Hat tip to Jared Russell.

Lengthy discussion at this thread.

Here’s a simple method for getting a nice smooth x(t) motion profile (if smoothness is desired).

This is what we ended up using for feedback. They are AMS AS5030; they are similar to the CTR encoders that came out this year. These were reputedly in the KOP at some point in the past.

The magnets are inserted into the bolts at the ends of the shafts.

They are pretty compact compared to potentiometers.