Balancing an Arm

[BJC]

Originally Posted by EricH

Why do you need gas springs or other means of balancing an arm other than its power source?

This is not an idle or ignorant question. I have seen multiple arms with no balancing (other than the power source) that did quite well. Single-joint, multi-joint, even with a large-ish mass at the far end like a game object.
...
Snip
...
Just to bring something up... I have yet to see one of 330's single-joint arms use any sort of balancer that wasn't the drive motors. Neutral for some was all the way down; for others it was wherever the arm was left--one at least needed a little bit of power to maintain a position. Typical drive, 1-2 FP motors, stock gearbox, heavy reduction afterwards (exception: 2x Globe motors mounted on the arm itself--2004). No braking capability.

I don't think there is any reason not to "balance" your arm in FRC. Why would you make your motors work harder then they have to? By making an arm close to neutral your improving the arm's loaded speed and consequently allowing it to take on a greater loads without slowing down. In theory, the only weight the motors should actually be lifting is from the game piece. While 330's single joint "stick with claw" arms weight much less than many others it doesn't weight nothing to the motors like it would with balancing.

[MrForbes]

We've made two arm robots, each with a small motor and a "spring" to support most of the weight. Neither arm was fully balanced, but they did work ok.

Gas springs do not really have a constant force, the force is higher when the spring is compressed all the way. You can play with the geometry of the mounting points, to try to get a more linear spring force out of it, but it will never be perfect.

And surgical tubing also has this problem, even more than the gas spring. The fun part is trying to get the geometry right so that it works the way you want, ie. naturally holds the arm retracted in the "stowed" position, then provides more help as the arm raises up. We haven't been able to do it yet, but one of these years we'll actually design this part of the robot.

The 330 approach of using a lot more motor power, seems to be quite successful. I'd listen to Eric.

[Chris is me]

Originally Posted by MrForbes

And surgical tubing also has this problem, even more than the gas spring. The fun part is trying to get the geometry right so that it works the way you want, ie. naturally holds the arm retracted in the "stowed" position, then provides more help as the arm raises up. We haven't been able to do it yet, but one of these years we'll actually design this part of the robot.

The way we've found some success using surgical tubing is to pre-stretch it a little so that even when its in its most relaxed position, it's still providing a bit of resistance. It seems a lot of the nonlinearity is in the first few inches of elongation, so this seemed to work for us. Then again, arm balancing is the kind of thing you can just get "good enough" at.

The 330 approach of using a lot more motor power, seems to be quite successful. I'd listen to Eric.

There's a lot to be said for just throwing a gear reduction at the problem. It naturally slows your arm down a lot more so you are less reliant on software to control it. Plus depending on your configuration, you can probably self-right your robot. I mean, adding a spring can only help an arm, but if you gear like 330 it's not mandatory.

[ChrisH]

BeachBot design is driven by requirements developed during the design/concept phase. Some of these requirements are driven by the game or rules and others by experience. We call the later "BeachBot requirements". One of those requirements is that the robot will be self-righting to the extent possible. Extreme examples of this were our 2008 and 2010 robots who could right themselves from any stable position, given enough time.

Because we mount our arm motors low and do the reduction in chain between the motor and the pivot point, the arm system is quite weight efficient. Self-righting may not be possible with a "balanced"arm.

Due to our design philosophy of keeping everything as low as possible on the robot we rarely have to use our self-righting ability. Twice in a season during competition would be alot, but it sure is handy (and a crowd pleaser) when you need it.

Every design has its trade-offs. We like using brute force in the arm because it helps with secondary issues. But there might be a good reason for using a balanced approach. Just be aware of what you might be loosing in going with a particular approach

Originally Posted by Chris is me

There's a lot to be said for just throwing a gear reduction at the problem. It naturally slows your arm down a lot more so you are less reliant on software to control it. Plus depending on your configuration, you can probably self-right your robot. I mean, adding a spring can only help an arm, but if you gear like 330 it's not mandatory.

[DampRobot]

I'm more than a little surprised that there is some debate on this thread whether or not arms/elevators should be balanced. In my mind, this is sort of a no-brainer.

As affirmed by JVN and other designers from teams like 148, 111, and 254, balancing an arm or elevator increases it's speed while decreasing current draw. The less weight that must be overcome by the arm/elevator, the faster it can be geared. While it's not too difficult to slow an arm down, it's very hard to speed it up. As the drivers (and software) adapt to the higher speed, performance benefits will become apparent.

