I am interested in building one. It can be the first version or the HD.

I saw a kit is mentioned, but it seems is not available anymore, at least, not on https://www.hdrobotic.com/shop, where prices start from 13.000 (ouch) and there are no kits listed.

I am wondering, has anybody built/ assembled one using just the info on github/thingiverse? Does it work, are all the parts listed, is the Bom missing something?

I would like to avoid starting ordering / making parts without any feedback on the feasibility of making it. Thanks!

Can I build a Dexter HDI now?

The HDI has NOT been fully open sourced. However, some of the changes from HD to HDI have been, e.g. the diff. It's all on the public github repo, especially under the wiki. The hardest parts are 1. getting the electronics (we keep hoping someone will layout an open source PCB, we make all the schematics available), 2. Getting the wave drives (email Harmonic) 3. Finding the chips, during the pandemic shortage. Honestly, it's a challenging built, but it IS still possible. 

Great! Maybe, I can help with the PCBA part. Is it the optical encoder or the Xilinx FPGA that needs to be layout? Also, the mechanical parts are the same except the Differential Joint, right? I only see HDI mentioned on the Differential joint page in the Github wiki. 

I'm replying to myself here because it's not allowing me to reply to you.

All the PCBs need new layouts. But the optical encoder is trivial, so I wouldn't worry about that. The FPGA is currently on one board (a MicroZed) and the Motor Control Board (MCB) plugs into that. One of the problems is that because of the way the connectors are setup on the MicroZed, most of the board space on the MCB is taken up running traces. The real solution is to re-design the MicroZed / MCB stack into a single board... or into an FPGA / Analog board with a connector on the bottom that plugs only the necessary signals into a Motor / Power board. We don't need all the stuff on the MicroZed, and if you keep all the signals we do need connected the same, the .bit file for the FPGA should work without modification (and you can't modify it... or rather... you can, but it would be really difficult). That is still a heck of a complex board design, because the MicroZed is a really tricky layout to meet all the requirements of the FPGA. This is not an entry level project! LOL. But it should be in the scope of medium to advanced open source boards. 

There ARE a few other (minor) differences between the HD and the HDI but a good mechanical engineer would see them easily, and the robot is still useful without them. 

Thanks for the detailed information! I have experience with the Altera cyclone FPGAs to control high-speed ADC, DDR SDRAM, and PCIe interface. I may just have the required skills for this design, although I never used a Xilinx FPGA. There are several websites related to this project, I wonder where should I start first. Should I start by building a Dexter HD, then upgrade it to HDI? Is the OnShape version most current? I also clone the fusion360 version HDI, but I think it's mostly outer shells. 

The big question is what printer you have available. If you have access to carbon fiber, the HD makes the most sense. If you have PLA, then you should certainly print the Dexter 1; it's a tougher build (lots of little bits to strengthen the PLA) but it's also more rigid (carbon fiber is typically bound in nylon and so it deforms) and perfectly usable. If you want, you could try the HD in PETG or a resin if you can print with those.  Don't get hung up on the idea that later versions are "better" they all have good and bad points, as I've indicated. 

If you just want to print one of the version, use the links to the STL files from the Hardware Wiki page. If you want to make design changes, OnShape is the only option. 

I have built a Voron2.4 350*350 recently, but I did not try anything but PETG with it. The reason I care about the version HD or HDI is that I plan to use it to perform some precision tasks. I read about the HDI on the official website, and find it quite enough for my future applications. But I can't find detailed info about the performance difference between HD and HDI, so I think I should try to build an HDI. 

The Dexter 1 is just as precise as the HD or HDI. They have a bit more load capacity, e.g. 2 or 3 kg (with counterweights) vs the Dexter 1 at 1 or 2 kg. Dexter 1 is stiffer, which means it can hold a precise position better.

Also, keep in mind the difference between accuracy and precision. Dexter is precise. It is only accurate /after/ calibration. I mention this because a LOT of people are confused about the difference between accuracy and precision. 

Please show one video. Cut wood similar cnc but in 6D = XYZABC

Dexter doesn't have the stiffness required to cut wood. Polish, paint, burn, etc... would work. We've done laser etching. 3D printing has been on our todo list for a long long time, but we've just never had the time to do it. LOL. Should be possible. And... it should be possible to mount the extruder (or extruders) on a fixed external mount and then have Dex hold the build plate. That way, you can print up a face, then turn the print sideways and print off in another direction, avoiding supports.

robot arm has many advantages but

but for it to be suitable for anything there has to be pressure. Cutting in wood (the simplest) is what illustrates how useful this tool is. arm must be able to control material cut, pressure, resistance 

unless it's just a gadget for the movie and not a tool

I guess pick n place machines have to cut wood? 3D printers have to cut wood? We can apply 3KG of pressure, but without /stiffness/ that will not correctly cut wood. We can operate a drill press, serve beer, load strawberry flats, dispense soft serve ice cream, do medical testing, tend other robots like CNC machine, or pressure mold, or 3D printer, and on and on... but sadly, since we can't cut wood, we are useless. LOL. Build a CNC machine or router for cutting wood. And Dexter can load planks, operate the CNC software, and remove the finished parts for you. 

Just so you know, there's another robot arm called Dexter:

https://www.gamechangers.technology/oxford-technologies-drhcell-robotics/

Or here:

https://www.nuclearsolutions.veolia.com/en/our-expertise/technologies/dexter-our-propriety-remote-manipulator-system

Your's is much more accessible.  Excellent work!

what is the difference between the buyable one and this have you implemented any new ideas

The Dexter HD simplified the build process and improved the accuracy of the original by reducing the amount of parts and glue needed for assembly.

The Dexter HDI reduced the amount of glue used even further in favor of bolts and threaded inserts as well as decantilevering the pulleys with some new parts. The code disks were also changed so that Dexter can achieve absolute positioning as opposed to the relative positioning that we've been working with up until the HDI. This is done by closing off some of the slits slightly and having the encoders monitor where those points are. 

We don't currently have a timeline on when we will be open sourcing the HDI, but it will be when we move onto our next version of the design.

Most force/impedance robotic control systems measure torque to detect an obstacle collision. Does Dexter measure torque perhaps through the motor control circuit, or just use the joint position, or joint position rate of change to detect an obstacle? James, I noticed that you sell magnetic abolute position sensors on your site. The AS5047 gives you 16,384 counts per revolution at about 10-20khz. This is much lower than the one million CPR of your sensor, but was this not high enough resolution or fast enough to do force control?

First, my own site and encoders have nothing to do with Dexter or Haddington Dynamics. The AS5047 is 4000 CPR, not 16K. The sensor on the Dexter is very much NOT my design, it was developed by Kent, the principle designer at Haddington Dynamics. 

Dexter measures position only, but because it is so sensitive, it can detect forces like a cotton ball being dropped on the arm. 

Has anyone implemented this on anything other than the microzed fpga? It's 5 years old and there are cheaper alternatives now. 

I think we would love to hear about alternatives which support the same general capabilities: Same FPGA size, 32 bit ARM core, Ubuntu, lots of IO. We've been talking to Avnet about the platform. 

Will the .BIT file work on other xilinx boards or only the MicroZed?

I'm honestly not 100% sure. I'll have to ask our lead about that, but my understanding is that the .BIT file is designed for the chip used on the MicroZed, so it would work on any board that had that chip... and... that had the IO pins from the chip connected in the same way that the MicroZed connects them... so, technically "yes" but effectively "no". 

I came here after receiving an email on the Hackaday prizes, and started researching. This project is fantastic, I am most impressed with the Dexter Development Environment (DDE).

I won't be building this till I've simulated my intended use (using the DDE and maybe FreeCAD [1]) and any cycloidal drive prototype stl's are released. Three harmonic drives at >$100 each [2] in addition to everything else is out of my budget/risk appetite. My personality is such that I'll trade time and labor to minimize expenses and optimize things, you learn more that way anyway, it is what I enjoy!

----------------------------------------------
Slip Ring
----------------------------------------------
8mm slip ring referenced on page 4 of assembly manual. Looking at BaseLite.stl, which slip ring fits over, diameter is 84.3mm.

As the large copper rings appear to be manufactured in bulk by punching/stamping copper sheet [3] (requires machining of stamp), the most cost efficient choice would be to choose some "standard" size that is already mass produced. Using the Conflat Flange (CF) 80 gaskets, used in the high vacuum industry, would be a good fit. 80 refers to the ID in mm, but rounded down, see chart [4]. CF100, with ID of 102mm, appears to be more commonly used/available. No CF80 on Aliexpress, but many Alibaba sellers. CF80 distributor on Ebay sells 2 for $20 [5], but the cheapest single CF100 I could find is $5.50, so...

I can see the assembly manual right now starts but doesn't finish the slip ring connection. Skimming through the videos/webinars I couldn't find directions for the slip ring.

----------------------------------------------
Carbon Fiber Parts
----------------------------------------------
Costs via DragonPlate supplier (for comparison):

1.5mm 4.4mm 705mm CF strake: $4.53 (.057" x .177" x 48") [7]
2.5mm 5.6mm 2652mm CF strake: 2x $8.67 (.092" x .220" x 48") + $4.77 ( .092" x .220" x 24")
3.2mm 12.6mm 2616mm CF strake: 2x $12.74 (.125" x .500" x 48") + $7.01 (.125" x .500" x 24")
5mm 20mm 321mm CF strake: $8.81 (.200" x .250" x 24")
6mm 8mm 137mm CF rod/tube: $5.05 (.315"OD x .239"ID x 24") [8]
1" CF Square Tube: $60.75 [9] (base arm)
.75" CF Square Tube: $49.75 [10] (forearm)

Cart total is $183.49. And shipping at checkout is "Shipping charges are calculated when order ships"... Would save some $ by using 1" tube for the forearm, but would have to change model.

----------------------------------------------
DIY Carbon Fiber Parts
----------------------------------------------
Making the CF strakes/rods from carbon fiber sheet and epoxy is an option worth considering. It looks to be lower cost and higher labor, but I see an opportunities like customizability and making a skin [6] using scrap materials. There are plenty of forum guides on making CF parts by hand, and in the future, by robot arm? :)

Carbon fiber fabric:
.23mm 1yd@$13.5/yd 36" [11]
.38mm 1yd@$17/yd 50" [12]

Layer 4 .38mm CF fabrics for 1.5mm thickness strakes, and etcetera:
.38mm*4 = 1.52mm
.38mm*6 + .23mm = 2.51mm
.38mm*6 + .23mm*4 = 3.2mm
.38mm*12+ .23mm = 5.02mm

Cured sheets would then be cut with table saw [13], or possibly by Dexter as he is so precise!

Only 4.05ft^2 of 12.5ft^2 .38mm fabric used; much to spare!

1" square aluminum stock (~$23 for 72" at US stores) can be the form for the square CF tubes [14]. And a 6mm aluminum rod (~$1-2) as the form for the CF tubes.

DIY Cost: $115.45 = $13.5 (.23mm CF) + $17 (.38mm CF) + $45 (Quart 820 Epoxy) + $15 (US shipping estimate) + $23 (1" aluminum stock, cheaper with a trip to the scrapyard)

Savings over DragonPlate and only using ~1/3 of the Carbon Fiber ordered. Downsides are less quality parts and no fancy cure process (e.g. curing oven to raise temperature resistance and mechanical properties [15]).

----------------------------------------------
FPGA
----------------------------------------------
MicroZed: $178+sh [16]

Might find a cheaper reseller or alternative, e.g. Xilinx Z-turn lite $117 [17] or $103 [18]. Would be nice to know what VIVA is compatible with, esp. considering this MicroZed can handle a lot more than Dexter's stock requirements.

P.S. I like your twitter quote of Stephen Hawking, we should be scared of capitalism, not robots. "If machines produce everything we need, the outcome will depend on how things are distributed."

[1] http://hdrobotic.com/dexter-community/#!/general:freecad
[2] https://hackaday.com/2018/08/24/a-peek-at-the-mesmerizing-action-of-a-cycloidal-drive/#comment-4976153
[3] https://www.ebay.com/itm/253978363132
[4] https://i.ebayimg.com/images/g/LE4AAOSw9~Rb6nKP/s-l1600.jpg
[5] https://picclick.com/2pcs-CF80-Copper-Gasket-New-Vacuum-Pump-Flange-173608218978.html
[6] https://github.com/HaddingtonDynamics/Dexter/issues/4
[7] https://dragonplate.com/Carbon-Fiber-Strip
[8] https://dragonplate.com/DragonPlate-Carbon-Tube-315OD-x-239ID-x-24
[9] https://dragonplate.com/Carbon-Fiber-Roll-Wrapped-Twill-Square-Tube-1-ID-x-1-ID-x-24
[10] https://dragonplate.com/carbon-fiber-roll-wrapped-twill-square-tube-075-id-x-075-id-x-24-3
[11] https://www.sollercomposites.com/Carbon-3K-Fabrics.html
[12] https://www.sollercomposites.com/Carbon-6K-Fabrics.html
[13] https://www.practicalmachinist.com/vb/general/cutting-carbon-fiber-plate-216679/
[14] https://www.bentrideronline.com/messageboard/showthread.php?t=3120
[15] http://www.shadowaero.com/COMPONENTS.htm
[16] https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-z7mb-7z010-som-g-rev-f-3074457345635221615/
[17] https://www.aliexpress.com/item/XILINX-Z-turn-lite-ZYNQ-7010-ARM-Cortex-A9-with-FPGA-dual-core-Development-Board-Control/32836668246.html
[18] https://www.xilinx.com/products/boards-and-kits/1-pcz4jb.html

Hey Andrew, 
Nice work tracking all that down. We do have a partial BOM (linked from the repo) but it is a bit out of date and could certainly use to be updated. Let me know if you want to help update it. We did raise a help wanted issue about it.
https://github.com/HaddingtonDynamics/Dexter/issues/34
I've made that google sheet "Anyone can comment" so if you want to leave notes on it, go for it, and if you want to edit, just ask me.

Andrew, true confessions here: We've all disabled the slip rings on our robots... they just are NOT reliable and they cause so many problems with reliability that we gave up on them. If someone out there that can make a reliable slip ring, please let us know. Anyway, the robots typically don't need to spin around for the bulk of the work they do is all in the same quadrant. 

As I understand it, Viva is a high level design tool so it's compatible with any FPGA that we can get an accurate descriptor... file... format... thingy... for. I'm not the expert on that so I'ma shut up now. 

What I AM an expert on is firmware, so I'm starting work on a code only (no FPGA) version with a lasercut encoder which should be as accurate (or better with a good laser) but much much slower. It's designed for human input, so you can make a non-powered "arm" with this, connect to a Dexter arm somewhere else in the world, and control it by moving this low cost local "arm" encoder around. Please consider being involved:
https://github.com/JamesNewton/HybridDiskEncoder

I'm hoping we can use the Cypress PSoC chips because they have a good 32 bit ARM core, enough memory to do ATAN2 (which is the necessary math), they have an onboard programmable analog front end, AND... they have a little FPGA which we may be able to use in the future to increase speed. 

Now that I look more, I think the MicroZed looks quite interesting. I'm sold after seeing the MicroZed chronicles, seeing OpenCV works with it, and utility for other projects.

I think it best for now I offer suggestions/ideas where I think I may have something to contribute. I hope I can get through other projects and start building Dexter, though there is much preliminary reading I must do. 3kg payload, very impressive!

Andrew, don't hesitate to ask if there is anything we can do to help you get started building a Dexter.

What is the approx BOM cost?  How much can we expect to pay for all the materials?  Will you create a kickstarter or "kit" that we can purchase and install ourselves? Thank you and congratulations!

I was just about to ask what the BOM cost is. my 3D printer is currently down, I'm redesigning it. So also, I was wondering about PLA components. 

They have a kit apparently : http://hdrobotic.com/store

The kit is $2,999. If you tried to make this yourself without the kit, I would give it a ball park figure of about half that, but I would research it completely before diving in.

We will be moving to an HD kit which will be available soon on our website.

Thank you for the congrats!!

We have the BOM on our GitHub space.  It is being updated.  The HD BOM is in progress.

Congrats on your prize.

I really like your idea for artificially increasing the sensor resolution. 

I had another idea about arm position sensing: running a cable from next join to the one that is sensed, wind it around the encoder with a spring, to be able to also sense the backlash and the deflection of the instrumented segment.

Hey, sorry I didn't see this comment earlier... not sure how I missed it. Yes, I've done exactly that with a 4000 CPR magnetic encoder and got 4 clicks per 1/1000 of movement on a CNC conversion. You have to watch out for a few things:

1. The string will stretch, vibrate, and eventually fail. The stretch isn't a big deal as long as the force on the string is very consistent. It will drift for a while, then settle. However... that drift will re-appear with some types of string based on heat, humidity, and the phase of the moon. So it's really best for relative movement and must be re-homed on start-up (not a big deal)

2. If the shaft of the encoder requires any torque to move, it will either slip or will "drift" into place after the move. e.g. you will see the reading change after motion has stopped as the string stretches to balance the force on either side of the shaft. The non-contact magnetic encoder eliminated this issue, and most good optical encoders should be fine, but I've seen a lot of them that require significant torque to turn, and I would be leary of that issue.

3. You have to be really careful about the string not touching anything or rubbing or vibrating. Not sure how much of a problem that actually is, but I'd watch out for it.

You might be interested in this project where we are applying the method used on Dexters encoder to a very low cost laser cut / 3d printed encoder system that can be used separately from the Dexter control electronics:

https://github.com/JamesNewton/HybridDiskEncoder

thank you for your insightful answer. 

Have you looked into contactless sensors, like time of flight or interferometry? I am still thinking of having sloppier joints to reduce the cost, and try to sense and correct the error.

I like your sub-project on the quadrature sensor, in particular it validates my obsession with telling people that PSoC are the gateway to FPGAs :)

1) I have not found your exact calibration procedure

2) are you running at a "dual rate" where at high speed your just read the thresholded LED like a normal encoder, and at slow speed you try to finely discern the intensity of the LED?

Yes, using an encoder on the joint to compensate for a lower cost drive train is smart. That's exactly why I was doing that for the CNC. No ball screws, just very sloppy lead screws on the Z axis.

As I said, I used a non-contact magnetic encoder. This one specifically:
http://massmind.ecomorder.com/techref/ecomprice.asp?p=416083
I don't know much about TOF or interferometry to be honest. I'd love to learn more about them. 

If you have experience with the PSoC chips, I'd love any advice or help you can offer. I'm new to them, and loving it, but stumbling through it.

1. The project isn't to that point yet. I'm hoping the only calibration needed will be setting the drive levels on the LEDs. Time will tell.

2. That's the plan, but not at first. We are targeting this at human input, so speed isn't an issue. 

Amazing project. Congratulations on your 1st Prize at the 2018 Hackaday Prize. Way to go. Looking forward to the next rev of this project.

Where do you buy the gearboxes? A couple years back I was looking for essentially exactly those gearboxes and could not for the life of me find a distributor or reseller. (Some manufacturers will sell their products directly to individuals but many will not (either because volume would be too low or because they are only set up for business-to-business sales)).

Hello, we normally buy them from HanZhen. http://www.hanzh.com/product-2.html

How much do the harmonic drives cost?

holy hell knowing I can buy these just opened many doors in my mind

Kenneth, the prices vary widely depending on specs, source, qty, etc... but they are generally not real cheap. $50 to $100 range. 

AVR, yep! They are cool ask heck, but if you want your mind really blown, look into cycloidal drives. e.g:
https://hackaday.com/2018/08/24/a-peek-at-the-mesmerizing-action-of-a-cycloidal-drive/

The price isn't much lower, because they use so many little bearings, but they are very configurable, and can avoid a type of backlash caused by bending / deformation. 

STOP IT! Too many cool things! I'm having yet another "something shiny!" moment. And it's the third I've had in as many minutes.

LOL. Ok, ok... The responses before ARE written by the guy at HD who does marketing. It's funny to me that he is providing the very best answers he can provide, given data from the techs and engineers in the company, and it still doesn't make anyone happy because of the language. Give the poor guy a break? 

So I'm an engineer at HD (firmware, testing, working on Arduino compatible smarts in the new end effector). And I'm a long time OSH / FOSS supporter. And I completely freaking fail at marketing (check my side business. LOL). 

Maybe a conversation with me is better? I'll post some responses below this.

1. ITAR, CCL, whatever stupid government regulation it actually is we don't care about. We aren't allowed to put an encoder on the 'bot that exceeds a certain angular resolution and then sell the bot outside the USA. It's freaking stupid and very annoying, but we want to stay out of jail so we do as we are told. 

From a technical perspective, the encoder is AMAZING! I have a Dexter, I know what it can do. There ARE problems with it, but they are mostly related to the processing of the data and not related to the encoder itself. e.g. We currently are not exposing the actual joint angle from the FPGA to the onboard Firmware, but that's on the "backlog" list for the next iteration. As a result, we currently can't read back the actual joint angle in the firmware, we only send a desired joint angle and the system "makes it so". We can get back the error, and other status info, but actual join angle is important and we will add it. This presentation may do a better job of explaining how the encoder works and why it's able to do more:

https://docs.google.com/presentation/d/1YGBnNvxhoP9J7alk5sASB5aUM_wg30fUuiZzM94uL2w/edit?usp=sharing

Let me know if you have more questions about the encoder. It's a technology I think more people should understand, so I'm happy to spend more time explaining it.

instead of using the slots in the encoder disk as "on", "off" / "black", "white" / binary values, we use the optical sensors in /analog/ mode. With a high resolution ADC, we get thousands of positions per slot. And yes, those are not perfectly linear, and yes, there is noise and all that poop. But the end result is MUCH higher resolution than a standard encoder. Fantastic repeatability (NOT accuracy). And it's a pretty cool idea, huh?

But even in home applications, why NOT print a low res encoder disk, use photodiodes and A2D encoders, and get higher resolution positioning? It's a freaking cool idea! And we open sourced it. 

 2. Massively parallel, super whatever... who cares? It's an FPGA doing stuff faster than the FIrmware can do it. That the point. That's cool. Really, really cool, actually. It gives us a stunningly fast feedback time so we can do things like adjust the "springiness" of the response. Or switch into a compliant "follow" mode instead of position "keep" mode. In follow, you can grab the robot, move it around, and record waypoints or the entire path. Then play back, insert into a program, whatever. It makes it really easy to use. 

One issue we have right now is that you have to return to "home" to switch from follow to keep modes, but we are working on that as well. It's a tricky problem that we didn't see coming, and honestly, it's over my head why it doesn't work. 

3. Open source: Dexter is as open source as we can legally make it. There is ONE area of Dexter that isn't /really/ fully open source and that is, as modzer0 points out, the HDL for the FPGA. The reason for that is that our primary engineer, who developed the HDL himself. It's called "Viva". He sold it to another company and that company is sitting on it. It's a decision he may well regret, but feeding the family is sometimes a good idea, no? He has a resale license, and can "sell" a copy here and there for $1, but there are limits on his ability to do that. 

The files that come out of the HDL are available online (in the github) and they are /technically/ editable, and the source file is also there, but yeah... we get it. It's not really fully open source on that point because the editor isn't available to the general public. 

So why not use a "standard" HDL? I'm so glad you asked. Because, and this is really important, so please read to the end and think about it, all the existing HDL's for FPGA design force you to THINK in sequence as you write the code. Our HDL, "Viva" is graphical. It shows you things on the screen in a format that more closely represents what is actually happening in the FPGA. If you write in a standard HDL, you have to think about a process that is parallel, then transcribe it into an inherently serial form (the HDL) then it gets processed back into parallel operation. With Viva, you think, and draw in parallel. It's just better, and it's what the big mfgrs /should/ be providing and are not. 

More than that, it's the format our principle developer thinks in and works in, so we aren't going to change it. Sorry. End of story. Not going to burn more cycles defending that. 

If you want to reject our FPGA claims, that's your choice and there isn't much we can do about it. I'll try to post screenshots if that helps? I think I can do that...

If you want to reject "massively parallel" and "FPGA super computer" then... LOL. Yeah, I kind of agree with you. Those are marketing words. But the FPGA IS doing cool things for us, it DOES solve a lot of problems, and you CAN see that in our demos and in person if you are near someone who has a robot. 

If anyone in the SoCal area wants a demo, and can make it to Escondido, I'll happily setup and time and show you what the robot can, and can not, do. We go to Maker Faires all the time, stop by and see for yourself. All the other parts of Dexter are FULLY open source. The firmware, the hardware (schematics, PCB's, etc...) the physical objects, etc... I've printed new end effectors from the files on OnShape. I'm using CircuitMaker.com for the power supplies (and soon the new interface board) for the new end effector. 

