Recently, we’ve been polishing the code for our elevator, which uses two Falcon 500s for movement. The neutral mode of these motors is set to brake, but this doesn’t generate enough friction to hold our elevator at a constant height without falling. While this might be how brake mode is intended to function, it’s still not ideal, and we are working around this by setting the motor’s target position to whatever position it’s in when we stop moving it manually. However, this doesn’t seem like the most effective way of maintaining the position of the elevator (especially during a climb, as if the robot disables while hanging and the elevator slowly lowers the robot, the next time the robot is enabled the elevator jumps back to wherever it was previously). What we want is a stronger version of brake mode.
We noticed that one of the new .setControl() options introduced in Phoenix 6 is “StaticBrake”, which “applies full neutral-brake by shorting motor leads together.” This seems like what we’re looking for, but the wording makes it seem like it could damage the motors. Is this what StaticBrake is, and is what we’re doing an intended use case for it?
Are you suggesting that having the Motor configured with it’s NeutralMode set to brake isn’t enough?
CTR Electronics old documentation says the following…
You can use Talon FX’s ConfigStatorCurrentLimit method to dial in how strong the brake is.
Have you already tried playing with that value at the end of the match for climbing?
I’d be concerned about trying to using a device’s setControl function to have behavior work after the match ends. If you’re talking about during the match then that’s different …
The problem with the elevator not being able to hold a position is for during-match functions (such as shooting into amp), we’re fine if the elevator slides after a match. The problem with our current method is that the elevator would snap back to the last position it was at when it was disabled immediately after enabling, which could hurt someone in our pit if they weren’t expecting it.
I wasn’t aware the strength of brake mode could be modified, but I think adjusting that should solve our problem. Thanks for the help!
You can also ensure your climb mode disengages any closed loop control commands. That way when your robot is enabled again it isn’t just going to the last closed loop control position.
We have manual control without PID and set points with PID. The problem is that after stopping with either manual or reaching a setpoint, the elevator slowly goes down due to the set point PID command ending and manual not having any PID. The current implementation has logic to save the last stop point and PID back to it, but it is difficult to tune, plus we don’t have any experience with combining feedforward and PID. So it currently just uses a P value to hold position (which is separate from the set point PID).
What you are describing IS the brake mode for all the brushless and brushed motors. All three (or 2 for brushed) bottom transistors in the three phase bridge are on.
You COULD set things up where you tell the motor to actively maintain a position…
A PID setpoint command to the motor doesn’t just stop holding position when a scheduled command ends. The motor would only do that if it was told to do something new or your PID gains + feedforward were insufficient. I personally have found that P gain is not enough by itself to compensate for gravity.
Other possible problems…
Your deadband on your joystick might be too loose.
or
Your setpoint keeps updating even when you don’t mean for it to.
Your implementation is attempting to achieve something we have already got working so feel free to take a look at what we did if it helps. You can also download our project and run it in simulation to see it is working.
By “manual control”, we mean a default command that takes in a joystick axis. It overrides the last PID set point with whatever the controller is reading, most likely zero. The logic I mentioned previously saves the stopped position and enables PID to keep it there.