We are making an articulating arm for our robot. we have a cim motor on a CIMple gearbox with a gear chained to a much larger gear which is connected to the arm itself.
our problem comes when we are running the arm. we would like to be able to move the arm to any spot we want and have it stay there when we let go of the joystick. currently when we let go of the joystick, gravity takes over and the arm falls down. I’m asking if there is a way to keep it in any place we stop at. do we use a brake to create resistance or do we use encoders? if we have to use encoders we would need help in figuring out what our distance per count is among other settings in the programming side of things.
There are several ways to solve your backdrive problem (that’s what it’s called)
The mechanical solution, guaranteed to work, would be to replace your CIMple box with a wormgear. It cannot be backdriven. This is the same type of gearbox as comes preinstalled on the window motors.
A simple software solution would be to switch the jaguar controlling your CIM from coast mode to brake mode. This is likely to be not 100% successful, however.
A simple mechanical solution to this problem is to add a “counterweight”, or something similar, to balance out the weight of the arm. Many teams have used gas springs in the past to do this, example here. Latex tubing could also be implemented as a spring to counteract the weight of the arm and would likely be cheaper.
Yes, it has to do with one of the jumpers. It should be documented in the Jaguar docs.
To solve this in software, you would attach an encoder to one of the shafts and then use a PID loop to control it. There are a couple of papers in CD-Media about how to tune one and what one is. A PID loop can be thought of as attaching a software spring to the arm to help hold it up in position. The P term is probably enough to at least get you started, and is easier to understand than the rest of them when you are first starting out.
I would use one of the window motors included in the KoP. They’re intended for this sort of thing. They have a screw drive gear box on them, so they’re a little slow, but they have crazy torque and can hold a position with a load on it.
A DC motor converts electrical power to mechanical power. If you remove the input voltage and spin the mechanical side, the motor becomes a generator.
As a generator, if the electrical terminals are open, there is no current and the “drag” of the motor on the mechanical system is at a minimum (just the frictional losses are felt).
However, if you short the electrical input leads to the motor, it generates electrical current from the mechanical system. This requires that the mechanical system to do more work hence, the motor resists the rotation.
So, for either the Jaguar or the Victor, if the brake/coast jumper is set to “coast” the motor offers the least mechanical resistance that it can when commanded to no speed. Likewise, In the “brake” position, the speed controller will offer the greatest mechanical resistance to rotation when off.
You may wish to consider using the jaguars for your arm… they can take a feedback circuit from a potentiometer at the joint and then (using settings that you provide) attempt to provide sufficient power to the motor to move to and hold the position that you want.
Alternatively, labview offers a similar PID routine to control arm position. You’re looking for a “closed loop feedback” system, where your driver is entering the arm position data and leaving it up to the robot (either the cRio or the Jag) to figure out how to achieve that position.
Note that this requires using the CAN bus… not the PWM cables.
Note also that this is the second step towards a solution… the first, as advocated earlier, is attempting to counterbalance the “dead weight” of the arm with springs or counterweights.
Jason
P.S. Unless your arm joint is exceeding the range of a potentiometer (usually around 270 or so degrees), I’d recommend using a pot rather than an encoder. It is simpler to just read an analog input than to zero and track an encoder.
our team has never used pid or CAN. do you know where some resources are for us as far as programming with pid and CAN and connecting the Jaguars via CAN?
About the window motors, I was told that the screw drive in them does not allow for back driving. and aren’t they far too slow to be effective if reaching the top rack? just wondering plus the thermal lock on them could be a problem…
If you intend to use the motor alone to hold the arm up, without any mechanical counterweight or spring-loading, be cautious. You’ll be running the motor at or near stall a lot of the time. A CIM can handle that for a while, but it will get very warm and you might want to consider a way to cool it off during or between matches.
A Fisher-Price or Banebots motor will not handle that kind of abuse well at all. They rely on an internal fan to keep their windings cool, and if they’re not turning, neither is the fan. You’ll melt something in short order, followed by smoke. Nearby veterans will sniff the air and nod at the familiar smell of a fried motor.
:eek: Well thats not good then. We were going to use a Banebots motor hooked up to last year’s gearbox with a chain to power our four-bar shoulder joint. we were going to power the robot drive with the four cim motors, but is that necessary? should we just use two there and use a cim to power the arm?
You can still use the BB for the arm, but understand that the BB will not like being anywhere near stall for any significant period of time. This means that you should design the torque that the motor needs to apply to keep the arm up to be significantly less than the stall torque (1/4 or less of the stall torque. I don’t have a good number for this). Adding a second BB if it looks like it’ll take much torque on the motor to keep the arm up will help. It wouldn’t hurt to also put a fan blowing across the motor to cool it when it isn’t spinning.
971 used 2 FP motors in a single joint arm in 2008, and it worked just fine. We had way too much power in the joint, which meant that the motors weren’t loaded very highly.
This isn’t quite an elegant solution, but you might consider adding a window motor to the system geared/matched to the RPM at one of your rotating joints in addition to the BB motors you’re using to rotate the arm. The window motor’s worm gear could help to lessen the need for the BB motors to operate at/near stall to hold your arm in place.
I think you are confusing backdrive and drive backwards. If you reverse the voltage to the motor, it will drive in the other direction just like any of the other motors.
What people mean when they say you can not backdrive the window motor is that you can’t physically turn the motor by turning the shaft (the problem the OP is having).
OH! thats what that meant. my bad… that opens up my options again! thanks! at about how long of straight running will the window motors thermal lock kick in?