Timeline for Is there a bug in the Encoder Counts packets 43&44?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:49 | history | edited | CommunityBot |
replaced http://robotics.stackexchange.com/ with https://robotics.stackexchange.com/
|
|
| May 14, 2015 at 20:01 | comment | added | JSycamore | 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. | |
| May 14, 2015 at 14:26 | comment | added | Jack | 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 | |
| May 14, 2015 at 14:00 | comment | added | Ben♦ | To clarify, the encoder can and does count down, but only when the wheel is commanded to drive in reverse. | |
| May 13, 2015 at 21:07 | history | answered | JSycamore | CC BY-SA 3.0 |