Hexapod kinematics

dc42

it is my understanding the internal kinematics code does not support rotational axis.

so this would be a major rewrite.

The kinematics does support rotational axes. SCARA and polar kinematics use them already.

Veti

i stand corrected

dc42

You are not often wrong!

oliof

Adding new kinematics is relatively easy, even I managed to do it (-; If you have the kinematics and inverse kinematics at hand it's pretty straightforward.

(the reason I haven't submitted my implementation for inclusion is because I lack the faculty to add a proper check for illegal moves currently, and because to my knowledge only two machines of the colinear tripteron kind exist, both of which have severe backlash issues ... so before I return to the software, I need to improve the hardware).

Garth_42

@oliof

Glad to hear that it’s easy I have looked at how to add kinematics and I am really only a little past being a beginner in Python. I will see what I can do. I am planning a ball screw driven machine so it isn’t using rotational axes for motion.

oliof

Here is how you can approach it:

Check out and build the software unmodified.
Read the kinematics source code.
Read about adding kinematics.
If you still want to do it, reserve a kinematics ID as outlined in the document above.
Start implementing. It might be worth to have read, and written some C++ before you do so. Python basics only get you a short way of the path.

Garth_42

@oliof thanks for the info. I am starting to try to compile the source and looking at resources for brushing up on C++.

In the meantime, I am thinking about making a gcode translator for XYZ input and outputs to the position of each of the 6 linear leg axes. Do you think that this would work? Or is there something I am not thinking about that would make this approach not feasible.

Garth_42

The idea being that I would take standard Cartesian gcode input and then translate that into a gcode that moves each of the linear axes to the position needed for the specified Cartesian points, leaving extrusion unmodified and upload that to the machine

oliof

That could work but isn't really less effort? I know that the MPSCARA originally came with a post processor like that, but then only worked with the output of a specific slicer with specific settings and with a specific version of Marlin.

PS: Did you see https://youtu.be/T_347m_lxes ?

JoergS5

@Garth_42 said in Hexapod kinematics:

The idea being that I would take standard Cartesian gcode input and then translate that into a gcode that moves each of the linear axes to the position needed for the specified Cartesian points, leaving extrusion unmodified and upload that to the machine

Linear axes are called linear because they have only one direction of movement. But the movement itself needs not to be linear (I mean the speed changes). Hexapod are 6 actuator movements, with movement speeds not linear. If you translate cartesian coorinates into hexpod axes and then back into cartesian, the hexapod movement speed do not reflect how they should be.

The firmware segments movements into smaller linear straight movements. The segmentation of long linear paths (G0/G1) and curved paths (G2/G3) into short straight moves is not exact, but with enough segments exact enough.*) If the calculation is done inside firmware, the segment start and end points are correct for every axis. If you give the firmware only the 6 axis coordinates, it can only segment linearly the complete path of every axis, and they don't fit to each other.

*) the firmware even allows to configurate the segmentation length through configuration parameters (S and T parameters), if you program it into the kinematics.

It's better to create kinematics/inverse kinematics rules to let the firmware calculate the translation and let the firmware calculate the move path and axes step commands, including segmentation, speed and acceleration limits, mesh calibration support, endstop support, M208 limits and more.

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.