Keep constant TCP speed when TCP orientation changes (nonplanar toolpath)

[cxlso]

Hi everyone,

I’m using a Universal Robot for 3D printing, and I’ve noticed that the TCP speed drops a lot whenever the robot needs to change its orientation along a non-planar toolpath. On corners or areas with quick orientation changes, the TCP almost stops moving.

When printing, this ends up depositing way too much material in those spots and messes up the print quality.

Any idea why this happens or how to fix it?

Thanks

[LoyWeiWin]

Hi cxlso!

Do you have a picture or video to describe the issue? Perhaps locking / configure the robot configuration would help, assuming the robot have to transition from one pose to another config. As a result, it slowed down. Or maybe you have assigned too much target at those corners? It is quite hard to guage your issue with an understanding how the script is written.

Alternatively, you can look into RTDE to control the extrusion speed when the robot is about to reach the corner? Assuming the extrusion is controlled through the control box / arduino.

Hope this helps.

[cxlso]

Hi Wei, nice to hear from you!

Here’s a video: https://drive.google.com/file/d/1zWJsz9ELhGjgp-KPQ4bCCEMO0WGolZA5/view?usp=sharing
I hope you can spot the issue. Basically, whenever the waypoint planes rotate to follow the curvature of the toolpath, the movement slows down compared to when the waypoints all have the same plane orientation. In the video, you can see that where the TCP takes longer to move because of the orientation change, the extruder deposits more material.

This video is actually from an older project, but I’m about to start a new one where I’ll print on organic surfaces with lots of valleys and hills, so I want to fix this problem.

I could address it by measuring the plane rotation and adjusting the robot or extrusion speed proportionally, but I’m hoping it can be fixed directly by changing some settings—either in the robot configuration or in the plugin settings.

I suspect it might be related to some of the variables in the "Create Speed" component, but I remember adjusting them and not seeing much change.

Any help would be much appreciated 🙏

[LoyWeiWin]

Hi cxlso. Thanks so much for the explanation — that makes a lot of sense. Given that your target planes are non-planar, I’d suggest increasing the orientation speed to around 3–5 rad/s. This should let the UR’s wrist 3 rotate a bit faster, since in the video it looks like the arm slows down whenever that wrist has to make a larger reorientation. Hopefully this would resolve your issue.

[visose]

@cxlso if you search this forum you will likely find this issue discussed in multiple posts. This is one of the most common issues people face when attempting to extrude material with an industrial robot. Most robust solution is to link the extruder motor with the robot controller (as an external axis or via a separate controller) so that the dynamics of all motors are synched and extruded distance matches TCP travel distance.

[cxlso]

@LoyWeiWin @visose Thank you both for your replies.

The extruder motor is already synced with the program. I control the extrusion rate with the analog signal. I'm already varying the speed to mitigate squishing of the layers, but that's a good point I can try to sync the extrusion rate to some of the change in joint rotation.

I also tried playing around with the different variables of the component Create Speed. But I couldn't see much difference.

However, using Joint Targets instead of Linear is actually fixing my problem.
Using Joint motion, the TCP speed stays constant. 👍

[visose]

Joint motions won't move the TCP at a constant speed in world space, only the joints rotate at a constant speed.
The reason the TCP slows down when reorienting the tool is that one of the joints cannot accelerate fast enough to keep the TCP moving at the programmed speed (or a joint has reached its maximum speed). You can check if the accel value is not set at maximum, but likely it's reaching a physical limit.