Skip to content

Conversation

@fmauch
Copy link
Contributor

@fmauch fmauch commented Sep 19, 2024

This uses the PoseBroadcaster currently written by @RobertWilbrandt. As he wants to contribute that to ros2_controllers, this will stay in a draft state until it is merged upstream.

@gavanderhoorn
Copy link
Contributor

High-level question: would it perhaps be better to have the hardware interface offer a quaternion instead of an Euler angle triplet?

That would seem cleaner to me, in the sense of it being more of an N-to-1 mathematical abstraction.

While they aren't necessarily very human friendly, quaternions have definite benefits mathematically, and making it the responsibility of the hardware interface/driver to convert whatever internal orientation representation it uses to this 'intermediary representation' would seem to make sense.

@fmauch
Copy link
Contributor Author

fmauch commented Sep 26, 2024

High-level question: would it perhaps be better to have the hardware interface offer a quaternion instead of an Euler angle triplet?

That would seem cleaner to me, in the sense of it being more of an N-to-1 mathematical abstraction.

While they aren't necessarily very human friendly, quaternions have definite benefits mathematically, and making it the responsibility of the hardware interface/driver to convert whatever internal orientation representation it uses to this 'intermediary representation' would seem to make sense.

I was discussing that with @RobertWilbrandt, as well and I would agree. But I think that's a question to discuss once the PR on ros2_controllers is there.

@gavanderhoorn
Copy link
Contributor

Oh, just noticed #856 actually does it that way.

@RobertWilbrandt
Copy link
Contributor

I don't have any strong opinions on this - Going through REP 103 i went through the options and preferred RPY because the values cannot represent any invalid state (while i would expect that a quaternion should be normalized). From an application point of view i agree, so i changed the representation in pose_broadcaster now.

Felix Exner added 4 commits October 9, 2024 14:54
# Conflicts:
#	ur_robot_driver/config/ur_controllers.yaml
#	ur_robot_driver/launch/ur_control.launch.py
#	ur_robot_driver/src/hardware_interface.cpp
This has now been merged to master.
Everything is merged upstream!
@fmauch fmauch requested a review from VinDp October 27, 2024 18:11
@fmauch fmauch marked this pull request as ready for review October 27, 2024 18:11
@fmauch
Copy link
Contributor Author

fmauch commented Oct 27, 2024

Binary builds fail as the necessary changes in ros2_control have just been merged into master.

Copy link
Contributor

@VinDp VinDp left a comment

Choose a reason for hiding this comment

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

Looks good to me and works as inteded.

@urfeex urfeex merged commit 660e363 into UniversalRobots:main Nov 11, 2024
8 of 12 checks passed
mergify bot pushed a commit that referenced this pull request Nov 11, 2024
Adds a broadcaster for the robot's TCP pose.

(cherry picked from commit 660e363)
mergify bot pushed a commit that referenced this pull request Nov 11, 2024
Adds a broadcaster for the robot's TCP pose.

(cherry picked from commit 660e363)
urfeex pushed a commit that referenced this pull request Nov 11, 2024
Adds a broadcaster for the robot's TCP pose.
urfeex pushed a commit that referenced this pull request Nov 14, 2024
Adds a broadcaster for the robot's TCP pose.
URJala pushed a commit to URJala/Universal_Robots_ROS2_Driver that referenced this pull request Dec 20, 2024
Adds a broadcaster for the robot's TCP pose.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants