Skip to content

Scaled jtc #1191

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 67 commits into
base: master
Choose a base branch
from
Open

Scaled jtc #1191

wants to merge 67 commits into from

Conversation

fmauch
Copy link
Contributor

@fmauch fmauch commented Jul 3, 2024

This is my take2 on #301.

I plan to finish this until Friday, @firesurfer feel free to poke me :-)

Currently missing

  • tests for scaled execution
  • There are some ToDos in the documentation:
    • Algorithmics
    • Handling tolerances

Things that will get changed, as discussed in the latest working group meeting

  • Allowing scaling factors above 1 might get postponed to a later point.
  • Report the scaling factor in the controller state
  • Use a custom datatype for the scaling_factor subscriber (std_msgs are deprecated)
  • Change subscription to transient_local. This will require documentation, as a standard ros2 topic pub will not work with this.

fmauch and others added 13 commits July 3, 2024 17:38
This adds a scaling factor between 0 and 1 to the JTC so that the trajectory
time inside the controller is extended respectively. A value of 0.5 means
that trajectory execution will take twice as long as the trajectory states.

The scaling factor itself is read from the hardware for now.
This avoids writing the explicit conversion by hand

Internally that basically does:
static_cast<rcl_duration_value_t>(static_cast<long double>(rcl_duration_.nanoseconds) * scale_ld)
That was changed in a previous commit
used

The current implementation only works correctly when a position
interface is used.

When the hardware in fact slows down the robot (as UR does), also velocity interfaces
should be scaled correctly, but that't rather an edge case right now.
It is accessed from the RT thread only, anyway.
@fmauch
Copy link
Contributor Author

fmauch commented Jul 3, 2024

Thoughts on tests I should implement:

  • Execution with scaling factor of 0.5 takes twice as long (and does not fail, when no tolerances are set)
  • Execution with scaling < 1 and goal time tolerance leads to an early halt and failed execution
  • Execution with scaling < 1 and path tolerances set should not fail (if goal_time_tolerance is large enough)
  • Execution with scaling > 1 should not fail independent of the tolerances set <-- is that true?

@firesurfer
Copy link
Contributor

hi @fmauch Great to see this being worked on again. I added some comments to the code.

Regarding the tests:

Execution with scaling factor of 0.5 takes twice as long (and does not fail, when no tolerances are set)

Makes sense

Execution with scaling < 1 and goal time tolerance leads to an early halt and failed execution

Isn't this what we patched in: UniversalRobots/Universal_Robots_ROS2_Driver#882. As far as I can tell you also backported this patch. (And I still think the goal time should be also scaled ;) )

Execution with scaling > 1 should not fail independent of the tolerances set <-- is that true?

Same as above. From heavily using this controller in our system I have the opinion that in most use cases it makes sense (and is what a user would expect) that the goal time should also be scaled. But perhaps I understood your suggestion wrong.

@fmauch
Copy link
Contributor Author

fmauch commented Jul 4, 2024

From heavily using this controller in our system I have the opinion that in most use cases it makes sense (and is what a user would expect) that the goal time should also be scaled. But perhaps I understood your suggestion wrong.

Thank you for your input. That's why I put my brain dump on that here, so we can discuss this :-) And that's also why I didn't write the documentation on that, yet.

I'll wrap my head around this a little more and try to get a better feeling for the current behavior, then come back to this.

@firesurfer firesurfer mentioned this pull request Jul 4, 2024
fmauch and others added 16 commits December 4, 2024 21:32
Co-authored-by: Christoph Fröhlich <[email protected]>
Also run two trajectories
We calculate the state error at the beginning of the control cycle
based on the estimated progress in the trajectory (respecting scaling)
compared to the current joint state.

When we are approaching the final point, that state error might be 0,
though we haven't reached our goal, yet. In this case the trajectory
would succeed and falsely report success in the case of a strict goal
tolerance.

This change checks the current state against the command once
interpolation reached the last point in the trajectory. This allows the
robot to arrive at the final point as long as it is doing so within the
configured goal time limit.
when scaled

For this, the trajectory is manually sampled at the expected time points
and this is compared to what the controller generates.
# Conflicts:
#	joint_trajectory_controller/src/joint_trajectory_controller.cpp
@firesurfer
Copy link
Contributor

@fmauch whats the current state of the scaled jtc efforts?

@fmauch
Copy link
Contributor Author

fmauch commented Apr 30, 2025

@RobertWilbrandt would you mind taking a review on this, as well, since you use it yourself AFAIK.

Copy link
Contributor

@christophfroehlich christophfroehlich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding more tests, my points of the first review were fixed! @firesurfer @RobertWilbrandt do you have time for another review round soonish?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants