search

HALRobotics / Beta

HAL Robotics Framework beta release and associated documentation.
17 stars 3 forks source link

Maintain speed for drawing curves #109

Closed AdwinK closed 1 year ago

AdwinK commented 3 years ago

Hi

I am using a UR3 arm as a drawing bot with a custom pen tool head.

With the need of high precision, the speed is adjusted to extremely slow (5mm/s) and blending limited in 1mm radius.

I am facing 2 problems:

1.

I noticed the speed settings and acceleration settings doesn't maintain the robot in the same angular speed. i.e., for the same speed input, a shorter path is drawn faster than a longer path. (even if I input using the orientation limit)

https://user-images.githubusercontent.com/86712439/124733387-ba39ff80-df46-11eb-9b97-9198629588c6.mp4

For that I had to input various speed settings for every target (see below attached script), in order to prevent errors like "Protective Stop C153A5: Protective Stop: Position deviates from path: Wrist 3" when I want the TCP to follow the curve's direction but when the curve tangent changes dramatically. (i.e. extreme in curves)

I wonder if I am inputting in a wrong way or is there a way to prevent it. I couldn't use MoveJ as the movement of the TCP will stutter a lot which creates unwanted pen strokes.

2.

With extreme slow speed (5mm/s) drawing, in certain extreme turns the robot performs the error "Runtime error: MoveP cannot maintain speed when reversing direction. Adjust waypoint to make robot able to blend."

HAL error

the following is a simplified GHX to recreate the error.

HAL maintain speed test.zip

HAL Version

The current HAL framework I am using is

EXTENSIONS

I had a problem to load the newest HAL framework and therefore stayed in ver. 1.3.26

Looking forward to your idea and reply.

Thank you.

sebandraos commented 3 years ago

Hi @AdwinK ,

  1. Unfortunately there is no orientation speed constraint in the UR language (URScript): image image N.B. v is in m/s and there is no angular component. We can't do a great deal to correct that. Parametrically generating the speed based on the curvature of your input curve, as I understand you're doing, sounds like the best compromise. We are looking into allowing users to choose to export our solved speeds rather than programmed speeds but I don't think that would necessarily help here because the orientation speed constraint still wouldn't be exported to the UR.
  2. This is again a hardware limitation. URScript's movep maintains linear speed and is exactly designed for this kind of application but when you reverse direction or make a very tight turn you inevitably go through a slower speed which movep doesn't like. Depending on the tightness of the turn you may find that increasing the blend radius helps the situation by allowing the robot to retain more speed. In v1.4 (due for release before the end of the summer) we have done two things to improve this:
    1. Added the option to switch between movep and movel where movel doesn't have the same hard speed constraints.
    2. We will automatically adjust the blend radius to try and fix the error.
  3. What issues are you having installing the latest version of HAL.UniversalRobots? We are always keen to hear about issues so we can try and fix them.
AdwinK commented 3 years ago

Thank you @sebandraos

I see there's a certain limitation on URscript and I am looking forward to the MoveL function in the upcoming update in v1.4.

Regarding on the installation of the latest version of HAL.UniversalRobots, I have the issue that grasshopper is not loading in the HAL gha, I believe it's related to issue similar to #22 & #69. I have tried with enabling COFF loading in GrasshopperDeveloperSettings, removing all other plugins and reinstalling but fail to fix it.

I at the end had to copy the HAL framework from another computer which haven't update to successfully load the component.