Page 1 of 1

Encoder Counting Up/Down at Different Rate When Driven by Roboclaw

Posted: Fri Jan 18, 2019 4:48 pm
by Lionel
Hi guys,

I have a really strange issue. My setup consists of 4x Roboclaw Solo30A driving 4 Pololu motors with encoders. All the Roboclaws are in multi-unit mode, controlled by serial packet, and have different ID. I had already had everything working and even controlled all motors simultaneously by an Arduino Mega.

Now, I made more permanent cables and connectors (try to have something more robust, my mistake...) and once I finished, I also had to update the firmware to the latest version with Motion Studio (don't know if it's related to my issue). Problem is now, only the first motor is ok while I have the strangest issue with the encoder count of the three others.

These problematic motors connect fine and when I rotate their axes by hand, I see the encoder position moving up and down with the right count in Motion Studio. However, as soon as I move the motors by changing the PWM the encoder count is moving at a much faster rate in one direction (the other direction rate stays fine, ie consistent with hand turning). So anytime I make one turn in one direction followed by the same motion backwards, instead of ending to something close to zero, the encoder displays a huge value! Velocity and position control do not return any error but the QPPS are completely wrong

What baffles me is that by turning the axes by hand, the count is perfect in both directions. Only when I actually have the controller moves the motor it becomes wrong in one direction. I also cannot comprehend why the first axis still works, the wiring is identical to the others.

Any ideas?

Re: Encoder Counting Up/Down at Different Rate When Driven by Roboclaw

Posted: Thu Jan 24, 2019 10:15 am
by Basicmicro Support
If you have access to an oscilloscope please check the encoder signals, A and B, on all encoders. My guess is changing the wiring has introduced noise that didnt exist before.

Also if these are the type of motors with encoders built in, most of those have a flaw that allows motor noise to get into the encoder signals. This is common to ever motor I have purchased from multiple vendors that have the magnetic hall encoders built in. They install a snubber cap(no resistor) between the motor leads or between each motor lead and ground. This cap(s) allows AC noise to pass through to ground(or inductively couple to it, depending on the cap layout)) which is good to reduce motor noise, BUT, they dont seperate the signal ground from this snubber ground(or the signal ground is immediately adjacent to the cap so it gets inductively coupled to it) so you end up with big spikes on the encoder signal lines which cause false encoder counts. If you have a long ground line from the encoders to the Roboclaw this just exascerbates the problem.

There are two fixes for the above problem.

1. You can try adding a capacitor on each signal line to ground near the roboclaw. The resistance in the wire plus the cap produces a low pass filter which can be made to clean up these noise spikes. Usually a .1uf cap from each signal line to ground is sufficient.

2. Alternatively you can remove the snubber cap from the motors encoder PCB(I'd recopmmend soldering a through hole cap(.1uf will usually work) across the motor power leads if you remove the snubber on the pcb of the encoder). Some motors have one that connects to each side of the motor power lines and some have two caps. One from each motor line to a common point on the board(gnd). You can find them with a continuity function on a multimeter.

Another possible cause of your problem(if the above isnt the cause) is if you are running your encoder wires parallel to your motor wires. If you are I recommend you seperate them(motor power wires in one bundle and encoder signal and power wires in another. Running them parallel allows noise to couple from the motor power lines to the encoder lines and the longer these wires are the easier this can happen and the worse the noise will effect your encoder signals.

Re: Encoder Counting Up/Down at Different Rate When Driven by Roboclaw

Posted: Fri Feb 01, 2019 4:31 pm
by Lionel
You were right.

I did not have a scope but it was on my shopping list for a long time so I actually just bought a brand new Siglent SDS1104X-E for this (yay me!). I was appalled by the level of the encoder line signals. First, while being fed a beautiful +5V from the Roboclaw, they only output a peak-to-peak signal of less than 3V with a noise level of at least 1V, sometimes even much worse. Awful :( .

I did disassemble the robot encoder and could see that snubber cap right across the power lines of the motor but it would be quite difficult to unsolder without removing the magnet and that one seems to be press fit on the axis so I was unsure if I would be able to put it back.

So I settled with adding a capacitor across the A-B channels of the encoder and the GND at that did the trick! The count is now fine again with both Motion Studio and my Arduino. 0.1uF was too high (the signal was too slow to raise and was chopped off at high speed) but the magic value seemed to be a tenth of that (10nF). You can see below the dramatic improvement of the signal:


The lower plot is with the cap, the upper one is the other channel without any cap (raw signal). Zooming in I could actually see that the noise is made from a series of spikes at 20kHz. I guess that's the PWM frequency of the Roboclaw.

Thanks a lot for the help!

Re: Encoder Counting Up/Down at Different Rate When Driven by Roboclaw

Posted: Mon Feb 04, 2019 10:15 am
by Basicmicro Support
Yes. Because of how they layout the snubber cap on most/all of these magnetic encoder motors the PWM from the motor driver couples to the signal lines on the hall effect sensors. That is because for all intents the snubber capbs shunts the A/C part of the 20khz, directly into that pcb. A real snubber should have an appropriately sized resistor to reduce how quickly that energy goes into the pcb, or better yet goes into an isolated ground plate but they are pretty limited on space on the PCBs.

Yes, you will have to play somewhat with the cap value for filtering depending on the maximum frequency your encoder signals can reach. Glad you got it working.