During shooter testing we’ve been using velocity control on the Spark Max with a geared-up NEO. We’re just controlling the motor velocity setpoint with a slider on the front panel of the periodic tasks VI like in the Rev example code.
We’ve noticed during spin-up that if we slam the slider to a high value very quickly, the motor gets full voltage, starts to accelerate, and then cuts out very consistently once it reaches a speed just under 2000rpm (which takes a second, maybe a second and a half). The motor can’t be started again until code is stopped and re-ran. Disabling and reenabling the robot, changing the setpoint, or changing PID settings doesn’t get the motor running again.
We were able to work around this problem for testing by slowly ramping the setpoint manually.
Now we’re testing bang-bang control, also using the on-board PID (just set the P gain super high, all other gains to 0, and the output range to 0 -> 1 instead of -1 -> +1). Given that bang-bang control is either fully on or fully off this means our 2000rpm problem is back.
Very late last night we were able to get bang-bang to work by setting the maximum output to 0.9. But we would like to be able to use the full power of our motor (obviously).
Has anyone run into this issue? Is this some sort of current or heat protection measure? Firmware issue? Communication issue?
I realized after posting this that there is a good chance we are tripping the thermal breaker on the PDP. We’re geared VERY high (3:1) with the equivalent MOI of 5 4x1.5 colsons. We were powering the test off of an existing robot so there is a chance we had a <40amp breaker on that PDP slot because no other slots were available.
What threw me off is the fact that the behavior of the tripped breaker is not what it usually is. We had tripping problems with another prototype using a slightly geared-up brushed motor (CIM) on a 20amp breaker (we built it poorly so there was drag in the system). But the behavior was very different: the motor would run for about 1 sec then stop, then start again after about 2sec (once the breaker cooled off), and this cycle would repeat.
I guess the “smart” nature of the brushless controller doesn’t allow it to cycle on and off again without getting some signal from the code starting up?
I’ll check on the breaker situation tonight and report back to this thread.
Update: we fiddled around with the smart current limiting settings and found some that worked. We were able to cycle the shooter up to full speed multiple times using the bang-bang control without tripping the breaker.
Check out smart velocity control for the NEO. It should effectively limit the total current applied, while also giving you very repeatable ramp up times.
Is the kSmartVelocity what you were referring to? Is there somewhere this is better documented? I can’t find anything which explains the difference between kSmartVelocity and kVelocity.