reading NXT motor encoders

[mattallen37]

Why is it that when I send a motor power command, the NXT motor encoders get reset? I am trying to do some PID, and it's no good when you can't get feedback reliably.

[mattallen37]

Okay, I see that I can use OnFwdEx, and set the reset flag to 0. This works fine, but why isn't the default of OnFwd 0?

[schodet]

There is several counters that you can use:

• MotorTachoCount: Get motor tachometer counter.
• MotorRotationCount: Get motor program-relative counter.
• MotorBlockTachoCount: Get motor block-relative counter.

Their names are not very explicit, but the only difference between them is the moment they are supposed to be reset.

[HaWe]

which counter is the one that is probably resetted in matt's source code?
(matt, maybe you can show us your code?)

[mattallen37]

Okay, thanks. I wondered for a while what the different names meant.

@Helmut, I have only ever tried anything with "MotorTachoCount". It would get reset automatically whenever I used the OnFwd command. I am not at home, and don't have my program with me, so I can't post it (well, i could, but it would take ages to get it).

The difference between OnFwd, and OnFwdEx is that the Ex command allows you to specify if you want to reset the encoder value(s), and I believe you can choose which of the two to reset (Tacho and/or BlockTacho, I don't remember seeing anything about Rotation).

[linusa]

From a direct command point of view, it's relatively simple: You can only reset RotationCount and BlockTachoCount (via command ResetMotorPosition), the TachoCount is off limits. All counters get reset when booting the NXT (obviously) or when launching a new RXE program. You can only reset the TachoCount by direct commands via advanced IOmaps commands.

The BlockTachoCount is apparently used by NXT-G to keep track between NXT-G blocks (as the name suggests). If you do NOT reset it between consecutive SetOutput(State) commands which involve synced motors and TunRatio (turnpct as NXC calls it), the 2nd motor command will give very strange results -- I call it "dancing robot syndrom". The wheels will inverse/revert the turn-ratio stuff they just did, leading to pivoting robots (fun to watch, horror for the coder if you don't understand it). Rule of thumb: Don't use this counter for actually counting distances. Reset before every call involving multiple motors. Ok to reset before every command, too.

The TachoCount is related to the internal error correction. This is the mechanism that corrects accumalative errosr from consecutive motor commands (for each wheel seperately). If the motor overshoots one command, it will turn not far enough (or not at all) the next time. Explained here. So if you want "worryless" motor control without unexpected side-effects, reset TachoCount every time before a new call to SetOutput(State). If you find the auto error correction useful, don't touch it.

The RotationCount seems to have no side effects at all. We've always used it as "user defined mileage counter", just as in your car. You can reset it at your own will, just like your car's "daily dist/odo" counter.

[mattallen37]

Thanks a lot for all that info, that really helps me understand better. I am away from home, and all my robots. Once I get back I will try messing with this some.