Hacker News Reader

Comment by letstrynvm | Hacker News Reader

> Where did they get a shaft encoder with over a million counts per rev?

The article says they put the encoder directly on the motor, before gearing it down. So the effective resolution after gearing is magnified. But the encoder moves much faster accordingly, hence the need for higher speed / fpga decoding.

View on HN

No, the article says "Dexter’s optical encoders are placed directly on each joint, and have resolutions that aren’t possible with any other control system." The usual approach is an encoder on the motor, before the gear train. They probably have one too, so they can see what the motor is doing vs. the joint. Remember, none of this is rigid under load.

There's just one encoder per joint. The encoder disk is 3D printed and the cruft from the print is used to refine the encoder ticks. Instead of fighting noise they save a map of all the systematic noise and then can use a lookup table to localize.

*I went to Vegas and built an arm with the founders.

Like an optical flow applied for radial motion?

Like optical flow in that features are used, not like optical flow in that there's one standard by which all measurements can be compared to.

Does this introduce risk of future noise (fluff, chad, whatever: it's industrial applications == dirt == hostile environment) being misread, and require recalibration?

Not saying wontworkbecause. I think this calibration trick is very good and I am imagining it's applications to other things eg more precise disk head placement from noise maps of the interblock separation reads

Ya recalibration is definitely a necessary aspect of this approach if the optical reading changes. For example if IR light levels change.

Which is guaranteed with aging.

Encoders at the joint only. Motors are steppers, so we have some idea where they are but that is open loop.

Reply on news.ycombinator.com