We have a robotic arm that is going to be moved up and down with the use of 2 CIM motors. The CIM motors have different rpm’s or speeds making them fight against each other when they try to move the arm. We are going to mount the versa-planetary encoders on the motors to fix this. I was wondering how you would program it in teleop so that the encoders would make the CIM motors have equal outputs so everything would be in sync. I haven’t used PID, but I was wondering if that is how you fix it. Also, if we wire the encoders into the Talon SRX’s will we still be able to program with them? We are using labview.
*Please provide a more detailed description of your design.
What do you mean by “The CIM motors have different rpm’s”? If both CIMs are attached to the same shaft or same gearbox, they will have the same speed, and they won’t be “fighting” each other if both are getting the same command.
Or did you mean to say you have two arms, each powered by one CIM?
*
*
The motors are connected to the same shaft on opposite ends that is supposed to rotate the arm. When the motors run at 100 percent to rotate the shaft one turns at 62 rpm +/- 3 rpm and the other runs at 65 +/- 3 rpm. So, when I move the arm the slower motor drags the other one behind. The arm we are trying to rotate has to be able to lift a lot of weight, so it is a problem when the motors fight each other. I saw something in other threads about calibrating speed controllers. Can you do that with Talon SRX’s? We use talons utilizing CAN bus for communication. So far in the user manuals I haven’t seen anything about calibrating them.
I don’t know much about master and slaves. But would that setup work with the two motors instead of PID control?
-
Where are you getting these numbers from?
-
62 rpm +/- 3 rpm and 65 +/- 3 rpm share a 3 rpm tolerance band. They may in fact be spinning at the exact same speed. Do you have any other physical evidence that one motor is spinning faster than the other? See 3 below.
-
If the two motors are connected to the same shaft, it is not physically possible for them to spin at different speeds unless the shaft is actually twisting or a belt or gear is slipping.
-
65 rpm is approx 360 degrees per second. How long is the arm that’s connected to this shaft?
So, when I move the arm the slower motor drags the other one behind.
If both motors are functional that’s not an accurate description of what is happening. One motor may be carrying a bit more load than the other, but it is not “dragging” the other motor.
The arm we are trying to rotate has to be able to lift a lot of weight, so it is a problem when the motors fight each other.
One motor may be carrying a bit more load than the other, but the motors are not “fighting” each other: they’re both contributing torque to lift the load.
I saw something in other threads about calibrating speed controllers. Can you do that with Talon SRX’s? We use talons utilizing CAN bus for communication.
Calibration is for PWM. If you’re using CAN you don’t need to calibrate.
I don’t know much about master and slaves. But would that setup work with the two motors instead of PID control?
EDIT: saw your 4th post
Using separate PID for each of two motors which are physically connected is probably not the best way to do it.
If the motors are physically connected to each other (as yours are), using master/slave may be appropriate. But this will not solve the problem you have described (excessive loading and shaft bending).
Answers to your questions.
- We used a handheld digital tachometer to measure each motors RPM individually at free speed. The RPM hovered in those ranges for each motor.
- The shaft is in fact twisting a bit. We are worried that the couplings are going to break as a result of this.
- The arm we are moving is a “boom-like” structure 48.5 inches long and made out of aluminum. The fulcrum where the motors (connected by the shaft) are an inch from the end. Just moving the arm is heavy enough, but it is more so when there is a load on the end of it. This is a video of our robot when we were using a snowblower motor to pivot the arm. The snowblower motor ended up not giving as much lift power as we wanted. https://www.youtube.com/watch?v=YJ1LrNceyyI
- We were not using PID at all. Just normal select triangles for buttons to create an output.
The free speed of a CIM is not 63 rpm. What exactly were you measuring?
- We were not using PID at all. Just normal select triangles for buttons to create an output.
The free speed of each motor being slightly different does not mean the motors are “fighting” each other when physically connected to the same shaft and being given the same open-loop command. Each of the motors is trying to lift the load. One is not “dragging” or “fighting” the other.
The arm we are moving is a “boom-like” structure 48.5 inches long and made out of aluminum. The fulcrum where the motors (connected by the shaft) are an inch from the end. Just moving the arm is heavy enough, but it is more so when there is a load on the end of it.
The shaft is in fact twisting a bit. We are worried that the couplings are going to break as a result of this.
Not good.
Did you use the JVN spreadsheet to calculate how much torque that 48" arm is exerting on the shaft (and on the gearbox output stage?). If not, I recommend you go back and do that before doing anything else.
1)We have gearboxes on the CIMs which makes the rpm slower.
2)Also, our mechanical team made a bench-top robot testing out the arm, and it seemed mechanical wise they found the gearbox was binding up causing the motors to fight. They fixed this and now it seems we do not have to do anything fancy with programming. Although, I think we will still do a master and slave setup with the talon srx’s just in case.
3)The mechanical team did in fact use the spread sheets to see if the gearboxes with CIMs would be sufficient to lift the arm. When tested it did in fact lift it. It was fairly smooth and there was no binding.
Now the question is if we will be able to use the encoders as a limit switches for the arm.
Another thing that happened is the arm backdrives down to starting position. Would using the brake/coast mode on the talon fix this? or would we have to program a button that just exerts enough power to keep it stable?
What gearboxes are you using, and what gear ratio?
Turns out we use Mini CIMs that have 100:1 versa planetary gearboxes from vex. They are 3 stage with a 1/2" hex output shaft. The encoders we have are versa planetary encoders that fit right in with the gearbox.
Normally you don’t use encoders as limit switches. You use them to provide a feedback signal (a.k.a “process variable”) to a closed-loop controller, like a PIDF for example.
Another thing that happened is the arm backdrives down to starting position. Would using the brake/coast mode on the talon fix this?
It might, depending on a variety of factors. It would be simple enough to try.
…or would we have to program a button that just exerts enough power to keep it stable?
I suppose you could do that. Most teams would use a position closed-loop controller as described above.