Inside Haddington Dynamics and Their Groundbreaking Dexter Robot Arm
blog.hackster.io
blog.hackster.io
The article misses the point. The purpose of the high resolution sensing is not positional control. It's for force feedback. Here's the spec page for the robot, with more info.[2] (But too much hype. Seeing "In the loop, On the loop, Out of loop, Big Data Roadmap" on a data sheet makes me think "phony".)
Also, it's not $2,999. It's $4,888 for the base kit, and $9,800 complete and assembled. You don't have a usable robotics system at that point - you need another computer to control it. The FPGA is just motor control. Still, that's better pricing than Universal Robotics, which starts around $35K for a mechanically comparable system.
There's no reason these things should cost more than many cars. They're not that complicated. It's mostly volumes being low. That problem took down Rethink Robotics. I have a $400 3-axis uArm on my desk. This is a low end robot with RC servo grade motors. I built a six-axis force feedback end effector out of a Space Navigator for it. Controlled by ROS. The functionality is there; the precision and useful life are not.
[1] https://www.mouser.com/new/broadcom/avagoAEAT9000/ [2] http://hdrobotic.com/tech-hub/
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.
*I went to Vegas and built an arm with the founders.
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
As for the reason this robot is so expensive, the inconel harmonic drive gear boxes are probably a good portion of the cost. Harmonic drives aren't made in big production runs. The assembly instructions are somewhat horrifying and involve quite a bit of manual labor.[1] There's a lot of cutting carbon fiber rod and gluing it into the 3d printed bits. The horrifying bit is that you have to glue stuff to the motors and it appears that some assemblies aren't exactly made to come apart.
[0]https://github.com/HaddingtonDynamics/Dexter/wiki/Encoders [1]http://hdrobotic.com/dexter-v1-assembly-manual/
That would still need very accurate homing switches though.
http://www.e-mechatronics.com/download/datas/catalog/cheps80...
They use the power generated by the motor spinning to store the position.
They didn't. They use a wheel with fewer counts per rev, read an analog value, and interpolate. It's like micro-stepping a stepper motor.
https://hackaday.com/2018/11/15/an-in-depth-look-at-dexter-t...
[1] http://laughtonelectronics.com/oldsite/comm_mfg/commercial_d...
If you run cheap robot continuously, it wears down quickly.
In summary, it's a hybrid of digital and analog. To the standard quadrature encoder slit counter, we add sensing of the light levels as each slit covers or obscures the phototector. So we get e.g. 200 slits times 8096 light levels inside each slit equals over a million positions. It's so much data that we need an FPGA to process it fast enough. You can breath on the arm and it can sense it.
There is a constant battle between writing for sales/investment and writing for technical disclosure. Sometimes we get some chocolate in the peanut butter. It's certainly not phony, and I'm happy to answer any questions that anyone has about the real technical abilities.
The $2,999 price was for the Dexter 1 which was available at the time the article was written. The current generation is the Dexter HD which is more capable, much easier to build, and (as you noticed) more expensive.
Example: the mr-j4's on my CNC machine have 22 bit encoders (4 million counts per rev) and are 4+ years old at this point.
These are fairly standard equipment, and not that expensive as servos go (300 a motor, 300 a servo drive, in bulk).
It will happily position repeatedly at to any of those counts, and it's repeatable to better than 5 microns (i am only using equipment good to about 5 microns because that's what i need. I have no urge to go set up the laser interferometer to measure this better, but i have no doubt it is repeatable to better)
Yasakawa's sigma7 series are 24 bit encoders (so 16 million count per rev).
Basically current generation servos are easily in the millions per rev count.
(and since the robot are in turn made from these servos, ...) To be fair to haddington: this is a pretty wild leap from the last generation of servos in most cases.
For comparison, the melservo-j3 was only an 18 bit encoder (262,114 count per rev), and the yasakawa sigma 5's were 20 bit (1 million count per rev)
So each got better by a factor of 16 in the newest generation
The near state of the art that i'm aware of is the renishaw resolute:
https://www.renishaw.com/en/resolute-absolute-encoder-system...
Being rotary encoders, they are measuring accuracy/etc in arcseconds. For reference, 1 arcsecond is ~0.0003 degrees (1/3600th of a degree). So the +-5 arcsecond on the largest rings is 0.0015 degrees, and the +-0.5 arcsecond on the smaller is .000015 degrees.
Both are fairly ridiculously small angles.
To give a sense of scale of this error. On a circle with a radius the size of the earth, 1 arcsecond would only make an arc 30 meters long.
On a circle with a 1 meter radius, it's about 5 microns of arc length per arcsecond.
So yeah, you can do pretty well now in encoders :)
That's, uh, that's exactly what a state-of-the-art robotics lab is supposed to look like. I used to work in one; place was a mess. Then they closed some big sales, moved to a shiny new facility -- and promptly got worse, that is, worse if your goal is to actually work on cool robots rather than edit elaborate specs on theoretical robots to get Major Defense Client to sign the contract.
I'm not certain about this, but I believe that their arm does not have a final rotary actuator on the end of the arm. If the arm is used to hold a drill, for example, that does not matter.
I don't know about the robotics community on hn, but I use the Universal Robotics robot arms for sensor testing. Sensor Testing requires 6 DOF. Current Universal Robotics arms go for ~50k, and for that you get a highly repeatable robot arm, which is also safe for operation near humans, and with a good UI.
What is so hard about the final joint, Haddington? If this is a product decision, to go with a 5 axis first to get to market first, I disagree. At this moment, 5-axis robots seem more useful to manufacturing than to roboticists and robotics hobbyists. However, I would expect manufacturing to have long acquisition cycles, and to be more willing to select an expensive, yet proven, robotics company, than to take a chance on a cheap upstart, whatever their technology.
However, if you can get a 6DOF arm to within the budget of a university robotics class or individual hobbyist, who will be willing to take a chance on an unproven robotics startup, then these people will build word of mouth about your design. Teaching the math of robotic manipulation requires a 6+ DOF robotic arm. Students who learned on a Haddington arm will go into industry knowing the Haddington interface. Furthermore, it's much more likely for a $3k arm to be within the discretionary budget of an engineering team than a $50k one.
6DOF or bust, I just don't get it.
Their gripper option adds another axis.
Still if its resolution really is 50 micron it should be able to, eg, mill useful pcbs with the right head.
https://en.wikipedia.org/wiki/Supercomputer
By this definition any FPGA that has been correctly programmed is a super computer relative to a PC or non-parallel circuit performing the same task.
Couldn't you mill a PCB a lot cheaper with a 3 axis machine?
Edit: On the other hand, it would be nice to be able to probe a complex surface.
However, the whole program screams "get to market, then iterate" to me, which is a very effective way to move forward with a product like that.
Note: I've shipped products doing continuous signal processing on DSP, GPU, CPU, SoC, and FPGA. (MCU eventually... Give me time.) I did the mental swag on the described processing chain...
Out of curiosity, how big is your FPGA?
Anything that involves reading from moderately-to-insanely fast ADCs is a natural FPGA application, especially if multiple channels are involved.
At my last gig, we used FPGA's for several low-volume products.
So how are they solving the gearing problem? Harmonic drives are expensive and patented.
2. The motor dance issue happens because the feedback loop on most control systems isn't fast enough. With the FPGA, our control loop is 5 MHz / 200nS so we can correct before an oscillation has time to happen.
3. Our encoders give more than 1 million CPR (clicks per revolution) so we can sense an error before it has time to become an issue that might lead to oscillation.
(2 and 3) are the real magic of the arms design
4. Yes, Harmonic drives are hell. And they are not actually free of backlash, it's just "soft" e.g. they bend slightly. At this point, they are the best solutions, but we have prototypes of a cycloidal drive that costs less (in quantity) and gives us better performance. There are issues to work out, especially related to smoothness and wear, but we are making progress on it.