UR10 Should MoveP be used instead of MoveL?

[UnfoldAntwerp]

Hi all, first of all thanks for the fantastic components. Has made working with the UR10 a real joy. I had a question in regards to the type of moves that are generated. I am debugging some non-planar printing definitions and noticed that the speed of movement at TCP is not constant during the largest vertical axis changes. I have a few theories why that may be, angle speed limits, TCP that should be configured within the extruded bead instead of tip of the nozzle. But then I noticed that the generated programs use MoveL which as far as I can read, doesn't provide continuous speed. MoveP should be used for that?
from this article:
"MoveP will move the tool in linear motion at constant speed with circular blends, and is intended for process operations, like sealing or dispensing."
Any thoughts on this?

[KonradJuenger]

yes moveP would be the right motion type in my mind. Unfortunately robots doesn't support it but I think it would be possible to either modify the text output of the code generator inside gh or fork&modify the robots plugin.

[UnfoldAntwerp]

Thanks @KonradJuenger I’ll first try just editing the text before forking and see if that makes a difference. First going to solve extruder control before heading back to debugging non-planar code.

Ps. Came across your work last year on Instagram, really nice. We made a film with a Franka arm but that was just using the teaching mode. Never been able to do something more than simple joint or Cartesian motion with manual waypoints and the occasional build in lissajous. What method did you use for more elaborate tool paths? Did you connect it to Grasshopper too?

[KonradJuenger]

thanks, check out my fork of robots here: https://github.com/KonradJuenger/Robots/releases/tag/0.1.2
you should be able to choose "constantSpeed" as a motion type, I had this ready but only now the time to upload it to github

As I am not a proper developer, this might have some bugs, for example simulation is unaffected by the change and will simulate moveL instead

As for the panda: it was a real pain in the xx, I did write some c++ code which connected the panda to grasshopper via websockets , buffered and streamed new positions in a 1khz control loop. The problem was that this loop had to be real time (realtime Linux + server grade NIC) and that you'll have to make sure that all targets are reachable within the acc/jerk limit and within one millisecond.
I've also tried ROS with python, It was equally horrible.

[UnfoldAntwerp]

@visose you closed this issue but I'm curious if the use of MoveL is as intended or should it be changed to MoveP?

[visose]

Hi @UnfoldAntwerp, you can use @KonradJuenger's fork if you prefer to use MoveP over MoveL.

Which one to use will depend on your requirements. MoveP seems useful if you prefer constant speed at the expense of the speed being lower and not match as closely to the programmed speed.

When we developed UR support we had only access to first generation UR10s which predate the MoveP instruction. At least I don't remember seeing it in the docs then.

[visose]

For example, you might still prefer MoveL if:

• You are cutting something, as you might want sharper corners in the path and don't mind the slow down when turning the corner, then speed up on other places to finish the cut quicker.

• You are extruding something, and the extruder motor is coupled to the robot controller in such way that the flow can be synched to the speed of the robot, so you can have consistent flow on speed changes (to some degree). This is specially useful in extrusion since its such a sloow process.

You might prefer MoveP if:

• You are extruding something, but the extruder is not coupled to the robot and is constantly extruding material at the same rate, no mater the robot speed. For extrusion I would try to avoid this, as robot speed ends up changing. To not change at all, it has to limit itself to the worst case scenario of the whole path, like the sharpest corner, where everywhere else it could go faster, but its not doing it, just because of that one corner.

[UnfoldAntwerp]

@visose Thanks, once I get back to the machine next month I'll try the fork to see if it solves my non-planar speed issues.

[cxlso]

Hi, I know it's a long time ago but how did you solve it in the end. I'm running into a similar problem. Thank you.

[cxlso]

Hi @KonradJuenger and @visose I made a script for non planar printing however this involves a lot of different joint movements. So, even though my extrusion rate is constant, the actual translation speed of the TCP is decreasing too much on sharp non planar curvature.
I tried to install your fork but it seems like I have to uninstall the original version to use the forked one. This is not ideal.

Is there a way we could implement MoveP with a script component?
I was also thinking about modifying the program itself and replacing the text "MoveL" by "MoveP".