Hi guys,
When I use motors to control elevator lifting or intake opening and closing, to maintain the position , I should let the motor stop and hold the position by damping(gearbox and motor brake) or I can rely on the motor’s continuous output (but it would make buzzing noise🥲)
I would strongly recommend using feedforward. This helps you maintain the setpoints. You can use Sysid or tune these constants manually. Feedforward control is heavily used and you can construct an elevator feedforward object and apply it to the motor.
4 Likes
Both are valid options depending on your mechanism needs. A 3rd option would be a mechanical brake (a common design is a pneumatic actuator and a bicycle disk brake).
The feedforward approach @Kartikr27 mentioned is one way to implement the continuous motor output.
1 Like
Hello! For what it’s worth, “what should I do?” questions are hard to give a single answer on. Even if we know every detail of your setup and all your design goals, a lot of these choices still involve “engineering judgement”, trying both options to see which is better, or just making an arbitrary choice and moving on.
What you’ve posed is a great example of a systems engineering question - it has little to do with the exact details of the motor, gearbox, or software involved. Rather, it has to do with the macro-level selection of a design strategy to cause a mechanism to achieve a goal state. The final answer will require knowledge of software, electronics, and mechanical systems simultaneously.
The answer always starts by understanding the scenario - you have to know which details are relevant to the decision.
If I were in your shoes, here’s how I would parse the relevant details:
You have a mass which is constrained to travel up and down, but is suspended by a motor-powered gearbox & pulley arrangement. Presumably you have some way to measure the vertical position, and one or more goal positions that you want the mass to stay at for certain periods of time. Gravity will pull downward on the mass.
Gravity can’t be turned off (citation needed), and its force will not result in maintaining a goal position. Therefor, you have to design a system which fights gravity’s effects in just the right way to achieve your goal.
IE: you have to provide some upward force to counteract gravity.
As you and other posters identified, there’s a few ways to do this.
Static Friction
One way is to ensure that that, when unpowered, the maximum static friction of the motor/gearbox/pulleys is great enough that gravity won’t overcome it, and it will stay in place.
This is very simple from a software and electrical perspective. However, it has some downsides. For one, it’s hard to accurately design in the inefficiency needed to get static friction large. High-reduction gearboxes and not greasing some components will get you there, but you’ll probably need to design with a high margin of error. Any dynamic load (vibration, gamepiece, robot collision) could cause forces greater the max static friction and cause the mechanism to slip out of position.
Furthermore, you can’t turn this inefficiency on and off - it’s always on. This means that when it does come time to move the mechanism up and down, the motor has to fight against the frictional forces that previously pinned the mechanism in place. Not the end of the world, but you might chew up battery capacity doing work that isn’t useful, and will probably have a slower max speed of the whole mechanism.
Should you do this? Well, it’s easy to try to see if it works. And if it works, well… go for it! However, it’s hard to say up front whether this will be sufficient or not.
Active Motor Control
If static friction fails, the next obvious answer is to use the motor you have at your disposal.
At a minimum, the feedforward voltage should be chosen to produce upward force which is equal to the gravitational pull downward.
A feedback voltage can also be added in to correct for errors in position away from the goal.
This strategy is much more flexible, as you can tweak the exact behavior of the system in software (easier than hardware), and reject a much wider range of “disturbance” forces that knock you away from the goal.
However, as you mentioned: Yes, there is a “buzzing” noise that often happens when a motor is given a small amount of voltage while stalled. The noise itself isn’t bad, but rather you have to worry about power dissipation in the stalled motor. Some motors can be stalled indefinitely, but not all. Whether a motor “works” in this application will at least depend on how much voltage you are sending to it, and how long it needs to sit stalled.
For example, here’s a CIM motor’s locked rotor stall test data:
At 6 volts, the CIM motor’s output force degrades, but the motor can keep running for at least 300 sec straight.
At 8 volts, the CIM motor fails after ~175 seconds. Higher voltages cause it to fail faster.
The exact numbers will be different for different motors, but the end result is the same: Depending on the situation, this may or may not be a viable strategy.
Mechanical Brake
A third option as other mentioned is using a device designed to prevent motion to lock your mechanism in place.
Using something like this requires that you do both the software and hardware work to integrate it into your mechanism - it has to be mechanically attached, and the software has to be written to grab/release the mechanism at just the right time. You’ll also need a way to actuate it, possibly involving a servo or pneumatic cylinder.
However, if you can get that right, it allows you to reject those large “disturbance” forces without having to worry about your motor’s longevity.
TL;DR
Engineering is all about tradeoffs. There are few universal design answers.
20 Likes
Another one worth mentioning: instead of adding just friction (which opposes motion in multiple directions), you can add other counteracting force (which is always opposing gravity). It can be in the form of counterweights or springs. This doesn’t solve the problem on its own, but it reduces the holding force required to a more manageable level, to the point where you may have enough static friction to hold, or if you choose to stall a motor, it won’t need as much holding current.
Check out the big constant-force spring in the middle (strip of metal, wrapping up on a spool), trying to lift the elevator carriage up. This works against gravity trying to pull the carriage down. The motors do the rest.
5 Likes
For FRC: 99% of the time these days, the answer is closed loop control. That is, PID control + feedforward to eliminate gravity factor. Now you can also do things like add a constant force spring “counterweight”, but unless you have a heavy load or something that needs to move very very fast, 1-2 motors is enough to drive your mechanism at high speeds.
In any case, you should definitely know how to do PID with a feedforward, so unless your application is really out of the ordinary, take the time to learn.
4 Likes
Thanks you guys’ suggestions. Actually, we are indeed using PID control. We just concerned whether the motors get damaged if it stays in stall state for too much time. (falcon 500 is really expensive🥲)
My vote is counterbalancing.
Billions of garage doors and their tiny openers can’t be wrong. Lets not forget all the car hoods, trunks, and hatchbacks out there.
Constant Force Spring Kit (thethriftybot.com)
Motors don’t get hot.
No battery drain when the robot is doing nothing.
All motor power goes to moving the mechanism which makes it faster.
PID tuning can be the same going up and down.
4 Likes
Check the constant current tests on motors.vex.com. You can stall a Falcon for a long time as long as it’s at low current. At 30A or below, it seems to go for a long time.
This should be the case anyway.
2 Likes
Don’t forget the anti guillotine properties of mechanical counterbalancing when the robot is turned off! 
1 Like
You are correct.
Yes the PID should be the same but…
If you use F to get rid of gravity, it chews into the headroom that can be used to move faster. I guess that is what I’m getting at.
3 Likes
This year I found out that 2 Falcons will destroy a WCP elevator kit long before I unleash their full power. Unless you’re dealing with something seriously chunky, like lifting a robot or a very heavy arm, counterweights aren’t worth it anymore. They can be a pain to integrate and loosen up over time, changing the dynamics of your system. If I eally need more than 1 brushless motor’s worth of power, I just add another motor.
Gravity compensation is practically a rounding error in terms of limiting your motor output. Recalc shows that a 20lb elevator geared for 12ft/s with 2 NEOs has less than 10% output for gravity compensation. If you really need that extra 10%, reducing the weight of your mechanism is a lot more important than counterweights because the sheer force of accelerating the load will put huge stresses on the mechanism unless you reduce inertia. 115 had cables slipping and tubes bowing out until we reduced speed to 30% of max. Part of that is just how the kit is constructed, but mechanical limits are real.
1 Like
Not gonna lie even if an elevator is light enough to not need a spring, this is helpful enough to justify adding one in my opinion.
(yeah yeah CF springs can be dangerous etc etc, but I’ve just seen more people get hurt by unpowered mechanisms dropping than CF springs)
2 Likes
But the amount of force needed to counteract gravity is different at different angles, so a CF spring would be too much at a certain angle, and not enough at another…
Or is the equation in my head missing some factor?
1 Like
There are ways to control for this cosine error. You can make things cancel out with a linkage.
not a CF spring, but Raid Zero had a wonderful solution in their 2023 bot
1 Like