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