inconsistent encoder status registers reading in mixed mode

[mabrouk]

Hi,

I have Roboclaw 2x5a v4.1.10 and I am trying to drive it using mixed mode commands like 8, 9 and 43. When I read the enconder registers (16 and 17) sometimes I get different status values for example 0x80 and 0x82 even though both motors are turning the same way and in other cases the values are the same.

can you explain the inconsistency ?

thanks

[Basicmicro Support]

Bit 1 indicates underflow(eg going from 0 to 0xFFFFFFFF
Bit 2 of the status indicates the motor is going forward or reverse.
bit 3 indicates overflow(eg going from 0xFFFFFFFF to 0)
bit 8 use to be used for a failed quadrature decoder but is now always set to 1 for backwards compatibility.

If one motor is always 0x80 and the other always 0x82 when both are going in the same direction then one of you encoders wires(or motor wires) are backwards relative to the other.

[mabrouk]

did you read the question? I did not say that they ALWAYS return different values just sometimes this does not indicate that I got the wiring wrong - something is wrong but not the encoder wiring SIR.

[Basicmicro Support]

If you read my reply you will see I didnt say you DID wire them backwards. I said if you get 80 on one and 82 on the other when both motors were going the same direction then the encoders wires were backwards(relative to each other). Encoder wires can be reversed and the encoders still work so that was just extra information since your original post was unclear to me about what exactly you were seeing.

I also documented what each bit in the status bytes mean. I was expecting you to come back with more information on exactly what you saw relative to my new information on the bits.

[mabrouk]

Not sure what other information are you looking for.

It's very simple I use command 43 to drive the robclaw some distance with positive speed and while the roboclaw is running I read the encoders registers using commands 16 & 17 what I get back is inconsistent as far as the direction bit in the status byte - they both should be 0 meaning going forward. This happens most of the time but not always sometimes I get back 0x82 for one and 0x80 for the other.

[Basicmicro Support]

Your original question didnt say you only go inconsistent direction bits. It said "sometimes I get different status values for example 0x80 and 0x82" which implies you got other different values than 0x80 and 0x82. I was waiting for you to tell me what other values(whether it was garbage or potentially valid bits of data or not) you were getting. So were you only getting 0x80 and 0x82 or not. Were there other values or not.

Are you confirming the checksum(or the CRC16 on the new firmware) when you read back the data? If you are then those direction bits are probably(definitely if using CRC16) correct. That would lead to the encoders/wiring/mechanics having a problem(electrica or physical noise/jitter). Im assuming the motor isnt being commanded to oscillate. The direction bit is directly calculated by comparing the current encoder count and the previous encoder count(1/300th of a second previously, note: not the preivous time you read the encoder). If the Previous count is lower than the current count then the bit is cleared, if the previous count is higher than the current count then the bit is set. If there is jitter in the encoder readings(for whatever reason) this could cause an inconsistent direction bit.

If you are not confirming the checksum/crc16 is valid please do that before we go any further.

If you have not updated to the latest firmware please also do that. The CRC16 is much better than the simple checksum for error detection.

Also are you using the USB conenction or the TTL serial(S1/S2). if the TTL what baudrate? Does the same thing happen using a different baudrate(lower and higher)?

[mabrouk]

Sorry I did not specifically mention that it was the direction bit that had a problem in my original post - I provided the exact status byte values and thought it was obvious from the values which bit was the problem.

Yes I am using the checksum in the old firmware and crc16 in the latest one. Also I tried it on both USB and packet serial with 38400.

The encoders counts look good to me and seem to consistently count up when moving forward.

On another note I posted an issue regarding the new firmware - 4.1.13 - entitled "new firmware issues - 4.1.13"
under general topic. I appreciated if someone can let us know if there is a fix coming.

thanks

[Basicmicro Support]

The problem was my misunderstanding what you meant by this "sometimes I get different status values for example". But lets forget about it and get to the point of your post.

When using the CRC16 it is nearly impossible for the direction bit to be wrong. CRC is guaranteed to detect a single bit error. However if there is more than a single bit error the detection rate is something like 97%.

However I suspect it isn't an error at all. I suspect the encoder count is jittery just a little bit causing the encoder value to go backwards one or more counts sometimes(as far as the Roboclaw is concerned). You may never see it directly but since the roboclaw is checking the count 300 times a second it could see it.

Note I had a customer using an encoder the other day which was producing bad pulses in one direction only(it was a magnetic quadrature encoder instead of optical). So it is not unheard of for encoders to produce bad data.

First thing I would do is have my program use the actual encoder values to determine direction in this case. If the new reading is higher than the former then assume the motor is moving forward etc.

Second is to test if different speeds significantly change the bad reading. Run the motor at very low speed and very high speed.

Third run the motor using PWM(bot velocity or position control). Encoder readings will still work. If the problem stops then the PID tuning is probably causing an oscillation but one that is too small for you to notice.