Closed ahendrix closed 11 years ago
[dking] Eric, I've already discussed this with Kevin, we would like to know if you have any opinions on this.
[berger] It's interesting, but I'm not sure it gets us a huge win because it's not on many of the encoders.
If we want to detect and respond to encoder errors like what the lab automation team saw last week, I would prioritize making detected encoder errors visible instead of adding a second type of detection.
The existing encoder error detection was clearly pointing to the problem in the incident last week - the issue was that the users weren't aware of it.
[dking] Yeah, I guess doing matching on the encoder index is not worth the effort since there are only 2 encoders with indexes in the PR2. There is already a change that creates a diagnostic warning when encoder errors occur.
There are only a couple encoders in the PR2 that have an index signal. However, with these encoders, it is easy to constantly monitor for encoder drift / error by checking difference in encoder position when index pins goes high.
Unfortunately, the actuator data stored on MCB does not specify whether the encoder index is present. There a couple of ways to get this functionality.
Of the options, #1 is best, it is probably what we would do if there wasn't any versioning issue with the actuator data on the MCB.
trac data: