# Is there a bug in the Encoder Counts packets 43&44?

I think I have just found another bug - there was one that was mentioned in another post about the angle and distance. This one is about reading the encoder's counts. I was using them as a workaround for the other bugs but what I found in one instance is that the counts I was reading from the right encoder were incorrect. I was reading in a loop sleeping for 100msec while turning the create2. Here is part of the counts where it definitely shows a problem:

32767
-32763
32766
-32768


This kept on going until I stopped. It seems that it has a problem when it reaches the max.

Has anyone else ran into this or can explain or provide another workaround?

• Can you clarify the problem? Are you turning the create by hand or commanding it to turn? What do those numbers mean, is the encoder jumping between these numbers every 100ms, or rolling over like normal? Can you post some simplified code that demonstrates the bug? – Ben May 14 '15 at 14:07
• You mentioned another post, about angle and distance... could you provide a link to it? Is it iRobot Create 2: Encoder Counts or an earlier post? – Greenonline May 14 '15 at 18:34
• links added to question – Ben May 15 '15 at 16:45

Jack,

I have been working on determining the angle from the encoders. I recall running up against a similar problem to the one that you are facing.

First off, unless you are spinning the wheels really fast, the encoders should not give readings like that (508.8 counts per revolution means that you would be spinning the wheels ~130 revolutions in 100 ms--practically light speed for the Create 2). For this reason, I suspect that there is something odd going on inside the Create 2. I would suggest resetting the Create 2 using Op code [7], then trying again; this fixed my problem.

When you try again, you should do the following:

1. Connect to a computer and setup using RealTerm, or some other simlar program.
2. Reset the Create 2 with [7].
3. Send the following string of commands: [128 131 149 2 43 44]. This will print the encoder counts of each wheel each time you send the commands.

If this does not work, try taking out the battery and putting it back in, then repeating steps 1 and 3 above.

In addition, there are some things that you should keep in mind. From an earlier post (iRobot Create 2: Encoder Counts) and the updated OI specs, the encoders are square wave and do not keep track of the direction of spin directly, so you should see only positive increases in the encoder count, regardless of spin direction.

• To clarify, the encoder can and does count down, but only when the wheel is commanded to drive in reverse. – Ben May 14 '15 at 14:00
• NBCKLY, thanks for the reply. First, I am not spinning the wheels that fast at all - in fact very low - 50mm which is an order of magnitude lower than the max specified in the spec. Second, you mention that these counts are positives? the updated spec say otherwise - they 16 bit signed numbers so which is it? what happens to the counts after issuing the command reset (7)? are they rest to 0? there are very serious issues with the Create2 which makes it very hard to work with. any firmware updates coming? thanks – Jack May 14 '15 at 14:26
• Jack, as Ben clarified, the encoder counts will always be positive if you push the Create 2 rather than drive it with the motors; driving the wheels with the motors allows the Create 2 to keep track of direction and will give appropriate encoder counts. When you use Op code [7], you are resetting the Create 2 completely, not just resetting the encoder counts. Resetting will cause the encoder counts to start back from 0. – JSycamore May 14 '15 at 20:01