I’m trying to start off a robot run with both motor encoders at 0. This is likely the case if the BrickPi has just been powered up, but not if the motors have run. Looking at the firmware & BrickPi.py code, it seems I just need to set the field to the same value & sign as the encoder - only it doesn’t work. I found that if I applied 32 bit values from -247483648 to 2147483647 to the offset, calling BrickPiUpdateValues() each time till the encoder ends up as 0, it might take a while (even on my Raspberry Pi 3), but unfortunately the motor ends up in a uncontrollable state.
I realize I’m being anal here, but after all I’m a 72 year old retired programmer who likes having fun using Python to make things happen.
If someone can offer up a formula for setting an offset value to 0 an encoder reading, I’d much appreciate it.
Thanks
To set the encoder to zero, set the encoder offset to the value of the encoder then call BrickPiUpdateValues().
The firmware running on the BrickPi will subtract the encoder offset from the value of the encoder. Assuming the motors are stationary, you can zero them by writing the encoder value to the encoder offset. If the motors are rotating, then from the time you get an encoder reading until the time you set the encoder offset and get another reading, you wouldn’t ever see zero.
Thanks for replying. That’s what I surmised from looking at the firmware - only it doesn’t work on my BrickPi & RaspberryPi 3. My tests were done with the motors stopped.
After many hours of this long retired programmer’s 72 year old brain scanning the code, the acquisition of an Atmel programmer so I could place debug code in the firmware, and, I’ll bet, at least 15 firmware reprograms, I found the bug.
In firmware version 2.5, the Compressed_Communication file, ParseHandleValues function, line 539 should be:
ENC_Offset[port] = GetBits(1, 0, (GetBits(1, 0, 5)));
instead of:
ENC_Offset[port] = GetBits(1, 0, (GetBits(1, 0, 5) + 1));
My version of the firmware is too mussed up with debug stuff at the moment to offer it up.
Thank you for taking the time to dig through and find this. This is actually a bug in the BrickPi.py drivers, not in the firmware. By “fixing” it in the firmware, it will break drivers that were written correctly (such as the Raspberry Pi C drivers), and doing it that way will also limit to offsetting by only 31 bits, not a full 32 bits. I just created a pull request on Github that should fix the issue with the Python drivers.