Dobot with inverse kinematics ramps 1.4

Other Hardware Robotics
1

I have at last succeeded in putting together a sketch that will allow a Dobot version 1 with ramps 1.4 to do inverse kinematics. My dobot is a recently made clone, available on ebay for around $400 (no electronics), that uses homing switches instead of gyros. Its well made, and functions great. So far, you can input the x,y and z location and it will move to that location. It homes at start up, and zeros the coordinates, makes the moves in coordination using accelstepper multistepper and reports ok when the move is finished.

I can't take credit for the IK math, as I have built upon the work of a developer in Indonesia who worked out the math for a similar arm.

I have also modified the INO file associated with the brilliantly written AR2 software, so that it functions with a dobot. The inverse kinematics do not function though, as the arm is configured for 6 axis on the Ar2. It is however great software for scripting movements, responses, servos, etc.

I'd like to be able to have the program communicate with a code sender designed for GRBL or MARLIN, so that it can respond to a file of g code locations. As well, I would like to have the program accept inputs for circular motions, such as G02 or G03 what specify a staring point and radius. Any assistance with the software would be appreciated. Here is what I have so far.

Dobot_IK_Accel_Multi_Home.ino (13 KB)

AR2.1_edited_for_ramps_1.4.ino (44 KB)

2

I now have the software accepting G0, rapid move commands, G1 straight line commands using Bresenhems line algorithm, and G2/G3 circular command.

The method of input of commands is using the serial monitor, in the format of <gcode,X,Y,Z,I,J> with I and J being the coordinates of the radius of any circular command.

Eventually I want to either adapt my code to be able to communicate with a standard program like Universal G Code Sender or any of the many PC interfaces for marlin or grbl.

Revised code to eliminate some bugs. See second version.

Dobot_IK_Accel_Multi_Home4.1.ino (20.8 KB)

Dobot_IK_Accel_Multi_Home4.1.ino (21 KB)

3

I wrote a python program that reads a text file that contains the Gcode written on separate lines.
The gcode is still in the format of <G0,15,0,5> being x,y and z
or <G1,15,0,15> for straight line movements. For circular movements it is
<G2,25,0,15,5,0> for instance, for X,Y,Z and I and J (which are the offsets from the starting X,Y coordinates).
The program counts the lines, serves them up one at a time, waiting for a reply that the movement has finished. To use this program, you need to us my latest version of the Arduino code below.

Dobot_IK_Accel_Multi_Home4.2.ino (21.9 KB)

mygcode.txt (374 Bytes)

mygcodesender.txt (2.61 KB)

1 Like
4

@Northof49 - I have noted with interest your post. I cannot assist you, but am looking for suggestions on how to get familiar with robotics, grbl, IK, etc. that you refer to in your posts. Any link to study material is appreciated?

5

It seems to me that robotic arms are somewhat distinct from typical robotics. While a really advanced robotic arm project will involve more than simply carrying out a set of instructions, such as reacting to a changing outside world, such as finding and organizing randomly placed objects or avoiding newly introduced obstacles and problem solving, its challenge enough to simply get a multi-jointed robot arm to simply move to a desired set of 3D coordinates. Robot Operating System is one such programming structure that addresses advanced issues like mapping the outside world, predicting collisions and simulations. Its very complicated to even get started on, but if you are interested I would suggest reading up on Robot Operating System (ROS) http://www.ros.org/. I am still trying to work my way through the tutorials.

There are a number of software packages designed for controller stepper motor driven cnc instructed 3D printers and other machines likes mills, engravers, etc such as Marlin and Grbl. List of Firmware - RepRap They are great systems that can run on Arduino, but have the limitation of only being able to properly control machines that move about using cartesian movement, ie, all movements are based on axis that move strictly at right angles to each other. That suits 3d printers, mills, engravers, etc, and will allow movement of multi jointed robot arms, but not to move them to cartesian coordinates in 3D space as the arms typically don't move in only one dimension.

So that takes us to the subject of inverse kinematics, the calculation of the angles of various joints that in combination result in the movement of the end effector to cartesian coordinates (x,y,z). There is more than one way to calculate them, but the Denavit-Hartenberg parameters seems to be one of the more accepted methods of calculating what angles the various joints of an arm need to be at to have it be in a particular location. Denavit–Hartenberg parameters - Wikipedia

If you are interested in a great explanation of how these parameters would be used to calculate the movement of a 6 axis arm, Chris Annin has a series of excellent videos explaining how he did it for his AR2 robot arm.

Start here: 6 axis robot kinematics Part 1 - YouTube

6

Thanks @Nothof49 for the various links. I will go through them. Really appreciate the pointers.

7

I started with ROS and Chris’ Youtube videos and they are excellent resources. Thanks @Northof49

8

Hi Northof49, I think your work is very good. Clear, simple, efficient. Do you have any video of the arm moving? What about the precision and the repeteability using the accelstepper library? how did you calibrate the arm?

9

Thanks for the compliment. My programming skills are pretty rough, and I'm sure my work would be abomination to someone who knows what they are doing. About the best I can describe what I've done is to successfully stitch together all sorts of different example for getting various jobs done, like Robin's serial communication and parsing, an example of homing with switches I found somewhere, Bresenhem's line algorithm, etc.

I've thought about making a video, but don't have any skills in video editing, so it would be rather amateurish and unedited.

About the best test of precision I've put it through is drawing. It traces the same 10 cm diameter circle with a fine pen multiple times with only the slightest enlargement of the tracing line, possibly due to not having devised a proper pen holder yet. So, repeatability is less than 1 mm, I'm just not prepared to say how much less than 1 mm. The circle however isn't perfectly round. It has a clear elongation in the Y dimension. I was working on scaling the y dimension to correct that, but had to give it up temporarily while I chased down another problem. Every time I create a new variable its easy to lose track of how many places that data is needed somewhere else like the beginning or the end of a line or circle command.

As for calibration, I was experiencing a slight change in the Z depth as the arm extended outward from the base. That was when I used all accurately measured angles at the various joints. So I started experimenting with making slight changes to the perceived initial angle of Joint #2. IE, what if when it measured 90 degrees, the software thought it was actually at 93 degrees. Not actually changing what angle it begins at upon homing, but what angle the program thinks it is starting at. I found that by adding or subtracting degrees from that starting number, it flattened out or increased the movement in the Z dimension so that Z stayed stable as the arm moved outward from the base. I have no idea whether that is the correct way to deal with that issue, but by experimentation it seems to work.

If I can figure out the scaling part, I can set X Y and Z to exactly match the input distances. As mentioned above, X is near perfect, Y seems to move further than it should, producing oval circles.

As well, I have discovered that I need to change the math so that it accepts inputs in mm instead of cm. I need to do that because Inkscape, which I plan to use to generate G code for drawing, outputs in mm.

10

thanks for the explanations, very interesting.

11

Hello,

Thank you very much for your works.

Robotic Arm with Inverse Kinematics with Marlin Firmware :

Inverse Kinematics is included in marlin_main.

Best Regards.