Should vendors enforce a default software current limit on motor controllers?
Yes
No
0voters
During an event I was a CSA at this year, I ran into a seemingly impossible situation. A low resource team using the KOP drivetrain with CIMs attached to Talon SRXs on 40 AMP breakers on the CTRE PDP was browning out when attempting to move on normal carpet. This robot was fairly lightweight and was not running any additional mechanisms simultaneously that would normally cause this issue. I was able to demonstrate this issue to the team by having the robot drive against a wall to show the PDP breakers constantly tripping. After this, I helped the team implement a software current limit and was able to demonstrate that the issue disappeared when running the robot into the wall again. My theory on why they encountered this issue is that the hardware they were using was aged was was not operating as optimally as it should have.
As a result of this experience, I’ve been thinking about whether or not vendors should set a default current limit on motors to avoid these kinds of situations. With the new Rev PDH allowing teams to access more power simultaneously and the rise of brushless motors causing increased wear and tear on carpet, I’ve been leaning towards having vendors enforce this limit automatically to avoid issues like this.
Arguments For:
There is precedent to do this, as other ‘hidden’ behavior is already done in robot code (e.g. automatic compressor functionality when declaring a solenoid in code)
This adds a ‘natural progression’ to the process of learning how to manage a motor controller. When teams realize their motors aren’t running at full power, they will come across this information and will be able to learn how to implement/disable this feature as needed.
This should not affect high resource or knowledgeable teams that much, as they are more likely to be informed of changes like this and will still be able to disable this as desired.
Arguments Against:
This can negatively impact teams who aren’t aware of this behavior, causing them to spend more resources on developing a mechanism than needed or time trying to figure out why their motor is not performing as expected in certain cases.
The limit would have to be able to handle most cases, which can be detrimental/pointless for certain motors (e.g. a 40A limit on a TalonFX is fine, but a 40A limit on a 775 would not protect the 775).
Overall, I see this as a more net benefit to teams in FRC, as this should generally make robots more reliable in an environment where the double-elimination format favors reliability, but I’m curious to see what other’s opinion on this is.
Current limits aren’t exactly logical, with Sparks I believe it could be as simple as setSmartCurrentLimit(40) but with devices like Falcon motors Talon FX you get control over peak current draw, long term current draw, & the time frame to transition between those modes, & factory enforcing specific behaviors severely limits teams controls.
I think it could be better handled by just reminding teams to do it, pop it at the top of the setup documentation instead of having it buried down in the docs for example as configurable parameters 364-366 without even a proper function name. ehem CTRE
I agree that it might be good to have default current limiting that can be overridden. It flips the default in a way that likely helps low-experience teams. I recommend to our programmers that they add current limiting to every motor before there is a problem, but it’s one more thing to know about and remember.
I agree. At the very least there should be a default current limit of the largest legal breaker amperage. It’s kinda funny to me that 100% of Rev’s brushless motor controller SKUs will out of the box burn out 50% of Rev’s brushless motor SKUs. We did repeatedly hit burnout protection on a Falcon this year during practice. Thankfully, it protected itself. If we had had a current limit on it from the get go, we could have avoided that situation (though 40A is a bit low for a Falcon imo).
That’s a stator current limit, not an input limit like on the Talon SRX. A stator limit is good for limiting torque and/or protecting the motor. The input limit is better for preventing a breaker from tripping. The last time I checked the SparkMAX doesn’t have an input current limit.
Teams should also be aware that a NEO 550 connected to a SparkMAX with the default current limit of 80A will destructively fail in approximately 2 seconds if drawing full current.
We have run into burning up a NEO 550 on our bot during testing due to stalling the motor out on our intake for a few seconds at max power. I could see a major benefit in reducing failures of a given motor if there was a default current limit.
Maybe something like changing the API of the CANSparkMax to take a default SmartCurrentLimit ? That way the change is up-front and part of the Intellisense when writing control for a SparkMAX.
On the note of Neo motors specifically I feel like REV could default enable a temperature safety on them for stall protection as even a current limit may not keep the motor safe.
The temperature sensor lags behind the stator temperature significantly. Their temperature vs time plots show this. So unfortunately unless they implement a prediction model it’s not quite so simple.
Products should be sold in a configuration where they will not break under expected use-cases out of the box. Absolutely allow customers to change things, but set the defaults to be within safe condition for use out of the box. We had several broken motors this year because we either didn’t know to set current limits or swapped speed controllers mid-competition and forgot to change the settings on the new ones, and while we take responsibility for those, it’s pretty ridiculous that we have to change the product we bought in order to make it functional for any reasonable competitive use.
Temperatures lag a lot but if you only use it for stall use cases as an added layer of safety it tends to work pretty well, I’ve implemented it on Neos and Venoms before, you also need a current limiter for spikes but in stall use cases temps work better.
I think there should be a default current limit but there would be issues with it because not all motors need the same current limit. for example we have a 40a current limit on our falcons and neos but we a 10a limit on our neo 550s. setting a software current limit is definitely important because breakers are triggered by heat so you can still draw more that 40a through them. we consistently drew 80+ amps through neos last year on accident and that caused them to smoke. I think motor should come with a default current limit but it would be hard to tailor it to different motors (ex: 775s need different current than a CIM).
we experience this first hand last year with both NEOs and NEO 550s. if you stall them without a current limit they will smoke before you realize and turn it off. This year we set our 550s on our intake to a current limit of 10a. this allows us to stall the motor for the entire match (not that we do that) before it will smoke.