christianlandgraf
commented
2 years ago I'm getting the same error but it disappears if the External Control URCap is running. If it is stopped, the error messages reappear
Closed fmauch closed 2 years ago
christianlandgraf
commented
2 years ago I'm getting the same error but it disappears if the External Control URCap is running. If it is stopped, the error messages reappear
fmauch
commented
2 years ago I can confirm that once I start running the external control program the message goes away. Looking at the code I am wondering why this message was even added.
When designing the interface we deliberately chose only to send commands to the hardware if it could receive them (meaning if the custom port for receiving commands is actually open). In the ROS1 driver we silently ignore that case not out of laziness but as this would actually be the expected state.
That behaviour had been added in 349aa4f711dc416304d1a93a0f89192e9bf1ff8a. While it makes sense on the reading side, it does not make too much sense on the writing side from my point of view. @livanov93 am I missing something?
Edit: The corresponding PR #233 explains the motivation, but I think it would be better to return hardware_interface::return_type::OK without the error output.
destogl
commented
2 years ago Other than that, it appears that you are missing forward_position_controller
fmauch
commented
2 years ago I think, this can be closed by now...
When trying to run the driver on ROS2 Rolling I experienced some problems. (See launchfile output below)
My workspace looks like this and is up-to-date (as of writing this):
When using the driver with ROS2 Foxy (with the
foxybranch of this driver), everything works out great. I am currently dropping this here, without further investigating it. If it works for everybody else, feel free to close this, but since I just installed ROS Rolling and tested the driver, I guess others might also fall into this problem.