UR10 Should MoveP be used instead of MoveL?

UnfoldAntwerp commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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.

visose / Robots

UR10 Should MoveP be used instead of MoveL? #64