We’re using four Falcon 500s as drive motors on a 6-wheel differential chassis with 10ish:1 gearboxes. Java code using the Talon FX class is working as expected so far. I’m impressed with the fine resolution of the encoders compared to the external ones we were using before.
Historically, we’ve used Talon SRX controllers directly connected to encoders for all kinds of systems, with frequent use of both PID velocity controls for intakes and shooters, and also built-in PID position controls for things like elevator positions, arm positions, and even drive wheel positions (it does pretty good drive/turn/drive automation even without with the trajectory library. We even managed to drive the Infinite Recharge at Home courses using that technique.)
Another use for the PID position controls when it comes to drive wheels is to tell the motors to go to the position where they’re already sitting, and viola – active braking. If you’re trying to hold a defensive position, set the brake and the robot will actively push back against any efforts to move it.
That’s especially relevant this year where balancing is going to mean driving to a spot and braking. Once our driver has centered on the balance, we want them to hit the parking brake, and no matter what our teammates do, we want the robot to actively fight any movement and stick to a spot like glue. So far, it works great. We even have a fine-control for the driver so that if they move the stick while in brake mode, it slowly shifts the position so that they can adjust the balance point in an entirely linear way by shifting by inches without having to do difficult power modulation compensation manually for what could be a wildly tilting platform.
So here’s my question: Is there anything we can do about the Falcon 500 motors screaming their heads off when using this mode? As soon as they have to start pushing hard against resistance (such as another robot or a tilting platform) and they equalize to achieve the desired not-moving state, the stall warning activates and the motors all start the mighty falcon screech.
It’s actually a multi-part question: Can the alarm be deactivated? Is there a work-around to prevent stalling by rapid cycling or something weird? Is this warning actually relevant in that we might be damaging the motors? It seems unlikely since so many teams use these motors for driving, and driving against an obstacle and stalling the wheels is an extremely common occurrence. We got the squeal driving against a wall manually even without position controls being active. So why don’t I hear screaming falcons constantly at every event? I feel like I’m missing something.
When the falcons are “screaming their heads off” as you put it, that is an alarm indicating the motor is stalling. The stall load (the torque that it takes for the motor to not spin while sufficient power is applied to the stators) is 4.69 N-m. There’s also a current stall (when you are applying more current than the motor can use) of about 257 amps.
The torque is most likely what is causing the stall alarm, because there’s (hopefully) no way you are drawing 257 amps of current. This simply means that the motors themselves aren’t able to fully handle the load they are trying to pull. On a drive train this can happen when you are rapidly changing directions (because inertia), or if you are trying to move through something that is stronger than your drivetrain (i.e. a wall or another robot). This can’t be disabled because it is a critical safety feature. Say you (somehow) had a faulty breaker and (somehow) were trying to draw 257 amps of current, it’s highly likely that something will permanently damage itself.
It’s really annoying (we had this problem with our shooter last year) and there isn’t anything you can do about it because you simply can’t change how strong the stators in your motor are. As long as you aren’t constantly overworking them, it should be okay though.
I don’t think these are two separate thresholds. If you apply 100% PWM and have a perfect power source with the motor locked, you will see 4.69N-m of torque and 257 amps of current. When this happens, the motor will also squeal at you for some reason.
But, the motor will also squeal if it’s stalled holding an arm at like 20% power. Maybe only drawing 20A or so. At least that’s what we experienced with our arm prototype (unless I just didn’t notice that our gear ratio was so bad that it was cooking itself at like 60A)
Do any valued customers with Phoenix Pro know if the motor still squeals when using FOC? I wonder if the squeal could be a product of some weird commutation strategy they use? I know why it would happen with sensorless commutation, but I know the normal Falcon commutation is sensored.
The alarm is your friend, it’s telling you there is a problem.
There are multiple ways to reduce the torque load on your motor controllers.
You will need to conceptualize the open-loop controls differently from the closed-loop controls (more than likely) but here’s some thought to it in a basic form.
If you can limit the acceleration demand of a motor, your torque demand will be smaller, and your motor will be less likely to stall. How do you limit acceleration?
For simple open-loop control using the joystick, the WPILib SlewRateLimiter works quite well. Given that you have a fancy Falcon, and a motor controller with it, you can use the built-in motor controller functionality to do the same thing the SlewRateLimiter does. Read into the talon configuration classes and see what they do for you. For example here’s a link to a method that will let you set the acceleration ramp rate for open-loop driving in the Talon.
You can also use closed-loop ramp rates in the talon, you can adjust your kP and kD values in your PID control to not demand so much. You can adjust your allowable closed-loop error variable to start reacting more quickly. There are many ways to skin this cat.
Most teams do not set stringent current limits on their drive and have enough motor power that this pretty much never occurs - instead, teams tend to slip their wheels and burn up the field carpet.
How much current are you actually drawing while the alarm is sounding? That’s going to be what governs whether you damage the motor or not.
The stall conditions are and/either/or I believe. You only have to meet one of the conditions to get the alarm, but both are able to happen at the same time. As far as holding at 20% power, is there some sort of mechanical stop (on the arm itself or in the gearbox or whatever) that’s restricting movement?
As far as the squeal goes, it isn’t a product of software. The squeal is most likely hard-coded into the device itself, or it’s maybe even a mechanical something that causes the alarm. It’s like ABS brake warnings on a car. There’s some threshold where the car will automatically go into ABS mode, whether you want it to or not. The falcon stall alert is the same way.