kortex_arm_simulation crashes if the arm is mounted on a mobile robot #163
Comments
|
Hi @civerachb-cpr, I am not sure I understand everything in your question, so I will try to answer it the best I can. First, you seem to have trouble getting the robot_description. In kortex_arm_simulation.cpp, the robot_description is found using the hardcoded path defined within the robot_name namespace ( Second, you mentionned kortex_arm_simulation.cpp is starting Moveit, which is not the case (or at least I don't see anything related to moveit in kortex_arm_simulation.cpp). I am not sure what you are trying to achieve with the |
|
Sorry, let me clarify: Basically, we're using the Dingo as the main robot description, and adding the arm using the URDF Extras environment variable we support. You can see the Dingo description here: https://github.com/dingo-cpr/dingo/blob/melodic-devel/dingo_description/urdf/dingo-d.urdf.xacro. Specifically, at the end of the file (see: https://github.com/dingo-cpr/dingo/blob/06cdeee63212374608d0add4a780f49fca5d6ecc/dingo_description/urdf/dingo-d.urdf.xacro#L246) we can load a URDF stub to add additional links and joints to the base platform. In our setup, that environment variable points to the location of this file on-disk, which simply connects the Gen3 Lite xacro macro to one of the mounting points of the base platform. The model, viewed in Rviz looks like this:
When we configure the Dingo's URDF as described above and launch the simulation the model loads correctly, but the arm is completely slack and clips through the robot model. This, I assume, is because there is no ROS node running that is publishing the joint states of the arm joints. Echoing
My goal is to be able to get the kortex_driver running to control the arm inside Gazebo and have the joint states properly published & simulated. If I launch the kortex_driver without setting the
The robot description is provided by the dingo_description package: https://github.com/dingo-cpr/dingo/blob/melodic-devel/dingo_description/launch/description.launch When working with a physical arm mounted to a physical robot this is sufficient, and the robot works correctly. But when I launch the kortex_driver with the On the real robot, if we attempt to launch the kortex_driver using the standard launch file included in the kortex_driver package, the Dingo's robot_description parameter gets overwritten by Kinova's, and the robot model winds up in a broken state. We want to use the complete robot_description parameter published by dingo_description, which appears to be possible with the non-simulated version of kortex_driver. If I edit to use/robot_description, which is the description parameter we use when working on the physical robot, I can successfully load the parameter, but then the node crashes when looking up the move groups used by moveit.
For reference, here's the output of
Right here there appears to be a Moveit client starting, which is directly linked to the crash I'm seeing: When I launch with the fixed robot_description parameter path, I get the following error: The only reference to a group named At this point I'm not sure what my next logical step is. I'd rather not go through kortex_arm_simulation.cpp and manually remove all of the Moveit client code and recompile. But is that the correct course of action? Or am I missing something and there's a different/better launch file I should be using to launch the Kortex driver simulation while preserving the Dingo URDF and robot_description parameter? |
|
Ok, I understand your problem, and I will try my best to help you. When you start the driver with If you change ros_kortex/kortex_driver/src/non-generated/driver/kortex_arm_simulation.cpp Lines 141 to 149 in eef6758 This should allow you to finsh to initialization of the kortex_arm_driver.cpp. |
|
Ok, thanks. I'll try that out and let you know how it goes. Assuming it does work I may submit a PR to add some additional ROS params to make this easier to configure without needing to recompile the driver. |
|
I made the changes you suggested, and it seems like I'm making progress in the right direction. However, I'm noticing more inconsistencies between the real arm driver and the simulated one that seem to be causing further issues. After starting the kortex_driver with the simulation flag set to When using the real arm, the joint states are published on The only topics published by the arm driver when I run in simulation are: What topic should the joint states of the simulated arm be published on? |
civerachb-cpr
added a commit
to civerachb-cpr/ros_kortex
that referenced
this issue
Jul 15, 2021
…m when mounted to a mobile base. See Kinovarobotics#163
|
Hi @civerachb-cpr, I noticed you are using a prefix when launching the driver. I think this might be the problem here. I recently (last week) realised that something is not working when using a prefix and I haven't looked into it yet. I noticed this while looking at this PR. If it is possible, you might try to not use any prefix. Hopefully it is possible for you to use |
|
After further inspection, I don't think it is related to the Those two topics are supposed to be published at the end of the driver initialization Can you make sure everything has been initialized correctly with the param If everything looks good, this might indicate the problem is coming form Also, looking at your output, I get 2 topics related to the gripper that you do not have : Finally, I see that one of your topic is |
|
Hi @civerachb-cpr, Do you have any update on this? Regards, |
|
Hi, sorry for the delay replying to this. I'll get straight into answering your questions: 1- Yes, the gripper parameter is set to I suspect this may be due to a mismatch in prefixes between the URDF and the driver launch file? In order to keep the joint names unique across the robot we do use the Launching with the prefix argument set normally appears to run without any errors, but Roslaunch output: I do not see anything published on the I just pulled the latest |
|
Hi @civerachb-cpr, Did you delete some of the rows in your roslaunch output? I get way more stuff than you. I was wondering if you did it on purpose to make more readable. Also, your simulation driver does not seem to initialize correctly and I am not sure why. Can you also give the output of If it is not there, I think it might explain why all your topics are empty. To answer your question, there is no other branch you should try it on. Regards, |
|
@civerachb-cpr Hi, have you solved this problem? I am integrating Husky and Kinova Gen3 Lite in Gazebo, and have the same problem. Could you give any updates on how you solved them? |
|
Hi @yj-Tang, I don't know if @civerachb-cpr managed to fix the issue, but if you have the same issue, I can try to help you. What commit of the repo are you using? Best, |
|
Hi @felixmaisonneuve, The output of the |
|
Hi @yj-Tang, I have looked at what you sent me. This indeed looks like the same issue. Your simulation driver is not initializing correctly somewhere in this function : What arguments do you use with your Can you send the output of Best, |
|
Looking at the to might allow the simulation driver to find the |
|
Sorry about the late reply; just got back from vacation. No, I have not yet been able to fix this problem yet either. |
Hi, @felixmaisonneuve. Thanks for your quick reply. I have changed the scripts as you recommend. But it still makes no difference. The output of |
|
At that point, I am pretty sure it gets stuck at that line : because, based on your ros_kortex/kortex_driver/src/non-generated/driver/kortex_arm_simulation.cpp Lines 110 to 114 in 4f7e716 I would try changing the line to different variations like and Keep in mind you need to rebuild your catkin workspace with |
|
I tried different variations, but it still doesn't work. However, I can simulate the arm in gazebo and use moveit to control it without the driver. So I am wondering what is the function of this driver? Can we simulate the arm without the driver? |
|
The driver simulates some API calls (listed here) and add ros subscribers to certain topics that uses those API calls. It also initialize the 3 pre-defined arm positions in MoveIt (home, vertical, zero), so they might not work. Finally, it creates the ros publisher that publishes the arm's feedback on the If your use case doesn't use these and you are able to not use the driver, I think you could get away without using it, but some features may be broken, I am not sure to want extent it is a necessity. Out of curiosity, what did you remove exactly? What modifications did you do? The next step to debug this issue would be to add |
|
Actually, we didn't remove anything. We just combine the arm and our mobile base in one urdf file. Then create a moveit setup for the whole robot. The controllers can run correctly, but the driver of the arm always died. We can control the arm after all the stuffs are loaded in Gazebo. However, the initial pose of the robot can not be controlled (maybe it is influenced by the death of the driver ) which is quite annoying. I will try to debug with |
|
After adding the Our robot namespace is "/", so maybe the error comes from something related to this topic name [///joint_cmd] ? |
|
So turns out I was wrong and the driver can find the model just fine. It is crashing when trying to get the arm joints at You printed the value Can you copy the output of I am not sure what the |
|
Hi @yj-Tang, @civerachb-cpr, and @felixmaisonneuve, I have the same issue. Have you solved the problem?.
|
|
@dfalveargOT unfortunately I haven't had much chance to dig deeper into this in a long time. Last time I tried I was still encountering these issues though, so it sounds like not much has changed between when I opened this ticket and now if you're still running into this. |
|
@civerachb-cpr Hello! I'm also having the same problems detailed by everyone above. I haven't been able to find/create a fix either. Are there any updates/progress from the Clearpath side? Thanks! |
|
@RX-00, I've been swamped with other work lately and haven't had much time to revisit this. Last time I tried in May or June I was still having the same problems. |
|
Sorry about the delay in replying. I'd forgotten about this ticket as I haven't had to do any work with arms in a long time. I just tried it again; still seeing the same issues I previously reported. The situation appears unchanged since my last update six months ago. |
|
We have this issue, too. We have a mobile robot with two gen3 arms. I changed line 60 in kortex_arm_simulation.cpp as you said, and I commented out the moveit startup lines 141 to 149. Now both arm drivers are running. They both say is_initialized is false. This is because kortex_arm_simulation.cpp has hung at line 192, which is: m_follow_joint_trajectory_action_client->waitForServer and never returns to kortex_arm_driver.cpp which sets is_initialized to true, as well as registering the simulation handlers to the simulation will run properly. Something appears to be wrong with the communication between the action clients and the action servers. Perhaps a namespace problem? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A common use case (for us anyway) is mounting the Gen3 or Gen3 Lite onto a mobile robot platform (e.g. Clearpath's Jackal, Dingo, or Husky). Unfortunately, it appears to be impossible to run a complete simulation of the arm and mobile platform because of some issues inside kortex_arm_simulation.cpp:
The robot_description path is hard-coded. When mounting the arm on the real robot, we modify the base robot's URDF to include the arm macro. For example on a Dingo with a Gen3 Lite arm we would use https://github.com/dingo-cpr/dingo_manipulation/blob/main/dingo_kinova_description/urdf/dingo_gen3_lite_description.urdf.xacro to attach the arm to the robot. This results in the robot description parameter being /robot_description, but
ros_kortex/kortex_driver/src/non-generated/driver/kortex_arm_simulation.cpp
Line 60 in eef6758
/<arm-name>/robot_descriptionwhich does not exist in this use-case, and there's no way to modify this path without needing to recompile the driver.Even if we do change the
model.initParamline in kortex_arm_simulator.cpp, the fact that this class also tries to launch MoveIt and find planning groups causes the driver to crash anyway. We don't want to launch Moveit as part of the simulated driver; we just want to be able to get the joint states publishing correctly. We can launch Moveit ourselves (e.g. using https://github.com/dingo-cpr/dingo_manipulation/blob/main/dingo_gen3_lite_moveit_config/launch/move_group.launch) -- again, there doesn't appear to be any way to disable auto-launching Moveit without making some major changes to the driver and recompiling it.Is there a different node I should be launching to launch a simulated arm driver that just launches the core driver with a configurable robot_description path and without automatically starting Moveit planning groups? The launch file I'm using to start the arm is this:
with the
simparameter set totrue. This same launch file works properly on a physical robot (with thesimparameter set tofalse). My goal is to be able to have the simulation and real robot work as-similarly as possible. If I need to use a different node than thekortex_driver/kortex_arm_driverinstead, what node should I use instead?The text was updated successfully, but these errors were encountered: