Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Startup repeatability #5

Closed
JamesNewton opened this issue Jul 28, 2018 · 4 comments
Closed

Startup repeatability #5

JamesNewton opened this issue Jul 28, 2018 · 4 comments
Assignees
Labels
enhancement New feature or request Firmware Related to DexRun.c Hardware Issues relating to the physical hardware. help wanted Extra attention is needed
Milestone

Comments

@JamesNewton
Copy link
Collaborator

JamesNewton commented Jul 28, 2018

Having a way for Dexter to find "home" position automatically would be a wonderful help. This will both allow it to accurately interact with a work surface or other object via "dead reckoning" (no need to touch or be guided to a starting point). It will also removed the need to calibrate Dexter on startup because the prior calibration can be applied immediately.

Currently, the solution to this is to add a "dial" or little knob to each motor shaft. The robot is set to a perfect zero position once during manufacture (with a test stand) then the dials are installed and their correct positions marked. While powered off, the robot is move close to the home position, then each dial is turned until it lines up with the known home position.

Automated methods of solving this problem include:

  • An index pulse on each joint encoder. The issue with this is the cost of an addition sensor and extra size of the disk. It may be possible to get the same effect by filling in one of the regular slots with a semi-transparent material (it looks like "Elmers Washable Clear Glue" works well) so that the slot is still there, still the same width, but doesn't "open" as far as the other slots. On power up, each joint would be "wiggled" until the index slot is detected. Redundancy is provided by the fact that each sensor should see the same effect, some fixed number of degrees apart.
  • A mechanical home switch on each motor shaft. Just like the dials, the arm would be preset to near the home position, then on power up, each joint would be "wiggled" until the home switch closes.
  • A "garage" or "dock" where the tool interface must be placed by the user before power up. The robot can even drive the tool interface into the edges of the dock to ensure it is well seated before setting that position as home. Or that position may be "pre-home" and home is a known number of degrees on each joint away from the pre-home position. So the robot finds pre-home, translates each joint to a new position (home) and then zeros out it's position making that home.
@JamesNewton JamesNewton added this to the Pr0t0n milestone Jul 28, 2018
@JamesNewton JamesNewton modified the milestones: Pr0t0n, Montefiore Jul 28, 2018
@JamesNewton JamesNewton added enhancement New feature or request Firmware Related to DexRun.c Hardware Issues relating to the physical hardware. help wanted Extra attention is needed labels May 3, 2019
@JamesNewton
Copy link
Collaborator Author

JamesNewton commented May 19, 2019

In order to find position faster after power up in an unknown position, a set of index pulses, instead of just one, could be used.

If the gap between index pulses is different on the two sides of the center "home" index pulse, then the correct direction to rotate to reach home. E.g. if there are an odd number of regular sized eyes between index pulses on one side of home and an even number on the other side, a small movement in any direction from any position should tell us which way to move to reach home.

If the count of regular sized eyes between index pulses increases as you move away from home, then the exact position can be found faster. E.g. on one side, there might be 4, then 6, 8 regular eyes between indexes and on the other side, 5, 7, and 9.

@cfry
Copy link
Collaborator

cfry commented May 20, 2019 via email

@JamesNewton
Copy link
Collaborator Author

JamesNewton commented Nov 19, 2019

this issue is effectively closed for the HDI robots.

Repository owner deleted a comment from JamesWigglesworth Oct 28, 2020
@JamesNewton
Copy link
Collaborator Author

Kamino cloned this issue to HaddingtonDynamics/OCADO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Firmware Related to DexRun.c Hardware Issues relating to the physical hardware. help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants