UpdateHowto can be found on github.
I did not find it on Download Page
I have figured out the protocol Arduino talks to FPGA. In my repo https://github.com/maxosprojects/open-dobot/tree/master/FPGA-SPI-protocol/purec you may find a C sketch that controls dobot by sending commands directly to FPGA board with all existing hardware. This sets up the required pins to enable this. As a precaution, disconnect accelerometers before flashing, for now.
I have also just released initial version of open firmware that you can use to send commands directly to FPGA from your machine via the USB. https://github.com/maxosprojects/open-dobot/releases/tag/0.1 if you don’t feel like compiling it yourself. The source is at https://github.com/maxosprojects/open-dobot/tree/0.1/dobot-firmware/fpga
There is a Python driver in the sources, which is stable. The Python example makes one motor (connected to the middle stepper driver in the blackbox) go back and forth with acceleration/deceleration.
For now it only controls the movements (the three steppers) with some magic numbers that I haven’t figured yet how are they translated to frequency. Let me know if you figure them out. I’ll add few more magic numbers with corresponding frequencies later.
Try to achieve this with original proprietary firmware
There is one major limitation with the way the system was designed because of the way FPGA was programmed - it doesn’t seem to be possible to move the arm precisely at speed. The problem is the following: the FPGA executes commands from Arduino in 20ms cycles (one command every 20ms - 50Hz). If you set the speed for a motor at 50Hz (50 steps/second) then you can tell it to move one step in any cycle - one command setting 50Hz, which with 50Hz command rate makes it move only one step - the precision you’d want. However, when you set the speed at, say, 250Hz - it’s 50 steps per cycle. So if you were planning for the arm to make a curve at speed then you simply can’t change the direction it’s moving before the cycle completes (the last command finishes) and you can issue next command with frequencies adjusted to the changing direction in the curve - it overshoots and diverges from the curve. I guess this also applies to making a straight line at speed given the non-linear end-effector translation to motor speeds. So if you are using the standard firmware then refrain from high speeds when trying to make a straight line.