We have been using these servos [HSR-M9382TH] with a Rev SPM for a few years. We have managed to get them to work very well in many situations. However, there is still one issue we haven’t been able to solve. Occasionally, and somewhat indeterminately, these servos will suddenly attempt to rotate to one end of their range at high speed. Upon reaching that end, or being stalled for a moment before then, they will then return to their neutral position at a slower rate.
When we do see this, it tends to be when an opMode is forcefully terminated (and the RC app is rebooted).
We’ve tried talking to Hi-Tec and Rev but they don’t have much in the way of an answer.
One thing you need to be aware of with the SPM is that servo bus power is ALWAYS on. With the REV Hub servo ports, power can programatically be turned off, but with the SPM, as long as your 12v bus is powered, the 6v servo bus is also going to be powered.
The servo behavior your describe sounds like it may be related to the servo’s failsafe routine for signal loss. Fancy digital servos can be programmed to run a failsafe routine on signal loss and it looks like your servo has that feature.
Then the question becomes what is different about a forceful stop vs. a normal stop. I’m not sure, but I have a suspicion that the PWM signal might be glitching transiently when the Lynx board runs its internal failsafe routine. I’d have to stick a scope on it to verify though.
Thanks for the thoughtful response. The failsafe was our thought as well but the folks at Hi-tec claim that is not what is happening. However, they didn’t have much of an alternative explanation. They did offer that voltage feedback from the servo might be an issue and suggested we try their PAD (power absorbing device: https://www.youtube.com/watch?v=3bia1sUVTWs) inline. However, we haven’t done that because it doesn’t correlate well with the symptoms we are seeing. We are also quite keen to know what is happening on that signal wire when opmodes are stopped or force stopped. If we had that information, we could go back to Hi-tec and perhaps get a better answer. Unfortunately, Rev hasn’t yet been able to provide an answer to that one either.
Thanks!
I was wondering if perhaps there was different SDK behavior in those two cases, but a quick pass through the code seems to indicate that a Failsafe command (name is a coincidence) is sent to the Lynx module in both cases. I unfortunately do not have access to the firmware source code so I can’t see how the failsafe command is handled firmware side.
What I could perhaps do however, is put a scope on the PWM line to inspect what the signal does when an OpMode is stopped normally vs. force stopped.
That would be most interesting. I’ve just been told that we have also confirmed we see this under a normal stop condition on an opMode as well, sometimes.
Can you please tell me how that servo is being configured? For example, what is the servo actually being configured as in the Hardware Config? (I assume “servo”?). Can you double-check, please?
Darn, yeah, I’ve got nothing then. I agree with @Windwoes that we’d need to find a reproducible test case and put a scope on the line. I presume that none of the usual PWM ranges/values makes the servo move as fast as it does when this happens?
Just to add a possible data point to this discussion, our team regularly sees PWM oddities on our servo ports, especially this season when we initialize opmodes.
In our initialization, we’ll get the servo handles via the hardwareMap, then do .setDirection() on the servo handle to set them forward or reverse. About 10% of the time the servo moves to a bizarre location even though we haven’t set a servoPosition() or otherwise enabled the servo. Sometimes the servo holds the (uncommanded) position, sometimes it moves there but doesn’t hold position on its own (i.e., we can move the servo freely).
We’re not using the Servo Power Module.
We’ve been intending to put a servo port monitor onto the servos to see if we can determine if a PWM signal is actually being sent (and if so, what it is). The servos where we really notice the issue are DS3225-Pro servos, which we’ve used for many years now. I’ll see if we can do the servo monitor this week and report any further data we have.
I put a scope on a servo port tonight and had a look at the signal when stopping the OpMode normally and during a force stop. Neither case showed anything funny going on. The signal stops completely cleanly: no “super short” pulse nor “super long” pulse at the end or anything like that. Of course, there could be some sort of timing condition glitch in the firmware that only manifests itself 1/100 times. What we really need is a scope on the line when the issue happens, but achieving that is not a simple feat.
It’s possible that the issue has less to do with “behavior being injected when a force stop is occurring” and more to do with “behavior that is being interrupted, and how the device responds to that forced interruption”.
By “cleanly” I think you mean the wire no longer had any sort of pulse on it? Was it low or high? Any chance you could repeat that experiment with a Rev SPM in the mix? In theory, that should be a pass through for the signal but I’ve never opened one up to confirm its hardwired between the in/out ports.
When we see this, the servo is at rest, not stalled, at or close to its neutral position. The previous signal was set to .5 in the SDK so in theory there should be a PWM signal on the wire corresponding to that. Hope that helps clarify. Thx!
Correct, no more pulses on the wire, and the last pulse that happens is still the correct width. (I.e. if the pulses were all 2ms wide, the last pulse is also 2ms). The signal goes low and stays low after stopping.
I would be happy to repeat with an SPM, but I do not have one in hand.