SDC2160 - Seems to command opposite direction occasionally (position-tracking)

Hello!

I have an SDC2160 driving a small DC motor. I've watched the motor occasional jerk in the wrong direction, and have tried to reduce the situation to reproduce/debug.

Currently for debug I have no load on the motor except a very high ratio gearbox (1650:1). The motor has a hall effect encoder with 48 CPR (counting all transitions of the quadrature lines). I am in "closed loop position tracking" mode, and have "P" gain only: P:4, I:0, D:0. (firmware V1.8d SDC2XXX 1/8/2018)

The moments when the motor goes the "wrong" direction do appear in the RoboRun+ log. I set a specific target, and watch as the encoder value slowly approaches it. Along the way, the reported motor power briefly reverses direction, then quickly resumes the approach. During the period of reversed power, the encoder progress slows or moves slightly away from the target (which reflects what's happening the real world: the motor briefly slows or heads in the wrong direction on the way to the target).

I'm not sure how this could happen, what could be causing the controller to choose to reverse power in these moments, as the encoder value is gradually approaching the target and only a "P" gain is set?

I have attached 2 screenshots of the RobotRun+ graph (and a saved RobotRun text log corresponding to the first one). I can reproduce pretty reliably if there are other things I should try/record! Thanks for any help/ideas!

Example 1 Image:

Example 1 Text Log:


Example 2 Image:

This is probably not the cause, but could you have the Mute button un-checked? The feedback curve shows no dropouts in encoder signal, but in loop error and motor power. At least with long complex scripts (not involving any closed loop) leaving Mute unchecked can cause this kind of thing.

There is definitely something wrong with your encoder connection. You can tell because of the feedback signal. Probably some form of noise - the resolution is also extremely low on it.

Try Closed Loop Relative position mode. It pre-plans your trajectory and should be more resistant to noise on your encoder signal. But the best thing to do will be to capture your encoder output with an oscilloscope. Also, post your configuration settings so that I can check them.

Hi LRobbins and Gabriel, thanks for your responses!

LRobbins: I've never clicked "mute" before, but I just tried it - it seems like it disables the command slider control from RoboRun? In this test I'm using the command slider to manually test out the motor; I'm connected over USB only, serial cable disconnected, no scripts or other programs talking to the controller. So, I think I should be OK on that front, with the RoboRun control slider being the single source of commands?

Gabriel: Yes could be something wrong with the encoder! However, I'm not sure I understand why that would be; can you say more about what is in the data that suggests a problem there? As I understand the modes, in "Closed Loop Position Tracking" the commands are always in the space -1000 to 1000, and the feedback values are mapped to that space as well. So, even though I'm going through 34000 actual ticks (I have my encoder limits set to (-17000, 17000)), the graphed "Feedback 2" line will only display the data in the mapped -1000 to 1000 interval. So in the attached log, I try to move from command 88 to 279 (~10% of the total possible range), and the displayed feedback values are moving correspondingly from 102 to 261, representing ~8% of the range, with the resolution I would expect (same as command values)? (Of course, behind the scenes, 0.08*34000 = ~2.7k actual ticks are going by!)

To work around this issue I've switched to using the controller in a velocity mode ("closed loop speed position") and running the final position control loop around that in software over the serial, which has been working great, no obvious hiccups.

I've attached a picture of the settings, and the profile xml file (note that I'm using channel 2 for all these tests!). I changed the pgain from 4 to 2 from my previous post as I found it easier to reproduce the hiccups.

I just realized that RoboRun can also graph/log the raw encoder value, not just the (-1000,1000) feedback value, which will then directly show the true resolution instead of my attempt to explain in the confusing paragraph above! I did another run and attached the log and picture here:

(I accidentally duplicated the last message, please ignore this message!)

Yes, mute has nothing to do with this.

I am a bit skeptical about the idea that encoder noise is at fault. Though the feedback and counter curves may be noisy, there is no correlation that I can see between that and the very sharp dropouts in LoopError and MotorPower which are simultaneous or nearly so. The second dropout in the last screen shot also seems to have happened after MotorCommand, Feedback and Counter are all quite steady.

Ciao,
Lenny

I am experiencing a similar issue with a SDC2160 running a brushless DC motor, although there is no encoder involved. I am curious to know if you found a solution to your problem. Any luck?

Cheers,
Jeff