We have a vertical lift mechanism that we are building for our robot that has two motors, one on each side. We would like to use one button on the remote for up and one for down to control both motors. The motors need to remain in sync as they propel the vertical arm up and down. Suggestions on how to do this? We use RobotC and the motors are the standard 393’s.
- Use encoders and PID control (do a search, there is a TON of detail on this on here).
- Mechanically link them together (gear, shaft, chain, linkage)
- Use reset switches at the top and bottom of the arc that will stop the sides independently, so that any time you run to the extreme, they get realigned.
I have no idea what happened to my numbering…
For my team, we synced them mechanically by connecting the two motors with one axle. This worked, but if you expecting to carry heavy loads, then maybe use a high strength axle. Anyways, hoped this helped.
I think the issue is that the can’t be mechanically connected; therefore the OP is looking at how to use IME to keep the motors in sync.
Well the OP said “standard 393” which made me think he had no sensors. Some sort of cross support is going to be very important. Code can only do so much to sync them up without slowing the lift down drastically.
Thanks for the quick responses. We can use sensors for sure I just wanted to see what was best practice and with what methods people had the most success. We are new so trying to spin up as quickly as we can during our build cycle. Unless we changed our whole design the motors are not able to be mechanically connected together.
Then depending on the range of motion of your input shaft, you may be able to use IMEs, Optical Shaft Encoders, or even Potentiometers. In my experience, Potenetiometers are a bit less reliable in the fact that they break easily, and their values can be inconsistent.
Usually people try to link both sides of the arm with metal. A simple control loop using a sensor on each side can help as well obviously.
Here is an example of a lift with a good amount of support
Here is an example of a lift without enough support
Thanks for all the help everyone. IME’s look to be a good option. I will do some digging for some sample code and see if we can tweak this solution to work. I have not used the IME’s prior so looking forward to learning something new. We are using the Linear motion kit as our rails on both sides.
Does anyone have any competition template code examples using IME’s and linking them to controller buttons for up / down function? Seems to be something I am missing here…I think if I saw an example it would hit me as to how to properly use IME’s.
I don’t have any code, but a general strategy might be something like this. Initialize the encoders to the same value at a known position, most likely the starting position, or somewhere you can put a limit switch for resetting. Then, have your button or joystick control the desired theoretical value, and when there is a difference between the theoretical value and the actual value for either motor, drive them toward the theoretical desired value. One note, be aware of what direction is positive and what direction is negative for your encoders and motors, it might be that they are not what you expect/desire.
I don’t, but something like this code/pseudocode could work. You might also want to adjust for slew rate, but I just focused on matching here. What I’ve written here isn’t an ideal matching method, as if you keep going one direction and releasing repeatedly and one runs faster than the other, it will still slowly skew. But figuring this is for a lift or something like that and this will only happen for short periods, it shouldn’t be bad.
oldLeftSpeed=get speed from encoder;
oldRightSpeed=get speed from encoder;
do the same thing the opposite direction
I think you can simply link them together using Y-Cables. Then, they will act as one motor while coding.
But if one goes faster than the other you can’t correct for it.
The exact same effect could also be achieved by using the slaveMotor(tMotor nSlaveMotor, tMotor nMasterMotor) command. Just wanted to point that out in case someone wants to use this method but can’t use more Y-cables.
Using slaveMotor will probably be better in this situation. Thank you for the correction.
Thanks Everyone!! We ended up trying out the slaveMotor option and so far so good. Really appreciate the help and support.