Hexapod kinematics

JoergS5

@Garth_42 if you need help, I'll try to help you. I've set an alert to this thread.
Easiest to learn is to look into the existing kinematics files (in the src/Movement/Kinematics folder) and understand the logic.
The important methods/functions to start with is

MotorStepsToCartesian() for (forward) kinematics
CartesianToMotorSteps() for inverse kinematics

Garth_42

@oliof the g-code translator idea would be more in my wheelhouse as I wouldn't need to code in C++ and research a pre-existing codebase is all. Thanks for the link, I haven't seen that one... cool machine, and I didn't know that about the MPSCARA.

@JoergS5 thanks for the technical information, noted, very interesting.
Also, I appreciate the offer thanks much. I will respond to this thread with updates. I am starting to look at the kinematics files and it isn't as scary as it initially looked.

Garth_42

Hi @JoergS5 I have a quick question about the MotorStepsToCartesian and CartesianToMotorSteps functions that I was hoping you could clear up. I have been looking over the kinematics.h file for a little bit and I am having trouble figuring out the "motorPos" input variable. The file states that motorPos is measured in steps from the reference position. Does this mean that it is measured in motor steps from the origin of the printer's coordinate system?

JoergS5

@Garth_42 the motorStep position is set when Duet powers up.

When powering up, the Duet doesn't know the stepper positions. Homing and triggering an endstop, and telling in the config.g file where the endstop is (often by M208 and setting with G1 H1) , the firmware can calculate and set the motorPos.

The M208 are cartesian coordinate numbers, so for linear kinematics like Cartesian printer you're right, motorPos refers to the printer's coordinated system. You can however define machinePos as angle positions also of as actuator for nonlinear axes. In this case there is no linear correlation between stepper angle and cartesian coordinate. Hexapad have rotational positions, the 6 actuators create a cartesian coordinate, and the formula is not linear.

Example: one actuator of the hexapod triggers it's endstop, the firmware config says the endstop is at 10 degree, then firmware calculates current motorPos as 10 * stepsPerMm (which is in fact stepsPerDegree in case of rotational actuators), rounded motorPos to int.

StepsPerDegree are calculated by steps_per_rotation * microsteps / 360 * gear_ratio. E.g. 200 * 16 / 360 * 1 = 8.8888 without gear, and for 1:3 gear 26.6666

M208 XYZ values are cartesian values, it cannot be used to set angle values for the hexapod angles. I solved it for the robot by using a separate parameter for the endstop positions, please see my thread and wiki documentation (A parameter 1es, 2es etc.).

Garth_42

@JoergS5 thank you for the detailed and knowledgeable response. Your answer has further helped me understand the code base.

BTW I am designing a linear hexapod though so it seems like my complexity is reduced somewhat.

JoergS5

@Garth_42 I am curious what you mean by linear hexapod, do you have a commercial role model or another explanation/image/...?

Garth_42

@JoergS5 I am planning on using a leadscrew for each of the legs of the hexapod in a setup very similar to this: https://youtu.be/G_UmhUjZhNo

JoergS5

@Garth_42 I understand. Looks like https://forum.duet3d.com/topic/11876/6-axis-delta-3d-printer/9 and probably you can develop the kinematics together.
The kinematics will be nonlinear, using nonlinear functions (it is called six axis Delta there, but I think hexapod or stewart platform would be the better name: https://en.wikipedia.org/wiki/Stewart_platform ).

To explain it better: with linear/non linear I didn't mean how the actuator or attached linear guide move, like ball screw in your video. I mean the correlation of the actuators with the resulting cartesian coordinates. They are complex with hexapod.

I also thought about using it, but for the print bed. It would be a nice idea to tilt the bed, so overhangs can be printed without support material. This requires changes to the slicer also, because the layers need to be shifted according to the bed tilting.

Garth_42

@JoergS5 ah I see, thanks for clarifying that. I have implemented inverse kinematics in python but I am having more trouble coming up with the forward kinematics. After that I am planning on converting it to C++ and adding it to the repo. Thanks for linking that post, it has a lot of useful info!

dc42

I can see that the forward kinematics will be challenging! Six nonlinear equations to solve. The forward kinematics is needed by RRF only occasionally, so it doesn't need to be fast. An iterative solution may be appropriate.

PS a search for "Stewart platform forward kinematics" produces several promising results.

JoergS5

@Garth_42
https://github.com/LinuxCNC/linuxcnc/blob/2.7/src/emc/kinematics/genhexkins.c solves forward iterative, analyzing the code could give you some hints.

But you can learn a lot by drawing the kinematics and thinking about how to solve the equations yourself. You can try to solve with trigonometric functions (sin, cos, tan) or by geometric functions (thales, circle intersection) or both, they are connected.

It also helps to read scientific articles, which explain formulae in their introduction sections, before they discuss improvements to a specific topic. Some offer free pdfs.

Garth_42

Thanks both for your suggestions! I am slowly making progress. That repo is actually what I am using to develop a solution and am getting close. I am a little confused as to some of the matrix operations but I should be able to replicate it nonetheless.