If there is something (other than the FPGA HDL) that we've missed sharing, please point it out. 

3. The "end all scarcity" / robots in Africa thing. That's the goal. SpaceX wants to make humans interplanetary. All sorts of AI companies have crazy end goals. We set our sights high. At this point, other people have used Dexter to cut things with a laser, make art, tend a 3D printer (remove the finished part and dump it in a box), run a camera (a youTuber), stuff like that. We are short on practical applications, and we need YOU involved to find and solve problems with our "solution" (with Dexter). 

Our best application at this point is teaching people how to make a robot and NYIT is using it for exactly that at this time. 

If you wanna learn how to make a really cool robot, dig into the github. Post issues if you find a problem / don't understand something / can't find something. We REALLY want people to get involved in the project:
https://github.com/HaddingtonDynamics/Dexter
(p.s. please check out the wiki... I've worked really hard on that and I'm proud of it, but I want feedback on how to improve it.)

Understand that Hackaday is a haven and focal point for a large number of hackers, hardware hackers, reverse engineers, hobbyists, makers, and professionals in related fields. A large percentage of them love seeing tech scams dismantled and destroyed. Some systematically discredit marketing claims for recreation. The number one response from those scammers is marketing speak, and the tactic of attacking the credibility of those posting hard technical questions or even basic science why their product will not work as advertised. The people behind those scams have large teams of marketers and few if any engineers.

There are people who will fall for those tactics, and there are those who see right through them and smell bullshit. Hackaday has a large percentage of the latter.

A bit of advise for this site is to take any interaction with it away from the marketing guy. Remove all the claims in the description and stick to technical details. You don't have to be a good communicator. In fact if you're too good it will just create skepticism. Post about the process. The problems and how you worked through them. It should be about how things work and how you made them work. That's the purpose of the site. A place to show off projects and build logs.

One thing never to do is trying to undermine someone's credibility rather than addressing the technical questions. That's a fatal mistake as evidenced by Modzer0's surprisingly polite checkmate followed by the forceful creation of a new orifice for your marketing guy. Don't try the marketing impulse to delete the jab.  If he just apologizes everyone will forget it. Trying to cover it up will just make screenshots surface and you'll look even worse. Integrity is increasingly rare these days, displaying some will help fix that damage. Don't act like the tech scammers who are all marketing.

If you discuss the problems you have with designs you'll find people will help you with solutions.

Yeah, Daniel, I hear you and you are right. But the engineers at the company are heads down working, and we tend to forget about reaching out. Our bad, I know. I mean, we have a marketing guy to do the "reach out" stuff, so he is just trying to do his job. Honestly, it's my fault because I'm pretty sure he said something about posting on Hackaday and I should have twigged that it wasn't the right fit. I'm the only (I think) engineer at the place who has been on hackaday before going to work there, so I do understand and I should have caught it quicker. 

I do hope my responses and the details I've provided have answered your and others concerns? If you have any other questions, please don't hesitate to ask and I'll do my best to answer them. It would be a crying shame if I fail to convey how truly frick'n cool this robot and this company really are. Seriously, I have this job today because I spent a good long time contributing via open source just because I could see how amazing it is. I only got hired because I was whining about my regular day job being cut back and they wanted me to spend more time with them! LOL. 

Classy, labeling me as 'angry'. Such things are typically a defensive statement when one feels their ability to respond is in a weakened position.

I also never asked for your 'ITAR' data because you have none. ITAR deals with items and companies dealing with such defined in the USML. What you linked is the CCL, the commerce control list. Any microcontroller with a processor speed over 40Mhz is technically under that as well. I've actually had to sign export control documents to buy ESP32 modules that were imported from China to begin with.

As for the USML the use of a high resolution encoder in a robot arm isn't defined as a munition as it is:

 (1) not 'specially designed' to be a weapon system

(2) not used in angular control of devices designed for infrared optical tracking for intelligence gathering purposes.

(3) not a device used to track angular rate or position of missile technology(MT) that doesn't apply to rotary encoders and wasn't funded by the DoD

(4) is not space qualified and is not being used in an instrumentation radar

Lots of people misunderstand the things ITAR applies to

FPGAs can do tasks in parallel. It all depends on the contents of the bitstream given to it. If it's given a single cpu IP say something like a small pure stack based CPU then it is not in fact 'completely parallel'. It depends on how you use it. The way you describe it is how a marketing person would word it to impress potential customers. FPGAs are just configurable hardware, though very useful configurable hardware that can be used as application accelerators processing data clock for clock more efficiently than a general purpose CPU. That's why there's quite a number of motion control IP available.

I love FPGAs, I don't love the development environments or having to keep multiple versions of very large dev tools installed just because I'm working on an older FPGA. The licensing is something that gives finance bad dreams. Also a 'typical' 30 person FPGA team? That's a very large team.

As for the 'Duopoly' you almost make that sound like a conspiracy. You sure it wasn't them just supporting languages that were IEEE standardized and didn't come with very high license fees?

Can I be honest? We really aren't government employees and we really don't understand all that regulatory crap. Or at least I don't. We were told to limit the resolution and we didn't want to get into any trouble with the government so we did it.

