Long Distance Encoder Reading of 37D Metal Gearmotor

Dear Pololu team and community,

Project Background:
I am trying to use a Roboclaw 2x7A to control two 37D metal gearmotors. These will be used for a robotic arm whose base slides along a track on the wall. One gearmotor will be attached at the base providing rotational motion. I was planning on having the other gearmotor at the end of the track, driving a belt which induces linear motion along the track. The track is 48" long, and I used Pololu’s 60" cables to span that distance with some extra.

Application Question:
I am successfully reading encoder counts for the one gearmotor that is connected to the roboclaw exactly as seen in Basic Micro’s application note here. However, I am getting errant encoder readings (switching between positive and negative speeds with the motor accelerating in one direction) when using the 60" long wires. I expect this is because of either interference in the encoder signal lines, or a drop in voltage for the encoder power+signal lines over long distance. However, I don’t have an oscilloscope to check for sure. I could not find on Pololu or otherwise what should or should not be done for long runs of encoder wiring. I know generally that running power separate from data is best, but I need to get both of these to and from the motor at the end of the track, so that will be a little hard to implement.

What are the most prudent next steps to take to mitigate this problem?

Preferences: An electrical mitigation is much preferred over mechanical redesign.
Using the one Roboclaw for both motors as a cost savings measure (and if not, I’ll be troubleshooting serial comms over the same distance).

Attempted troubleshooting: Isolated wiring to the single motor having trouble. Switched encoder and motor power channels from 2 to 1 (same behavior). Switched to shorter wires (resolved encoder problems, but I don’t know how to get robot linear motion with motor attached to the moving carriage).

I think I found my problem; I didn’t pay attention to the fact that I had left the 60" wires coiled on the bench top, so I was making an inductor. Once I uncoiled them and let them drape over the bench, all good! If there are minimal steps I can/should take to prevent future problems, please let me know.


I am glad to hear you got your system working. You might look into shielding your encoder signal cables to prevent future problems. Beyond that, I do not have any “minimal steps” to suggest. If a more significant redesign is possible, you might look into if you can mount the RoboClaw closer to your motor in a way that it moves with it. That would allow you to keep the encoder cables short; however, that may just move problems to your RoboClaw’s input signals (though I think those would be less prone to cause errors that lead to problems).

- Patrick

Thanks, Patrick.

I’m currently using your precrimped wires to transmit power and encoder readings; Do you have a recommended source for either a relatively low cost shielded cable to replace that, or a source for a shielded jacket of some sort?

Unfortunately, I have two motors, one that is on the moving carriage, and one that is on the stationary frame; So I can have the roboclaw next to one, but not both. I could move the roboclaw next to the stationary motor, but then I’d have the inverse problem. So, I’d need a completely different way to drive the carriage (or the robot arm) so that I could keep both moving or both stationary.

Unfortunately, we do not have any specific suggestions for shielded cables.

- Patrick

Have you considered using a differential signal over twisted pair, e.g. RS-485? https://www.maximintegrated.com/en/design/technical-documents/app-notes/3/367.html. The Maxim chips are easy to use, but you’d have to check if the data rate is fast enough to capture the quadrature signal.

I am completely unfamiliar with standards such as RS-485; If I have troubles in the future once everything is installed, I’ll be sure to do some research on it; thanks for the suggestion!