Delta Kinematics

[iLoveAndyBaker]

Add Delta kinematics, rotary actuators (not linear)

Tinkersprojects has an excellent delta robot library - https://github.com/tinkersprojects/Delta-Kinematics-Library

Moves will need to be broken up into little pieces much like the wall plotter kinematics, because long straight lines will turn into arcs, and programming in the four linkage parameters might be quite a bit of work.

I'm going to attempt this myself, but I'm a much better mechanical engineer than C++ programmer, which is a nice way of saying I'm clueless.

[terjeio]

I can try to port the code but do not have hardware to test/verify it with...

[iLoveAndyBaker]

https://github.com/bdring/Grbl_Esp32/tree/main/Grbl_Esp32/Custom

parallel_delta.cpp - Copyright (c) 2019 Barton Dring @buildlog, Jason Huggins, Tapster Robotics

https://github.com/bdring/Grbl_Esp32/blob/main/Grbl_Esp32/Custom/parallel_delta.cpp

These guys wrote a Delta kinematics for ESP32 GRBL - It's got lots of excellent commenting and error handling. But you still don't have a machine :-( I'd send you mine but we're on opposite sides of the planet almost.

[terjeio]

I have comitted an intitial version for you to test/verify/develop further. Homing is not implemented yet. Enable in config.h.

[iLoveAndyBaker]

This is an excellent start. The kinematics have some problems - There seems to be an accumulating error that causes the motors to all move the base AWAY from end effector, but these readings are not showing up in any DRO. Importantly, this is only happening on X and Y moves. This problem does NOT happen on pure Z moves. It's NOT a small amount either. The easiest explanation is dropped steps or electrical problems, except in my case, my robot is upside down, so it's not gravity, and it's been working great when driven in cartesian kinematics. The error is accumulating in rapid moves, in feed-rate moves, and in arc movements as well, but only when I move the X and Y axis.

Next up, if I understand correctly, Steps per mm are actually steps per radian on the axes. I'm assuming that the other values of acceleration and top speeds are in radian units as well? It seems this way.

End points are funny, but not unexpected in behavior. I can jog the platform away (negative) and past where the math starts to get weird (when the biceps are straight towards the end effector) and then the arms jog all of a sudden move to the zero position. If I keep jogging, nothing happens. Then I reverse the jog to bring the biceps back to level, and when the math starts to work again, it quickly moves back to the position where the biceps are almost pointing towards the end effector. My reasoning here is that when the math returns a geometric error, it returns ZEROs and that's where the robot moves to. Solution? Don't move the robot to zero when the math returns an error.

I think homing will be easy. The delta homes nicely in cartesian mode, just home all three motors at the same time, in the direction that brings the end effector closer to the base.

Amazing that these settings show up ioSender!

I added some descriptions to the settings...

static const setting_descr_t kinematics_settings_descr[] = {
    { Setting_Kinematics0, "Size that moves are broken up into to compensate for the non-linear movement of a delta robot." },
    { Setting_Kinematics1, "Forearm length is the length of the connecting rod in millimeters" },
    { Setting_Kinematics2, "Bicep length is the length of the driven arm in millimeters." },
    { Setting_Kinematics3, "Base radius is the raduis in millimeters from the center of the drive platform to the bicep drive axle" },
    { Setting_Kinematics4, "End effector radius is the distance from the center of the end effector to the connection points of the main connecting rods." }
};

[iLoveAndyBaker]

This is the test robot. The motors have far too much lash, but it's good for testing.

It works OK if I pre-process the delta math and send the motor positions to the robot when it's got the cartesian firmware loaded, so I think there's just some minor math errors.

[terjeio]

Next up, if I understand correctly, Steps per mm are actually steps per radian on the axes.

Steps per revolution (turn). Same as used by marginallyclever. All motors must have the same settings.

I have commited an update with some improvements, among them a new command $DELTA that outputs some of the same calculation results that you get at marginallyclevers page. There is also a new setting and an initial attempt at homing. Does it behave better?

IMO jogging (and motion in general) should not be done until homing has been completed, and should be limited to the parallell cuboid?

I think homing will be easy.

Perhaps, what I have yet to find info on is where homing switches are normally located (at which motor angle) and if they also acts as endstops. A config parameter is needed?

Amazing that these settings show up ioSender!

Settings descriptors are read from the controller - so the ioSender UI will always be in sync. Hopfully other senders will adopt this too - e.g. the WebUI does so already.

I added some descriptions to the settings...

Thanks, I'll add them.

BTW nice looking roobot!

[iLoveAndyBaker]

I will test this code and get back to you with the results, sorry there may be a small delay though. Glad we have that $DELTA command, will be nice to see those values.

[iLoveAndyBaker]

Homing works! Well done.

For my setup, to get it working, I home my rig, then move the arms by hand (by grabbing them and overcoming the stepper motor, which is set to very low current for testing) to the 0 degree angle (away from negative angles) and then the kinematics seem perfect.

There will definitely need to be a parameter to define where the home switch is. I believe in almost every conceivable configuration, it will be in the "negative" angle space as I've sketched here. So there will need to be a parameter for those I think, and I imagine that they'll all be the same angle for all three axes. On my robot, it would home to -30 degrees or negative (pi/6) radians.

Can you explain to me what the parameter "Base to floor' means?

Now here is something with the kinematics, where the arms to to the full vertical position. It results in a mathematical error and the arm positions go to zero, then when we jog back into the envelope, it returns to the near vertical position.

I believe in this way, we can understand that, mathematically, the maximum positive angle will be +90 degrees. It's the maximum negative angle that we'd need to define, which is where home switches live (sorry I'm saying this again I realize)

https://www.youtube.com/watch?v=n_b2L3eEVtE

Also, this accumulating error that I was talking about has completely disappeared , but this may have been due to the control board I was using, which had some catastrophic electrical issues. I'm now running straight off an RP2040 board. Either way, it's gone and everything is great.

This is brilliant work. Shall we do a Stewart platform when this is finished up? :-)

grblhal is excellent. Thank you.

[terjeio]

Can you explain to me what the parameter "Base to floor' means?

It is defined here, not needed for grblHAL since Z max travel can be used?

Now here is something with the kinematics, where the arms to to the full vertical position. It results in a mathematical error and the arm positions go to zero, then when we jog back into the envelope, it returns to the near vertical position.

Perhaps the attached version is better. It may require a soft reset if motion hangs. Will look into that.

Some issues to address:

• Soft limits cannot currently be enabled, needs modifications to the core.

• Home position is also max travel limits? Should it be possible to have the home position at the top of the cuboid envelope? This would require separate homing and limit switches, such homing switches would have to allow motion past them. FYI the core supports separate homing and limit inputs - but there is no driver support yet for homing inputs.

• Selectable work envelope? Either all reachable space or just the cuboid envelope. The former requires core changes.

• If motion is to be limited to the cuboid envelope should homing finish by move to the top of it?

• Other issues?

Shall we do a Stewart platform when this is finished up?

6 axes?

---

Replace kinematics/delta.c with this for the latest changes:

delta.zip

[iLoveAndyBaker]

The homing is working brilliantly, as is the homing position parameter. I set mine to -30 degrees and it's working great!

Motion does not appear to hang, and behaves well when I jog the arms past 90 degrees, which is to say, it doesn't fly back to zero. It just doesn't move. Then I can jog back to an acceptable position and it will pick up where it left off.

This is how I did my home switches, in a close-up view.

The one last thing that I see is that I can jog the motors into the home switches (which I have set as hard limits in my case) so perhaps setting a soft-sort of limit to not jog past that point would be good, but it could theoretically conflict with people that have both home AND limit switches in place.

Maybe a compromise might be to add yet more parameters - A motor minimum and maximum angle. This would not protect against joint over-deflection, however, as described below.

Here are my thoughts on the work envelope: It would be a shame to restrict the movement to cuboid, since the delta work envelope is big and weird shaped, but very useful. It ends up looking like this I guess:

and it stands to reason that a big limiting factor to the workspace is also the amount of allowable joint deflection.

If there were going to me modifications to the core to soft-limit to the usable work envelope, I can see this as being a needed parameter. Once you account for that maximum joint deflection parameter, your work area turns into a hexagon sort of shape like this one.

This is where I'm reading this info. https://www.researchgate.net/publication/346550821_Workspace_Analysis_and_Mounting_Height_for_3DOF_Delta_Robot

I have also noticed an unsurprising relationship between planner buffer blocks and segment length - When segment lengths are small, the planner buffer blocks needs to be set high for machine speed to remain high, otherwise the machine speed is limited by the axis acceleration. I believe the default is 23 blocks (this may be left over from the old ATMEGA328 days) but with it set to 200 or even 1000 it works well without any strange side effects on the RP2040 - Maybe this can be a note in the segment length setting description box?

You've done some fantastic work here. I think we can expect to see many more delta robots popping up in the maker community soon.

And yes, by a Stewart platform, I do mean a 6-axis, like this: but with steppers of course. The work envelope calculations for that would be a real joy. But imagine what people could do with 3D printing!

[terjeio]

I have committed a new version along with some supporting core changes.

The functions for handling soft limits and jog constraint can now be overridden and I have added tentative versions for both. Soft limits may work already but constraining jog motions will not unless it is to the cuboid. A new setting, $647, has flags for where the home position is and if movements should be limited to the cuboid.

Soft limits check will be costly for arcs if not limited to the cuboid, this since it will be performed for each segment of the arc. To minimize this the arc bounding box should be calculated and checked against the allowable work envelope prior to segmenting. I have code in ioSender for bounding box calculation that could be used but not sure how effective this is. Constraining jog movements to the allowable work envelope may also be computationally expensive, iterating towards the limit is one way to handle it but perhaps there is a more direct way to do it? Are there any math experts out there keen to solve this?

I believe the default is 23 blocks (this may be left over from the old ATMEGA328 days) but with it set to 200 or even 1000 it works well without any strange side effects on the RP2040 - Maybe this can be a note in the segment length setting description box?

The default number of planner blocks is 35, and yes this affects max speed when many small moves are commanded. Adding more text in the description(s) can be done. In fact I would like a native english speaker, preferably a machinist, to review both setting labels and descriptions. I am neither...

[terjeio]

Another version is up, with a new setting for maximum angle++ With luck jogging should now be limited to the complete work envelope - this is hard to verify for me since I do not have access to a machine.

[iLoveAndyBaker]

And again you deliver amazing work - So here's what I found... It's very close.

• Soft limits do not work unless (40) limit jog commands = true

• Angle limit appears to be working on the joints, however, they limit the maximum Z travel by limiting the motor arm angle to the parameter 648 value, but like so:

Consider a homing angle of -30 Setting a Max angle of 1 gives the following range of motition on the motor angle:

• 1 degree max angle = -30 to +1 range
• 45 degree max angle = -30 to +45 range And for fun: A negative angle.
• 10 degree max angle = -30 to -10 range. Joints appear to respect the 10 degree limit.

This may be an interpretation of a joint's degrees of freedom, since in a ball joint, it's free to infinitely rotate along the axis of the mounting hole, but not to pivot more than a certain number of degrees from that axis.

Parameters 130, 131 and 132, axis max travel, seem to have no effect. (Not a problem?)

I'm very glad that I can turn off hard-limits, because soft-limits do appear to be working towards the home switches.

It could also be quite helpful if there was a command that would report the current motor angles, perhaps in $DELTA even?

[terjeio]

Soft limits do not work unless (40) limit jog commands = true

This is a core issue, will fix. BTW enabling limit jog commands will not help for checks for regular motion, only jog commands. Limit jog commands should always be enabled when using ioSender - due to its use of continuous jogging (by sending long moves).

Angle limit appears to be working on the joints,...

Can you add and verify the needed math to delta_calcAngleYZ() to check for limits imposed by the joints?

Parameters 130, 131 and 132, axis max travel, seem to have no effect. (Not a problem?

I'll limit the cuboid envelope to these settings if less that the calculated cuboid in the next commit.

It could also be quite helpful if there was a command that would report the current motor angles, perhaps in $DELTA even?

I'll add them to the $DELTA command. I may also add an option to add them to the real-time report as well.

There is an issue with the delta_calcAngleYZ() function, seems it should have a range check in input parameters since trig math keeps repeating the result depending on the quadrant...

[terjeio]

New updates has been committed, getting closer?

[terjeio]

Closed due to lack of feedback.