Balancing an Arm

[Tom Line]

As Joe said regarding our and their arm in 2011, we counterbalanced. Our gear ratio was 573 (go mechwarriors!) To 1.

We do not have facilities to make a light arm. If you look at chickens arm from the same year, they were able to fab it light enough that they used s 600:1 reduction with no counter balance.

Holding an arm in position using motors requires stalling them. If you have too much weight and draw too much current, you will fry them. You can always gear down, but then you are trading off on speed

[EricH]

Originally Posted by Brandon_L

Pesky CG, I knew I left something out. This formula would give you an arm that balances at 90 degrees though, no? What about something angular?

It would work for angular. HOWEVER, the distances will change in that case. They'll become closer to the pivot point. There will also be a change in the force vector of the balancer relative to the arm--could be in terms of magnitude; almost certainly a direction will change.

It's kind of hard to explain without going through a diagram. I've attached one with the main equations you'd need for two positions--note that they're the same equations for both positions, but the numbers WILL be different. You use a lot of components when you're working at angles (the component of force in the Y direction, for example).

[Nemo]

How do you balance an elevator? Do you use a torsion spring to reel in cable? Somehow you need to get around the problem of needing to stretch the spring/tubing to 5 times its starting length if the overlap between elevator sections is only 20% (or whatever) of the elevator's stage height, right?

[MichaelBick]

Originally Posted by Nemo

How do you balance an elevator? Do you use a torsion spring to reel in cable? Somehow you need to get around the problem of needing to stretch the spring/tubing to 5 times its starting length if the overlap between elevator sections is only 20% (or whatever) of the elevator's stage height, right?

Constant force springs

[Ether]

Originally Posted by Nemo

How do you balance an elevator? Do you use a torsion spring to reel in cable?

My garage doors are each balanced with a torsion spring reeling in a cable.

[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.