I hate to pull out the old "you can always slow it down in software," but I feel like I need to. Most beneficial effects of large reductions (non-backdrivability, high resolution) are the kind that can be essentially duplicated with good software. The only benefit mentioned in this thread that cannot be duplicated with a balanced arm , self righting, is really not a huge advantage 99.5% of the time. Sure, it's nice, but I'd much rather have a quick arm.

[MrForbes]

Originally Posted by DampRobot

I hate to pull out the old "you can always slow it down in software," but I feel like I need to. Most beneficial effects of large reductions (non-backdrivability, high resolution) are the kind that can be essentially duplicated with good software.

We have enough trouble getting an arm balanced....and you expect us to be able to develop good software too?

[Andrew Schreiber]

Originally Posted by DampRobot

I hate to pull out the old "you can always slow it down in software," but I feel like I need to. Most beneficial effects of large reductions (non-backdrivability, high resolution) are the kind that can be essentially duplicated with good software. The only benefit mentioned in this thread that cannot be duplicated with a balanced arm , self righting, is really not a huge advantage 99.5% of the time. Sure, it's nice, but I'd much rather have a quick arm.

Yes, you can "always slow it down in software" but personally I would prefer a mechanical reduction. Reducing speed in software is going to make your motor run harder. Maybe not an issue if you are using something like a CIM but if you are running the FP/BB style motors which are actively cooled by a fan when running you may be asking for trouble running them slower. Additionally, as much as I hate to admit it, software isn't perfect. Sometimes we get weird edge cases that are inadequately tested and an arm that moves physically slower means we have more of a chance to kill the power before it breaks something.

[Jon Stratis]

One point I haven't seen on here... try to avoid a situation where you're driving around with the motor stalled most of the time! The way we had our elevator set up 2 seasons ago, we had to be driving it down in order to pick up tubes. As a result, most of the match it was either stalled going down as we went after tubes, or stalled going up as we attempted to hang. We ended up burning out a lot of FP motors that year! There is some debate between myself and another mentor as to the reason for the burn out... he thinks it was due to friction in the elevator, making the motor work more to raise/lower, while I think it was due to the motor being almost constantly stalled!

All that said, counterbalancing any moving part, whether linear or rotary, isn't necessary in our applications... but it is a simple tool to use to get increased speed at a decreased effort!

[Ether]

Originally Posted by Andrew Schreiber

Reducing speed in software is going to make your motor run harder.

^This.

Here's a rather contrived example, but it illustrates the point.

Suppose you are using a BB550 motor to raise an arm, and you want to drive the arm at 15 rpm (90 degrees per second) at a torque of 500 oz-in.

If the total mechanical speed reduction from motor output shaft to arm rotation is 10:1 you'll be drawing ~60 amps

If the total mechanical speed reduction from motor output shaft to arm rotation is 50:1 you'll be drawing ~12 amps

[JVN]

Originally Posted by DampRobot

As affirmed by JVN and other designers from teams like 148, 111, and 254, balancing an arm or elevator increases it's speed while decreasing current draw. The less weight that must be overcome by the arm/elevator, the faster it can be geared. While it's not too difficult to slow an arm down, it's very hard to speed it up. As the drivers (and software) adapt to the higher speed, performance benefits will become apparent.

The bigger advantage of course is that if you reduce the load your motor needs to lift, you can use a less powerful motor to accomplish the task at the same speed. 148 (and 217) have used a single globe motor as our shoulder joint in years where many other teams are using a CIM or 1 or 2 FP motors...

The weight of the arm is (reasonably) balanced, so the motor just needs to lift the weight of the game object.

-John

[wireties]

Originally Posted by JVN

The bigger advantage of course is that if you reduce the load your motor needs to lift, you can use a less powerful motor to accomplish the task at the same speed. 148 (and 217) have used a single globe motor as our shoulder joint in years where many other teams are using a CIM or 1 or 2 FP motors...

The weight of the arm is (reasonably) balanced, so the motor just needs to lift the weight of the game object.

-John

And Team 1296 dutifully read the awesome JVN blog and did exactly the same thing! We used surgical tubing to save costs. Our arms worked beautifully - now if we can only make more elegant grippers...

