Open fmauch opened 1 year ago
@fmauch I didn't experience this in my application. We also didn't see this while testing last week didn't we?
Seeing this line regularly means that somehow the command_interface_configuration
is called every 2 seconds (https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/blob/fb5972dcd28425a73da3aa524493c9bc886f0f2c/ur_controllers/src/gpio_controller.cpp#LL66C1-L66C1) which is definitely shouldn't.
I agree with removing this output, but nevertheless you should check your system setup why it regularly reinits (is it really a reinit) the controller ( or creates a new controller instance).
@fmauch Did you manage to further investigate this issue?
I managed to repoduce this issue (even though I do not get a regular printout). I think it is ros2 control related. For some reason it calls for many operations command_interface_configuration
. I guess what happens there is that the controller manager creates for certain operations a new instance and configures it.
Yes, I've also experienced it only in certain circumstances. For example, when having the rqt_joint_trajectory_controller open, this seems to get called regularly. But apart from that I didn't further investigate this.
I guess this is an issue which should be reported in ros2_control then.
We have the same problem with our workspace that includes the UR5. Ever since the binary release 2.2.6-1
in May 2023 our driver broke due to the tf_prefix
problem in #677 . With the release of the driver binary 2.2.8-1
, we can start the driver again (sort of) with our tf_prefix "ur5/"
, however the scaled_joint_trajectory_controller
doesn't get activated (checked with ros2 control list_controllers
).
The same print out as described by @fmauch above (Configure UR gpio controller with tf_prefix: ur5/
) appears repeatedly with very high frequency (multiple per second) until the driver eventually dies.
slightly adapted from original source only in terms of config file paths, using calibrated kinematics instead of default, not using robot state publisher because we already have one of our own and custom robot_description.
ur_controllers.yaml
only the tf_prefix
is different from the original source
@firesurfer you said that this is a ros2_control issue. I'd like to help finding this issue, but I'm unsure where to begin as I'm not familiar with ros2_control. If you maybe have a hint for the search in the upstream ros2_control repo, I could open an issue there and track down the problem. At the minute I just don't know, what to even call the issue in ros2_control.
Thanks for both your efforts!
@niemsoen just to be clear: The output mentioned above is not a real issue, it is rather unpleasant. The SJTC not getting activated has (most probably) nothing to do with that.
Your controllers config file seems to be missing some tf_prefix adaption. Please see the file we have in #726. You'll also have to prefix the speed_scaling_interface_name
(and tcp_fts_sensor
to be complete) as your log output states.
Please do not further post in this issue if you keep having problems with startup, since as stated above this is most probably not related to the output.
Edit: Of course: If you keep having problems feel free to open a new issue. I did not want to tell you to not further bother us, I just think it doesn't belong in this issue.
@fmauch thank you so much, you made our day. I didn't see the instructions in #726, thanks for pointing it out - now it works!
I got the problem solved by building ros2_control from source.
@JaisonJose241 Can you tell me which commit you are exactly on. I just digged a bit through the ros2_control master branch and I couldn't find any commit which could explain why this issue doesn't occur when building from source.
Since #594 the GPIO controller prints
quite regularly (~every 2 secs). I'm not sure whether this should be normal from the documentations, but I suggest to remove the output / making this a print once.
@firesurfer did you experience this in your applications, as well?