search

HaddingtonDynamics / Dexter

GNU General Public License v3.0
367 stars 85 forks source link

Fix "freakout" / tourettes when encoder eye errors #61

Closed JamesNewton closed 5 years ago

JamesNewton commented 5 years ago

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.

cfry commented 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 .

JamesNewton commented 5 years ago

Commit https://github.com/HaddingtonDynamics/Dexter/commit/0d766de6320b2e64755c999c5daa912108d5f2c9 starts on this. The raw encoder angles give an accurate enough reading of current position IF:

  1. The Joint encoder eyes are calibratable. E.g. AdcCenters.txt is correctly set and the eyes are good.
  2. There appears to be a startup offset which is pretty serious. e.g. when the robot powers up, 0 may be shown as 5000, but it is /always/ off by 5000 for that joint from then on. The code records the first reading and then subtracts that from all following readings. No idea why.

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.

JamesNewton commented 5 years ago

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.