-
Notifications
You must be signed in to change notification settings - Fork 25
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
[BUG] - Unable to connect to KUKA lbr iisy3 r760 using ROS2 Humble driver #154
Comments
Hi @prasuchit, I will try to solve your problem as soon as possible, although it seems to be a rather strange issue... The second attempt seems to be a communication issue, maybe your network cable was not correctly connected - I hope this only came up once. From the other two cases, what I can see is that the The problem seems to be related to the ROS2 side of the setup, so I would also suggest to try it out in mock mode: |
Hi @Svastits, Thanks for the prompt response. I don't think it's a ROS issue because for the past week, since the time the driver broke, I've been using this file to continue building and testing my code. Although I see some warnings and occasionally a couple of errors, I can still see and move the robot correctly on Moveit2-Rviz. I even tried running the C++ examples and they also work on the fake hardware. So I think the problem is connected to the real robot. |
Hi @prasuchit |
@Svastits your intuition was correct. It is related to the ROS package. This is what I see when I run the fake hardware:
Also, what is this SEVERE WARNING namespace collision that keeps popping up? How do we fix it? Since there are other errors earlier in the log, I decided to upload the complete log via txt file: |
@prasuchit I can see 3 issues in the logs:
|
Hi @Svastits, I appreciate you actively working with me on this to resolve the problem.
So I tried the second idea and updated the ros2_controllers.yaml: effort_controllers/JointGroupEffortController The problem persists. I've attached the updated log. |
@prasuchit this solved the effort_controller issue, now the event_broadcaster is not found and therefore cannot be activated. I have never seen such an issue before, a spawner process is not started, although it is specified in the launch file... Unfortunately I cannot come up with a non-workaround solution, as everything works fine for us both locally and in CI |
@Svastits that actually fixed the issue, I was able to plan and move the robot within fake execution!! :) However, it is puzzling why these issues are happening. I see that the robot manager is specified to start here. Is it dependent on something else? Maybe the order of starting the nodes matters? For sanity sakes, if you can, please check if someone on your side can set up all the repos on Humble just by following the Readme instructions and see if the same problems can be replicated. Just to verify with you that everything is fixed now, I've attached the latest log: |
The controller spawners depend on the Actually we have set up more machines based on the readme, and the industrial CI that runs for every push and PR is also following those steps, so I am pretty sure, that the issue is not on our side. The logs now seem mostly right, the second issue is still there that the hardware interface is activated automatically, then is reactivated when you activate manually. What is the ros2_control version you use? It should be 2.40, with that version, this should not happen... |
Hi @Svastits, I just checked: ros-humble-ros2-control is already the newest version (2.40.0-1jammy.20240304.153413). I'm closing this issue for now since it is working now, albeit through unconventional ways. Thanks for all the help. Is there a plan to move to Iron? MoveitPy is integrated into Iron and isn't available in Humble. |
Thanks :) |
Description
Prequisites:
I have ROS2, and all the necessary packages from here cloned and compiled successfully.
I have all the dependencies installed correctly.
I have the KUKA iiQKA.ExternalAPI Control 1.0.3 installed on the robot.
I have installed and verified the RT kernel correctly as described here.
Problem:
Until recently I was able to connect with the robot, send commands through moveit-rviz and make the robot move.
Recently I pulled changes from all the Kroshu GitHub packages and recompiled and suddenly saw it complain about missing ExternalAPI control toolbox. I assumed this was because the external API may have been updated, so I backed up my current installation, cloned a fresh version from here, followed the instructions, and compiled it successfully. After this, I was able to colcon build successfully but started running into communication issues.
I found a very similar issue logged on the GitHub repo [here](https://github.com/kroshu/kuka_drivers/issues/150](https://github.com/kroshu/kuka_drivers/issues/150), and the developer seems to point to the externalAPI as the source of the problem.
I've raised a ticket with KUKA Global (case #: 00973371) but haven't heard back in a few days. Please help. I'm working on a very strict deadline and need to get things operational soon!
@Svastits
KUKA robot OS
iiQKA
KUKA robot OS version
iiQKA.OS 1.2
KUKA external interface version
1.0.3
Affected robot model(s)
lbr iisy 3 r760
Version or commit hash of the driver
No response
Setup
Reproduction steps
I just followed the step-by-step instructions provided on the Kroshu GitHub readme and instructions provided by customer support representatives from KUKA USA to get everything set up and running. This problem started last week out of the blue.
Logs
The text was updated successfully, but these errors were encountered: