Encoder A/B Count Direction Flip in Software

General discussion of using Roboclaw motor controllers
Post Reply
robof
Posts: 36
Joined: Tue Jun 27, 2017 11:21 pm
Encoder A/B Count Direction Flip in Software

Post by robof »

I take it that the Roboclaw was intended for use by differential drive robots, but I have a feeling many are not using it in this case, as I am not, and instead are driving 2 independent motors with each Roboclaw.

So with that, I think it would be very beneficial to us to have a software option to set the encoder count direction. I see already an option to switch the A/B channels so I would think this would be very similar and possibly more commonly needed. This option would also make it easier to wire since we wouldn't have to remember to flip one set of encoder wires. Lastly I could see it getting worked into tuning/auto-tuning since we could pulse + or - and if count was in the wrong direction we could flip the encoder count direction in software.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Encoder A/B Count Direction Flip in Software

Post by Basicmicro Support »

Im not seeing the connection between encoder count directions and differentially steered robots. Maybe you could elaborate on what you mean there.

The encoder counts are handled entirely in hardware. The A/B orientation of the encoder dictates its direction relative to the motors movement. Swapping either the encoder channels(A/B) or the motor wires MxA/MxB will change the direction of the encoder relative to the motor. Unfortunately the hardware A/B channels of the quadrature decoders built into the Roboclaws processor do not give the option to swap the decoder pins by software. What you are asking for can be done in another way, but would require additional code in what is already a very tight interrupt handler for the quadrature encoders. I'll add it to the wish list but I cant garauntee it can be added.
robof
Posts: 36
Joined: Tue Jun 27, 2017 11:21 pm
Re: Encoder A/B Count Direction Flip in Software

Post by robof »

I assumed the Roboclaw requires wiring EN1 with A/B and EN2 with B/A since differentially driven robots have motors spinning in opposite directions; whereas ideally I would wire both motors/encoders up the same, A/B on both EN1 and EN2.

I understand that swapping the direction of either the encoder wires (I'm doing this currently) or the motor wires (I do not recommend if your motor is grounded to - wire) is a solution.

Since the encoder counting happens entirely in hardware, I'm assuming the other option would be to read some new 'flip direction' flag only when the value is used instead of when it is actually incremented/decremented and multiply the return value by -1 if needed.

Again I understand this is an easy solution to just flip the encoder wiring so definitely not a big priority, but just something that pains me when constantly hooking/unhooking wires for prototyping. As well there were some other added benefits such as avoiding a runaway situation if wiring is hooked up wrong since the software could determine the count was going in the wrong direction and be corrected.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Encoder A/B Count Direction Flip in Software

Post by Basicmicro Support »

A DC motor power wire doesn't have a polarity. Some motors have a preferred rotation direction but it is unlikely you would be using a motor like that on a full h-bridge motor controller(since you usually want them to rotate in both directions equally well). So since there is no defined + or - side of a motor the Roboclaw has no way of know what direction the motor will be going with a given wiring of that motor.

The encoder inputs are labeled A and B but again, like the motor we cant know the direction the encoder manufacturer designed as "forward" so there is no there is no "right" way of wiring the A and B signals from the encoder.

If we can add the capability to change the direction of the encoder count we will, eventually. but like you pointed out it is not a high priority right. Assuming we can do this we probably would add this into the autotuner to automatically determine the directions when tuning and setting them automatically.

Post Reply