We are using a wrist mechanism which has a max planetary gearbox attached to a chain. We have an issue where even when the motor is on brake mode, the mechanism can rotate, causing us to slam the wrist into the arm when we drive. Is there any way to reduce this? When we rotate it, both shafts are spinning before it brakes so it doesn’t look like the chain is the problem.
Imagine this but with a max planetary on the falcon
What ratio is your planetary gearbox and the weight of the mechanism attached to your wrist and also the length from the wrist to the end of the stuff attached to it. All of those values determine how much force is needed and if the current mechanism and gearbox are correctly sized.
Solutions in general:
A larger diameter sprocket at the second point and a smaller one at the output shaft of the gearbox will increase your torque and give you more control over the wrist, but it will be slower overall.
Drive the wrist from multiple points on both sides, or closer to the midpoint with one motor. If the shaft from the second point went fully across the frame instead of just moving the whole wrist on one side and letting the other side drag. Right now you are moving the whole mechanism by its side, not from the middle and that’s harder on the motor. It’s like trying to lift a plank of wood from the end instead of closer to the middle. Even rotating it takes more effort from the end rather than in the middle.
Assuming you aren’t skipping the chain (the design shown should prevent that just fine), I’d say there are two basic options, increase the reduction or add damping. Increasing reduction is as simple as adding a stage to the MaxPlanetary, so that’s probably the easiest fix. Adding damping is more complicated, you are basically trying to add friction to the system, this could be some homebrew solution where a block of plastic rubs against a plate as the wrist rotates, or you could find a COTS damper or shock absorber that fits your application.
If you want software to fix a mechanical problem, you could try a powering the motor into a deadstop rather than just putting it in break mode, but you’ll be wasting energy, reducing the lifespan of the motor and making your programmers hate you so try to avoid this.
If the motor is not being back driven when the arm moves, you have a backlash problem so check that the motor is actually having to move for the wrist to come free. If backlash is a problem, check every connection and joint for play and eliminate it by tightening chains, directly bolting gears and sprockets to the driven mech rather than relying on the hex shaft to hold torque, shimming or cross pinning loose hex bores,…
Larger diameter drive/driven sprockets in general will be less affected by backlash in the chain ( I.e. 1/8 inch of slop on a 4" diameter circle is half the slop to circumference ratio than 1/8" on a 2" circle). A lot of teams seemed to miss this detail last year with joints in arms driven by small diameter sprockets and subsequently ran chains really tight which caused shock loading to spike and chain to stretch faster or break.
You can also dampen with rotary dampers, gas springs, gas shock, or even some friction material (think drum brake, but just dialed in with a jack screw and adjusted as needed)
Also of note, those hex shafts can wind up a lot. In other words the shaft may be like a torsion spring depending on the length and moment imparted on the end. Solution to this in this application is probably a larger OD tube as an axle.
Assuming that backlash is not the problem (which it very much could be), instead of putting the motor in break mode, have it PID to the last set position instead of using brake mode. Brake mode doesn’t force the motor to stop, it just makes it fairly difficult to move. PID or any other feedback controller will instead reject disturbances aka things trying to move the wrist by powering the motor to oppose any applied torques.
The motor in brake mode will not stop the motor from spinning. Higher reductions suggested above will help. But. You will need either active position control on the motor or a mechanical brake to hold the wrist in position.
The planetary is a 60:1. The weight is about 10lbs and the center of mass is about a foot from the pivot. Which gives me about 11Nm torque. The falcon has a stall torque of 4.69Nm. So a 60:1 ratio should be sufficient.
I’llLimelight, an integrated vision coprocessor likely solve it by applying a small amount of power to the wrist when it’s in brake mode to keep it stationary. Is there any problem with stalling a motor if it’s low current? (5-10A)
Stalling a motor at low current is fine in most cases.
However, brake mode won’t do anything when you are supplying power to the motor as it can’t short the leads together and apply power at the same time. If you want to apply a small amount of power to keep the motor up, you really want to use a feedback controller to keep the motor in position.
You can check the motors.vex.com charts to see what current level is safe for your motor.
100% the right move here is to use a PID loop to hold position. If your ratio is high enough you won’t even need to add a gravity compensation, but you can add kG*cos(angle) to your output command to help it overcome gravity. You can measure kG using the FRC characterization tool, or by just seeing how much command it takes to hold the arm level. “Close enough” is fine, as the PID loop will shore up the edges.
You probably have at least 2 stages of gearing to get the 60:1 reduction. Each stage will have some gear lash and they add up, multiplied by the previous stage. Putting the motor in brake-mode will not help with the gear lash. You might be able to use a feedback loop to compensate if you put an encoder on the output rather than using the encoder in the motor.
I recommend going way overboard on the ratio. We use 100:1+. With typical rotation limits of 90-180 degrees the speed is not that important. The resulting required torque means you can safely stall any of the bigger motors indefinitely. Some care needs to be taken because the motor will break things at that reduction if allowed to. I really like the AndyMark sport maxes for this. I don’t have enough experience with the Rev Ion to have an opinion, but they pack nicely with the Neos. You want to put the encoder on the output side of the gear box or directly on the arm so there is minimum lost motion with the encoder. You are going to have some lost motion in the gear train and chain. The lost motion does give issued with the position control.
You can use an external encoder but with the neo you’llLimelight, an integrated vision coprocessor also have encoder built into the motor. You could track both sides. Output is what you want for control though.
That is true. We go both ways. To use the motor encoder requires a way to time it or to set the zero. But then it easy to use the motor controller’s built in position control. Putting it directly on the arm lets use an absolute. controller. Nice feature on the Neo is you can plug the remote encoder directly into the motor controller. You can get close to the same thing using a cancoder on a CTRE MC.
Passing on a couple of lessons learned the hard way:
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.