Can we get back to the technology? Because that's what's really cool! Have you seen how the encoder actually works? This presentation might help explain it:
https://docs.google.com/presentation/d/1YGBnNvxhoP9J7alk5sASB5aUM_wg30fUuiZzM94uL2w/edit?usp=sharing

instead of using the slots in the encoder disk as "on", "off" / "black", "white" / binary values, we use the optical sensors in /analog/ mode. With effective 13 bit resolution, (12 bit but dithered) we get 8096 positions per slot. And yes, those are not perfectly linear, and yes, there is noise and all that poop. But the end result is MUCH higher resolution than a standard encoder. Fantastic repeatability (NOT accuracy). And it's a pretty cool idea, huh? Watch the video above... I've seen that demo in person. Swing by my office in Escondido, CA and I'll happily show you.

It's really wild when you use 2 robots slaved together because the human operator takes out any accuracy issues. The 2nd can send back position errors to the first, which can then use that to increase the position resistance which provides the operator with "feeling" from remote touches. It's amazing if you experience it yourself. Sadly, I only have one Dexter at my office, so I've only seen that at the main office in Las Vegas and at the Maker Faires. I think we will be at New York Maker Faire, September 22,23 and then San Diego Maker Faire October 6,7.  Come down and see it! 

But even in home applications, why NOT print a low res encoder disk, use photodiodes and A2D encoders, and get higher resolution positioning? And then if you know FPGAs you should be able to code up a feedback loop (PID or whatever) and use that to regulate the joint. 

I remember this from the kickstarter and the ridiculous claims of supercomputer FPGAs and how it would somehow solve a bunch of problems. All the claims of open source yet the provided HDL wasn't even complete. Nothing about it was that exceptional considering the amount of off the shelf IP available for motion control. The kickstarter video with all of it's helping the impoverished and buzzword marketing tactics says a lot about the people behind it.

Then there's this 'project' that's purely marketing itself.

Thank you for your input. We are sorry that you are dissatisfied with our project. We use an FPGA board with in-house code written by Kent Gilson, the pioneer of hypercomputing, with FPGAs using his own language.  With a pinch of research, you would have been able to see that we do not use Verilog or HDL.  We can get a 33 million gate program onto an off-the shelf Zed board.  Here is an early article from 2003 in Forbes regarding the founder’s work. https://www.forbes.com/2003/03/25/cz_dl_0325star2.html#2794832ef226 Here is an article to explain how we are doing what we are doing and how different it is from current control systems. https://www.roboticstomorrow.com/article/2018/06/using-fpga-supercomputers-to-build-a-high-precision-robot/12145- There was a big launch at automatica-Munich for an 8kHz control system.  We are currently running at 100kHz on each joint.  We restricted our encoders to 19.5bit so we don’t hit ITAR restrictions and therefore can not open source what we have done.  Lastly, not sure how to take your final comment regarding the marketing buzzwords.  If you are saying we are not sincere in our convictions to use technology to help others with a goal of ending scarcity, then I would direct you to the website https://www.whycantwe.org/ which was written by Fry (co-founder) and his fellow MIT colleague Henry Liberman.  One final link to help you and others understand our influences – I direct you to Jeremy Rifkin and The Third Industrial Revolution.  https://www.youtube.com/watch?v=QX3M8Ka9vUA Hopefully these links help you and others understand what we are doing.  

I appreciate your answer

An answer filled with more marketing. You keep repeating your founder's name like he invented the wheel or something. The hypercomputing you referred to is best described as 'hype' computing as it was all mostly hype with little substance other than taking people's money.  It's much like someone proudly stating that they invented Steorn's Orbo. Then you're using some magic FPGA language that's so great that no one has really heard of it in professional circles. So color me very skeptical of any claims without visible, testable, and verifiable results. You restricted the encoders? Great, remove those restrictions on the encoders and show us the results associated part numbers, and code that people can actually synthesize/compile and use for independant verification. It's also fairly easy to fine tune motors for a single repeated movement.

How about repeating the movement accuracy test say 10 times, then picking up a 100 gram weight and repeating it to increment up to the practical weight limit of the arm. Continuous video with no cuts.

As for ITAR, please provide specifics on the exact item you're in danger of exceeding. I have quite a bit of familiarity with it as much of my work is for the DoD and US Government.

As for my reference to marketing terms I refer to the continuous use of terms like 'supercomputer' to describe the FPGA based motor control system. That is a textbook example of a marketing buzzword.

I'm a scientist at heart so my default skepticism isn't fixed. The burden of proof is on you. I'll sing your praise if proof is independently verifiable.

Prove you're not like Waterseer of which your feel good help the people marketing video for a robotic arm of all things sounds very similar. Engineers and scientists told them their design wouldn't work and they kept claiming it did. Now they've switched to what's basically an overpriced dehumidifier proving everyone who told them their ground and wind based passive system would never really work much less come near their claimed values correct. Then there's solar roadways with all of it's hype and after taking in millions they still haven't paved a road or made a test installation that's net positive on power generation.

