By adjusting pressure you can quickly dial in the right counter-balance force, the force is constant instead of displacement-dependent like many springs, and it tends to damp the arm’s motion, making position-holding easier. In the implementation pictured above we clocked the air cylinders’ mounts so they would always tend to bring the arm to perfectly vertical.
Very interesting thread. The documentation for the versa planetary gearboxes says that you shouldn’t use extreme gear ratios. I’d like to use a mini cim with something in the ballpark of 200:1 to move our arm. Is this a bad idea?
You can find the VP Load Ratings Guide on the product page here. (The document is here)
According to the ratings guide, a 200:1 gearbox cannot hold the torque of a Mini CIM. If you look on page 6, you’ll see that the entry for stage -> Mini CIM -> 200 is red. That means that it’s likely to break.
This year’s arm has a CIM hooked to a ridiculous worm gear. It won’t stall. That being said there are two options being cooked up for counter balance. One is a pneumatic cylinder at constant pressure. The other is based on some sort of cord reel. This is mostly to reduce current draw on the upstroke and to make for less oscillation in a rather long lever arm. Last year we had an elevator with a winch for the “up” function. It was also CIM based and we used a Toughbox Mini with the other position holding the shell of a mini CIM. A small pneumatic toggled down on the rotor of Mini to freeze and down drift and keep the CIM from having to work at all in static mode. Worked very well albeit more work, and more learning, than some of the other options mentioned.
A good way around this sort of problem is to have one final reduction in sprockets. You could use a 16:72 sprocket reduction and a 40:1 - 50:1 VP reduction with a MiniCim for comparable motor loading and will keep the planetary transmission within its load rating. This approach may also let you mount the motor in a lower/more favorable location.
We had not thought of the disc brake - is there one in particular that teams like to use?
On a suggestion here, we’re trying the ones below. The hole pattern appears to closely match the vex versa-whatever pattern on their bearing blocks. (Note: ignore the negative ratings – most of them are about ‘this doesn’t work on my bike’)
This is the one my team has used in the past, including on our elevator last year (and probably on our arm this year) - it worked without any problems or adjustments through 2 regionals, champs, 2 off-season and countless demo’s (which was important, as it was basically impossible to access in our design):
It’s cheap, has the same bolt pattern as the AndyMark hubs, and you get 2 of them in the box, along with the cables and calipers. It comes with hubs pre-installed, you’ll need to remove those first (the bolts used are metric, and stick a bit - if you use a standard allen wrench instead of the proper metric one, you’ll probably strip them).
We have one like the one that CEF and Jon have used. The bolt circle is 45 or 46 mm which is just a bit smaller than the 1.875 inch bolt circle on the AndyMark and VEX hubs. We used a 3/16" drill bit to make the holes in the hub oval so the #10 screws can go through the brake disk. Don’t worry if the brake disk is not exactly concentric with the hub. It is not going to be spinning quickly.
We are going to use a small pneumatic cylinder to pull directly on the cable. A stroke of 1 inch works well for the brake caliper we have. We will make a bracket for mounting the cylinder and give the cable sheath something to push against. Some friends on other teams have used this arrangement successfully last year.
We ran the cable elsewhere to actuate it - it’s a little simpler to use the cable, and it allows for better packaging. Just remember that both the cable and the plastic sheath around it are important - you need to pass the cable through a hole (or something similar) that retains the sheath, so you get the forces to work properly.
An update on this: we did all our math (I love these kinds of lessons with kids) and it actually worked out that thing the mechanism is less than 5 lbs and on a relatively short arm we can get away with a bag motor with 250:1 of reduction and it still works fine even at 0.2 motor power. It probably needs a bigger gear ratio, though I guess we could also set the max power even lower. The mechanism will likely be in a parked (motor off) position a lot of the time, too. We are starting our full-blown test phase this weekend so we’ll see how it holds up. If not, we have a backup plan.
On another note, we got motion magic to work for the first time as well. I am pleased with the progress that the team is making on the robot this year.
Thanks to everyone who provided feedback - it’s been really helpful.
I am guessing that you are using the “Rotary Mechanism” tab in the JVN calculator. I had gone through the same calculations with my team and posted a question about the speed of the arm. The posts by @MrForbes, @AriMB and @GeeTwo gave a lot of good information on what to aim for when designing such an arm and why.
We’ve moved on from getting the motor to hold position (that seems to work pretty well) to now making sure it doesn’t kill anyone or disassemble the robot. The arm comes down pretty hard to the floor. We’ve tried a number of different PID settings. I’m guessing that bungee will help, but at this point (as a non-engineer) I wish I could get someone in here to help these kids who knew what they are doing!
We actually have two short arms on our robot and the shorter one is well-behaved and doesn’t move too fast, but the larger/slightly heavier one (same gear ratio and motor, less motor power given via command) is the mildly violent one.
So we are digging though the TalonSRX docs today and trying to figure out how to calculate arbitrary feedforward to offset gravity. If anyone has an ELI5 summary for that, I’d love to hear it! We are inexperienced in this area.
As you already have the mechanism built, the quickest and best way is not to calculate feed forward but measure it. Set up the motor to be NOT in a PID mode, but directly controlled by a joystick, or even better, throttle potentiometer. Work with it and figure out what throttle is required to hold the arm in place; that’s at least your start point, and likely your finish point, for feed forward. If you really want to do this right, you might try it both with and without the game piece and with a fully charged and end-of-match charged battery, and average all of those.
So basically the power required (between 0 and 1) becomes the feed forward term?
Can feed forward be negative? It seems to do okay coming back up, but the problem is going down. Or is there some way to use one motion profile in one direction and another in the other direction? Thanks