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?
7 Likes
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?
1 Like
The feature is effectively useless because it cannot correct position error.
1 Like
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âŚ
5 Likes
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.
3 Likes
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).
1 Like
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.
12 Likes
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!
3 Likes
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.
4 Likes
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).
1 Like
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â.
2 Likes
I thought the REV reply was fairly clear in context. The feature that âshould be documented betterâ is the lack of motion replanning.
2 Likes
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.
4 Likes
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.
7 Likes
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.
2 Likes
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.
6 Likes