I saw a couple of references to "slowing things down with software" in this thread. In general it is good practice to never ask more (with your software) out of a motor than it can give. Don't design software that asks the motor and the appendage to violate any laws of physics. This is often as simple as adding a trapezoidal velocity profile (or let the PID classes do it for you) or filtering the linear input from the driver station with a cubic function.

HTH

[Brandon_L]

Originally Posted by JVN

The bigger advantage of course is that if you reduce the load your motor needs to lift, you can use a less powerful motor to accomplish the task at the same speed. 148 (and 217) have used a single globe motor as our shoulder joint in years where many other teams are using a CIM or 1 or 2 FP motors...

The weight of the arm is (reasonably) balanced, so the motor just needs to lift the weight of the game object.

-John

Im quite interested in how 148 decided on where to have your arm balanced. Just straight out horizontal? Or something game specific like near the top rack in logomotion?

I didn't mean for this to turn into a "balancing an arm vs gearing" thread, I was more interested in methods of balancing an arm. Not that I'm ruling out any of the pro-gearing points, just looking into balancing at the moment. It seems like the easiest way would just be surgical tubing. I'm just concerned with how you decided where you want it balanced now.

[Alan Anderson]

The TechnoKats "Overdrive" robot had a perfectly counterbalanced windmilling trackball manipulator mechanism. It used a pneumatic cylinder which could be selected to two different pressures in order to balance it both empty and when holding a trackball. The design feature that made it perfectly balanced in any orientation was that the cylinder was connected to a sprocket that turned with the "arm", so that it applied maximum upward force when the arm was horizontal and zero force when it was vertical. The arm would stay exactly where it was placed with no motor power applied at all.

The main benefit I saw of the perfect counterbalance was in the control software for setting the arm position. Gravity simply was not an issue, and a single set of PID constants worked for the entire circle of arm travel. As a programmer, I consider the fact that we didn't burn out Fisher-Price motors by stalling them against the weight of the arm to be of secondary importance.

[JVN]

Originally Posted by Brandon_L

Im quite interested in how 148 decided on where to have your arm balanced. Just straight out horizontal? Or something game specific like near the top rack in logomotion?

In 2011 we disconnected the motor from the gearbox and balanced at about horizontal as baseline value, then tweaked until the drivers & programmers were happy. In some years, we've had to reduce this amount due to the arm lifting up at the starting position. In 2011 we had a very simple "drive until position, then cut power" control scheme. Combining the Victor brake-mode with surgical tubing balance and this control allowed for easy pre-positions.

We tuned in surgical tubing & position code through iteration -- test, tweak, repeat. (Iteration is always the answer, of course.)

In my experience, it is better not to overthink it, just add some surgical tubing and tune it to taste...

-John

[IKE]

Originally Posted by JVN

...
In my experience, it is better not to overthink it, just add some surgical tubing and tune it to taste...

-John

This is important for many things that invovle tuning. I am a huge proponent of "doing the math", but often in development cycles, you plan to get close, and then tune for optimum performance.
When doing any sprung element development on a car (springs, shocks, bushings, engine mounts...), you typically will do analysis and design to pick a nominal, and then have a tuning set of +/-10% to +/-50% to see how changing the rate might help performance. The reason for this is usually, your analysis is based off of some assumptions. Without tuning, the quality of the output is reliant on the quality of the assumptions (which sometimes are poor). Planning for some tuning can vastly improve this.

With things like balancing an arm, you can use the:
"JVN says balance at horizontal" as a rule of thumb, but then try a little extra and a little less and see what works best. If you vex robot works best with it tuned to balance when feeding in the trough... then that is the ri9ght answer for you and your robot. If your robot works best with just a little bit of assistance to keep the motors in the friendly half of the power curve... so be it.

You can get pretty fancy with the way you do the counterbalance as well. Using "over center" principles, you can get some nice variation in forces. The gas shocks on a minivan liftgate are a great example of this. At almost closed, the forces in the shock are at their highest, yet they offer very little lifting force due to the hinge and the push point and the reaction point nearly being in line. This makes it easy for the gate to stay at or near closed. Yet, when fully extended, the shock is at its weakest from a force in the shock, but it is able to hold the liftgate up all by itself. Pretty neat when you think about it.

You can also get this behaviour using bungee and "cams" to change the lever arm length that the bungee has. This can have some very neat and dramatic effects.