Closed JamesNewton closed 5 years ago
It sounds like an interesting pattern-recognition program to write that could detect physical bugs in the robot and report back to the user a hypothesis about what the physical bug is. A smart error message, as it were.
On Thu, Apr 4, 2019 at 8:29 PM JamesNewton notifications@github.com wrote:
When the eye isn't set correctly for a joint encoder, or when something external causes a failure of the encoder (gunk blocking a slot, electrical failure, the sensor block getting bumped, etc..) the reported position of the joint can suddenly jump and become unstable. It will show the joint moving in a way that is impossible; moving faster than physics would allow.
One possible solution is a monitor thread which keeps track of the change in reported position and reacts when it exceeds the limits of possibility. At a minimum, the robot should switch to open loop mode and report an error back to DDE.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaddingtonDynamics/Dexter/issues/61, or mute the thread https://github.com/notifications/unsubscribe-auth/ABITfVl8FlToVFBEgNAOksZrmcKJoqINks5vdpj5gaJpZM4cd86e .
Commit https://github.com/HaddingtonDynamics/Dexter/commit/0d766de6320b2e64755c999c5daa912108d5f2c9 starts on this. The raw encoder angles give an accurate enough reading of current position IF:
Velocity change sensing is also in there, but doesn't appear to reliably detect encoder mis-calibration. Even setting the center outside the eye only results in incorrect angles, not in random skipping of the angles. It /does/ trigger during tourettes episodes, but not for the expected joint or reliably enough to use.
TODO: MUCH.
Commit https://github.com/HaddingtonDynamics/Dexter/commit/4c595f28cb51038c252ae70aef14c245db663d84 adds boundary checking / limit to the https://github.com/HaddingtonDynamics/Dexter/commit/17c4c5e37560ef4027b8198a131e54334226ff0f changes which monitor velocity and switch to open loop mode if they are exceeded several times in a row. This /should/ stop freakouts in the future.
When the eye isn't set correctly for a joint encoder, or when something external causes a failure of the encoder (gunk blocking a slot, electrical failure, the sensor block getting bumped, etc..) the reported position of the joint can suddenly jump and become unstable. It will show the joint moving in a way that is impossible; moving faster than physics would allow.
One possible solution is a monitor thread which keeps track of the change in reported position and reacts when it exceeds the limits of possibility. At a minimum, the robot should switch to open loop mode and report an error back to DDE.