Will REV Smart Motion ever be fixed so that it the profile setpoints are sent to a position PID controller rather than a velocity controller?
I’ve heard it’s broken but it’s unclear what the problem is exactly. What does Smart Motion currently do, and what is it supposed to do?
The feature is effectively useless because it cannot correct position error.
Agreeing with @asid61 here.
As usual I’ll preface this post with “I am not a programmer and don’t claim to be one”. That being said, we used REV’s Smart Motion on our shoulder/arm this past year with no issues. The sensor feedback came from the NEO’s integrated encoder, and Smart Motion both held and corrected it’s position in real time with no apparent issues to us for the duration of the 2023 season…
I keep hearing from people (people who are much more knowledgeable on the subject than myself), that there is a massive flaw with using REV’s Smart Motion, but I have yet to see anyone be able to articulate in layman’s terms what exactly that issue is; Let alone demonstrate the effects of the issue on real-world hardware…
According to REV’s Java code example, this is what Smart Motion’ intended use case is:
This example shows how to use REV Smart Motion to control the position of the motor in a smooth and predictable manner by generating a motion profile on the fly in the SPARK MAX and controlling the velocity of the motor to follow that profile.
It’s very hard to argue to our programming team that “people on the internet say Smart Motion doesn’t work/is useless”, when they have real hardware sitting in front of them, with Smart Motion appearing to function exactly as intended…
Following a motion profile with a velocity loop but no position loop does not make sense if you’re attempting to control position. SmartMotion only runs a velocity loop; the position components of the motion profile are ignored.
If your mechanism is wildly overpowered you may be able to use smart motion despite the position control being open-loop, but it will not be able to directly correct any lingering position error after the transient motion resolves.
Forgive me for pushing further (I’m really trying to understand here ), but I’m interpreting this as to say, “once the Smart Motion control loop reaches it’s setpoint/target, it will be unable to react to any external forces, causing it to potentially deviate from the setpoint”.
If this was the case though, wouldn’t something like an arm or elevator not immediately begin falling (due to gravity) once Smart Motion reached it’s setpoint?
Conversely, our experience has been that once our arm reached it’s setpoint, it not only held it’s position, but would also “fight” to hold it’s position if an external force was applied (such as running into a wall, physically pushing up on the arm, or even just the act of gravity itself).
This makes sense to me. I figured it would send velocity commands to the controller to get it to move to the target position, which seems fine as long as you give it new setpoints frequently? Of course, spark MAX velocity control is not good so maybe there’s more to it.
It will fight external disturbances after reaching the setpoint because it is trying to hold zero velocity. It has no corrective feedback based on the mechanism position, though, so anything the velocity loop misses is gonna stay there forever.
I don’t know how to say this any more simply: SmartMotion generates a motion profile and then runs closed-loop velocity control on the velocity setpoints from the profile. The position setpoints are never used, and are only implicitly followed by the velocity controller (in that the velocity setpoints integrate to the position setpoints). It is not a cascaded setup where there is a position loop generating velocity setpoints; there is no position feedback at all.
This is the part I was missing, and it is now much more clear to me the issue being discussed.
It sounds like in my team’s specific scenario with our arm, it is indeed that we’ve thrown so much power at it that Smart Motion is able to work effectively for us (as you mentioned above). In theory if we were to exert enough of an external force on our arm to make it move a significant amount, Smart Motion would work to bring our arm back to a velocity of zero, regardless of it’s current position vs the positional setpoint.
Because of the immense power in the arm though, we likely were never able to apply enough force in testing to noticeably affect our position, leading us to the misguided conclusion that Smart Motion was attempting to hold our position (opposed to just the velocity).
Thank you for taking the time to explain this!
Has anyone experimentally shown whether SmartMotion is continuously replanning the trajectory or not? Maybe I missed something in the other thread. I imagine using a velocity gain that’s intentionally too small would show it quite well based on whether the deceleration occurs near the setpoint or much earlier.
If it’s actually replanning (or this can be recreated by repeatedly sending setpoints), that’s a perfectly valid control scheme even if it’s not always the best for FRC mechanisms. If not, then certainly it won’t be very effective. But I haven’t heard that we have clear confirmation either way.
If you check the thread I linked above you’ll find confirmation that it does not replan, as well as a discussion of why replanning alone doesn’t really fix the issue very well (it fails to handle small disturbances).
I have read through the other thread, but I only see anecdotal evidence for both directions. REV’s comment is vague and doesn’t address this specific issue. I agree that’s it’s not a great feature, but there’s a big difference “it doesn’t use position data at all” and “it relies on replanning the trajectory which isn’t great for end behavior”.
I thought the REV reply was fairly clear in context. The feature that “should be documented better” is the lack of motion replanning.
I think this is the conversation we’re talking about. Smart Motion can be “velocity centric” with “profile setpoints piped to the velocity controller” while still replanning the trajectory. This addresses the lack of a direct position controller, but replanning isn’t mentioned at all.
This would be pretty easy to experimentally test, so I was simply curious if we had more direct evidence. Regardless we’re in agreement that the feature could be significantly improved.
Per the discussion after those posts, it’s not trivial to “just replan every cycle” as a solution due to the behavior when errors are small. In addition to not being a strategy that would really fix the problem, there’s nothing in documentation that suggests it does this.
As someone who has never had an issue with SmartMotion for turrets, elevators, wrists, or high-load double rocker arms (that we thought was a 6-bar), I’d argue that using either large BLDC motor makes any mechanism “wildly overpowered”.
I’m sure there’s some tolerance I’m just not noticing though. But +/- a few tenths of a degree or inch usually doesn’t break a mechanism or cause poor on-field performance.
It “works” until it doesn’t, and if you don’t know what’s wrong with it you can waste a huge amount of time trying to tune the inherent error out of the system.
The control algorithm is poor, and it would be trivial for REV to fix it.
I’m not doubting the effort to fix it. But you also can’t argue with our results by hyperbolically describing its impact. We tuned our wrist + elevator once before the first event, and only retuned our lower pivot after a rebuild for better mechanical reliability. The mechanisms never ‘stopped’ working due to PID; for example even when the wrist got caught on another robot during DCMP’s, it still re-homed correctly in the same match. The pivot needed a rebuild because we did the math on it a bit wrong at the start.
Sure, it could be more robust. But I’d rather REV work on a better motor <> controller cable first.
What I mean is that it works until you build a system whose physical parameters don’t render the choice of feedback algorithm mostly irrelevant. This isn’t that hard to do, even with BLDCs.
If you overpower the mechanism enough you can dispense with the profile and just bang-bang the thing at partial power and it’ll still “work.” But that strategy works only until you encounter a mechanism that isn’t so simply-constrained.
The problem I have with smart motion is outlined by this thread: it’s a black box. Nobody knows what it’s doing inside. You tune a velocity controller, put setpoints and constraints in and …it works somehow? It’s doing something, that something just isn’t documented, anywhere.
Having used Smart Motion in 2019, it works, but it was significantly more difficult to tune than a position controller that we fed profiled setpoints to.