Re: Balancing an Arm
 

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

Re: Balancing an Arm
 

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).
Attachment 13266

Re: Balancing an Arm
 

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?

Re: Balancing an Arm
 

Constant force springs

Re: Balancing an Arm
 

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

Re: Balancing an Arm
 

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

Re: Balancing an Arm
 

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.

Re: Balancing an Arm
 

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

Re: Balancing an 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.

Re: Balancing an Arm
 

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!

Re: Balancing an Arm
 

^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

Re: Balancing an Arm
 

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

Re: Balancing an Arm
 

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

Re: Balancing an Arm
 

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.

Re: Balancing an Arm
 

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.