Skip to content
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

rqt_joint_controller fix for getting feedback #893

Closed
wants to merge 1 commit into from

Conversation

tstoyanov
Copy link

At some point there has been a change in the feedback that joint_trajectory_controllers publish and that has not propagated tot the rqt plugin. I've deduced the correct place to get the joint state values would be from /controller_name/state.actual instead of /controller_name/controller_state.feedback. Tested change with current humble release and gazebo plugin, seems to work fine for me.

…nd get feedback from the actual joint states
@christophfroehlich
Copy link
Contributor

Hi @tstoyanov!
It is the other way round, ~/controller_state is the new topic :) see

publisher_ = get_node()->create_publisher<ControllerStateMsg>(
"~/controller_state", rclcpp::SystemDefaultsQoS());

We made the change somewhen on rolling, and fixted rqt_jtc with #643
Humble should have worked always, because we only deprecated the "old" topic and message type. But soon we will backport this also to humble to use the new one (to avoid deprecation warnings), see #659

Or have you encountered a problem recently? We fixed some issues with #890. I'll close this PR now, if you still have problems feel free to open an issue describing it.

You are cordially invited to contribute to this repo, e.g., I just created an issue with some ideas for refurbishing rqt_jtc: #894

@tstoyanov
Copy link
Author

Right, sorry about that, should have checked more carefully. I am running the most recent humble release, that has joint_trajectory_controller at version 2.26 (current in humble branch is 2.29) and probably that change has not propagated there yet, since I don't see the controller_state topic at all when I get a controller up and running. Thanks for checking, will either build from source or wait for the next releases.

@christophfroehlich
Copy link
Contributor

That is strange, controller_state is there even for an earlier version of 2.26. Can you verify with ros2 node info that there aren't two publishers? E.g.

$ ros2 node info /trajectory_controllers
/trajectory_controllers
  Subscribers:
    /clock: rosgraph_msgs/msg/Clock
    /parameter_events: rcl_interfaces/msg/ParameterEvent
    /trajectory_controllers/joint_trajectory: trajectory_msgs/msg/JointTrajectory
  Publishers:
    /parameter_events: rcl_interfaces/msg/ParameterEvent
    /rosout: rcl_interfaces/msg/Log
    /trajectory_controllers/controller_state: control_msgs/msg/JointTrajectoryControllerState
    /trajectory_controllers/state: control_msgs/msg/JointTrajectoryControllerState
    /trajectory_controllers/transition_event: lifecycle_msgs/msg/TransitionEvent

@tstoyanov
Copy link
Author

Yes, here is the output:

ros2 node info /joint_trajectory_position_controller
/joint_trajectory_position_controller
  Subscribers:
    /joint_trajectory_position_controller/joint_trajectory: trajectory_msgs/msg/JointTrajectory
    /parameter_events: rcl_interfaces/msg/ParameterEvent
  Publishers:
    /joint_trajectory_position_controller/state: control_msgs/msg/JointTrajectoryControllerState
    /joint_trajectory_position_controller/transition_event: lifecycle_msgs/msg/TransitionEvent
    /parameter_events: rcl_interfaces/msg/ParameterEvent
    /rosout: rcl_interfaces/msg/Log
  Service Servers:
    /joint_trajectory_position_controller/describe_parameters: rcl_interfaces/srv/DescribeParameters
    /joint_trajectory_position_controller/get_parameter_types: rcl_interfaces/srv/GetParameterTypes
    /joint_trajectory_position_controller/get_parameters: rcl_interfaces/srv/GetParameters
    /joint_trajectory_position_controller/list_parameters: rcl_interfaces/srv/ListParameters
    /joint_trajectory_position_controller/set_parameters: rcl_interfaces/srv/SetParameters
    /joint_trajectory_position_controller/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically
  Service Clients:

  Action Servers:
    /joint_trajectory_position_controller/follow_joint_trajectory: control_msgs/action/FollowJointTrajectory
  Action Clients:

Only one publisher pops up. This is when running example_1 from https://github.com/ros-controls/ros2_control_demos

@christophfroehlich
Copy link
Contributor

Are you sure you have 2.26 installed? See

$ ros2 pkg xml joint_trajectory_controller
<package format="3">
  <name>joint_trajectory_controller</name>
  <version>2.29.0</version>
  <description>Controller for executing joint-space trajectories on a group of joints</description>
  ...

@tstoyanov
Copy link
Author

Right, this was unexpected :) I had an overlay from franka which was running a joint trajectory controller at version 3.3. I did a clean workspace and with 2.26 I get both state and controller_state, as expected. The release version of rqt_joint_trajectory_cntroller still does not work out of the box with that particular example, but I think that's because the joints are continuous (no limits) and the plugin doesn't know what to do when initializing the sliders. Mystery solved, thanks for the help!

@christophfroehlich
Copy link
Contributor

You're welcome :)

See
ros-controls/ros2_control_demos#387
and
#897

-> if you build both from source it should work now (maybe you need to copy the changes from the demos to the humble branch unless the backport was merged there).

henrygerardmoore pushed a commit to henrygerardmoore/ros2_controllers that referenced this pull request Jul 19, 2024
Covariances values should come from the IMU_Broadcaster, like the frame_id or the time
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.

2 participants