I’m working on a project that will require me to control the exact speed difference between 2 motors. Not the speed the code tells the motors to move, but the speeds they actually move. This would require using the encoders built into the motors. I would require more precision that simply telling the motors to both move at 200 rpm.
What kind of logic would I need to use to accomplish this, and how would I go about writing the code for this?
Just use a PID or any other closed feedback control loop right?
Is your only constraint the speed difference, or do you also want to strictly constrain one of the motor’s speeds? Either way, I would suggest using some form of a feedback loop. PID is a decent option, but based on the physics of you scenario, a simple proportional control or a TBH loop might work as well. In the case that you only care about strict control of the difference between the speeds then I would use a PID loop that takes into account the error between target difference and actual difference, and (if the motors are both in similar types of mounts) changes the command symmetrically between the two.
If you tell the motor to move a certain velocity (as opposed to voltage), the motor uses built-in velocity PIDF control that uses feedback to control the velocity. This is why if you try to stop the motor with your hand, the voltage applied will shoot up.
Let me guess: Differential swerve?
With knowing that it seems like the best method would be to cap the motor speed at like 95% or something, so that any friction or anything else that might prevent the motor from spinning at full speed wouldn’t matter, and one motor could match the other.
No, actually a triplet of differential robots I’m making for a tutorial video.
Ya this differential worked fine with built in velocity pid.
The motor is capable of outputting enough voltage to achieve ~230rpm with no load. You could cap to be able to reach full speed quicker, but there may be enough juice in the motor to reach 200rpm even with a bit of load.
@Sylvie
With V5, when you tell a motor to move a certain velocity the motor does specific internal calculations to alter the power sent to the motor so the output matches your requested velocity. Too fast?
Less power is sent Too slow? More power is sent. It knows if it is too fast or too slow by taking measurements from the internal encoder and comparing it to the target value. The process of taking measurements and applying appropriate changes is called a feedback loop. This is the term for the logic that you were looking for. From what I have seen, the feedback control that v5 motors have is very accurate, however it is not suited for all applications. If you want two intakes to move at the same velocity, using the built in velocity control is perfectly fine. If you are programming a flywheel, I would 100% advise you against the built in velocity controller since it accelerates as fast as possible and can apply backwards power if it overshoots the target velocity. Both of these can easily destroy the motor. That is why, if you are trying to design your own feedback controller for the motors, I would recommend using voltage control. As theo suggested, using voltage control lets you control the motor exactly how you want – without the built-in feedback overriding it. What this means is that if two identical motors receive the same voltage but work against different loads, then the motor with the lighter load will spin faster. You can use a feedback loop to fix this issue. The terms you see above such as PID etc are just abbreviated names of popular feedback loops. PID loops clicked in my head when I read the guide linked on this vf post. I highly recommend reading the rest of the thread too. It’s a bit more advanced, but very informative. When you think that you have mastered the concepts found within PID, I encourage you to look up more forms of feedback loops online, theres a lot to learn!
I like these solutions involving simply sending velocity commands to the motors. However, think about what happens when one motor gets stopped by some out side force while the other doesn’t. This will throw off the mechanism.
Instead, I would recommend using a simple slave/master setup where one motor’s velocity is set to the measured velocity of the other. This way, an outside force on one motor won’t affect the mechanism in the same way.
Ummm if the slave slows down, it will have identical issues you’re saying you solved.
It might make more sense to make the “master” sensor value the geometric mean of the 2 real values. Not the best solution, but its a solution.
If one side of the chassis gets pushed by another robot and both motors stop as a result, you’ve essentially turned your robot into a rag doll. If a team literally pushed ur robot u wouldn’t be able to push back
Taran, I don’t know exactly what you are building, but if it is similar to this concept, and your design calls for two motors to be in sync to keep secondary function (hood?, swerve angle?) in dynamically stable position, then I would suggest to seriously re-examine your design.
There is no textbook definition of what vex differential motor sharing is and how one should properly build it. Many teams had built various interesting designs over the last few years with various levels of success.
If you share your design, it will be possible to talk in less generalities and give more specific advice. However, as far as I know, unless the motors that ride on the moving bars or gears (relative to the chassis) are linked in mechanically closed loop, it is going to be next to impossible (short of insanely sophisticated code) to achieve good dynamic stability for the secondary function for any position except the very ends of its range, where you have hard stops.
If you have mechanically open loop, then when you change direction of the primary function, the secondary function will jump from one end of its range to another, unless you have all motors in the perfect sync. Also, without the link, floating motor is not going to contribute any power to the primary function in one of the directions. Finally, if a floating motor dies, you will lose control over both functions.
2131 teams brought open loop differentials to ITZ Worlds in 2018. They had two floating motors (each linked to one side of the drivetrain) mounted on the MoGo lift and contributing power to the drivetrain. The rest of the drivetrain motors were fixed on the chassis.
Their MoGo lifts would jump a little when you would start driving or changed direction. Since they had a pair of floating motors on the lift, even if one failed, robot would still retain some MoGo control, but at a reduced power level. Without such redundancy, they would not be able to drive while maintaing MoGo lift in the predictable position.
It may be tempting to use just one floating motor, given the lower V5 legal motor count, but I wouldn’t do that. Much more reliable and simpler to program design would be to have the motors mechanically linked in the closed loop. Then the secondary function control is going to be stable even without ultra precise PID and you could still limp to the finish line even if one motor fails.
Thanks for that, but based on the fact that I’ve already got one of the robots working with just a simple motor velocity command, I think that will work fine for what I need.
One of the three is similar to 81K’s diff tilter from last year, one is similar to 80110H’s diff mogo lift, and one is similar to the diffy hood from last week.