Then there's the simple reality of the modern tech economy. If it was really that good the company would have already been bought. Instead you're marketing hobby robotic arms on a site primarily for personal projects.

Skeptics are always welcomed – however you come across more angry than skeptic.  Not sure we can resolve that other than provide more information which you will promptly call marketing.  Either we stepped on your toes or this is just you.

We use the term hyper or super to provide context to massively parallel computational horsepower. 
A typical FPGA team is around 30 folks in 6 divisions (integration, testing, timing etc..)  We do not have these constraints.  Regarding why this language is not adopted or widespread - you need not look further than the duopoly that is Xilinx or Alterra.  What hardware company is going to support software that is agnostic to its manufacturer.  They make their money on the software- a challenge to that will not be supported.  Also, if FPGAs were not a serious contender for where hardware is going – would Intel spend north of $13B to buy Alterra?
Regarding ITAR restrictions - an encoder that is 20bits can steer lasers accurately.  Beam steering is not open source material.  You are an anonymous individual, so we have no idea of your credentials but based on your statement above you ‘work for the DoD and US Government’ then it should not have taken a request to us regarding ITAR restrictions on optical encoders.  But again, we don’t know who you are. https://www.bis.doc.gov/index.php/documents/regulations-docs/federal-register-notices/federal-register-2014/990-ccl3-2/file page 14.
You want a part number?  The layout to our Opto board is here https://github.com/HaddingtonDynamics/Dexter.  ‘It’s just a simple optical encoder system where we turn a 3D printed code disk into an analog sine cosine wave to get a circle and do interpolation from it. We record a table and then compare against that table to normalize, 2 million samples per second. Which spread over 10 converters--2 at a time--equals 200,000 samples per second per LED/phototransistor which gives us 100,000 (100kHz) frequency bandwidth per axis. From that we get loads of data. We can then use signal processing to get process gain. And all of this is done in real time.  FPGAs are completely parallel. It’s completely different from a processor where you have one thread running or multiple threads running. Everything is happening all the time simultaneously; you have to be explicit about things that are synchronized because it’s all happening at once.’ 
This can’t be done with serial processors that are “so abundant” on the internet today.  If you don’t want precision and haptics at a low cost – there are plenty of alternatives.
Regarding outside testing – you are absolutely correct.  Let others challenge our statements.  We applaud testing.  Which is kind of funny that you are arguing for us to prove ourselves and yet at the same time our proving ourselves means nothing if it not outside tested.  So far we have received positive feedback from Google X, Toyota Research Institute, New York Institute of Technology, NASA, Axiom Electronics and others that we can’t talk about because of NDAs.
When you have disruptive technology, you want to make sure it is available to the bright minds.  Many of those bright minds are in the maker community and can expand the capabilities of our robot beyond what we could do as a small company.  And getting to the people has worked.  Here is a link to one of our clients working with Dexter on a path we would not have taken as a company.  Robots/AI/painting https://www.facebook.com/ZSparkyThoughts/videos/214948589158880/
Presenting on this site was not a marketing ploy.  We were asked at the Bay Area Maker Faire to please submit our information – they liked what we were doing.  They liked that we were also working with a university that is moving to a maker focus.  In fact, 6 courses this fall at NYIT will have our technology as part of their curriculum.  Giving makers new tools is both economically viable and creatively exuberant.  
We knew when we open sourced that we took a large chunk of potential buyers and investors off the table.  This was a calculated decision, the only way to get disruptive tech into the market was to make sure everyone had access to it.  We had plenty of investors on the upfront with silly valuations – they all wanted to spend that money on IP attorneys.  In our opinion that is not how you get a new platform to the market.  These decisions could end up biting us.  But at least the IP is not tied up and others can use it.

He got a point. The engineers who get it done have a spidey sense earned with experience. If things look like it's written by marketing what shows up rarely meets expectations.

You've got to be a marketing or PR person. If not, you should be. The responses read like prepared press releases. The kinda things that irritate engineers. I bet if you just posted the technical details he wouldn't have any objections. Hell, there's way too many marketing keywords and phrases for my tastes.

I understand the objection to the Kickstarter video as well. Ever been to the poorer regions of Africa? They don't have any use for robot arms. They'd be happier with security, safe water, reliable food supplies, communications, power, lights, education, and a few other things before robot arms appear on the list. Even then I can say those robot arms will break fairly quickly in those conditions. There are people susceptible to marketing everywhere. There are also people who are irritated by it and will avoid the product just out of spite.

It might also annoy the open source crowd when you use a proprietary, dead language for a key part of how it works.

Daniel, Modzer0, see my post above. Yeah, the guy who wrote this is a marketing person. He is doing the best he can with data from our engineers (I'm one of them). We've been to busy working to post here. And yeah, the FPGA source isn't /really/ open source because the program to open the file isn't available commercially. Answers / reasons in my post and replies to it above. It IS still a really cool project, it's as open source as we can make it, and people who contribute and have FPGA ability are welcome and maybe we can work something out to get you access to the HDL software we use. Read my post and the replies for details.