MoveIt demo with Gazebo and j2s7s300 #132
Comments
|
We are using gazebo and j2s7s300 right now, and never experienced such behaviour... Strange. |
|
Yeah... well maybe it is related to my hardware (just guessing here?). I now I had some trouble running heavy simulation in Gazebo on my laptop... I'll look up on the internet once more to see if I find something related. Anyone, let us know if you experience such a similar behaviour and if you found a solution for it obviously :-) |
|
I have also encountered this issue. In my case the value for j2s7s300_joint_6 could be as high as 17. When outside of limit, I've also noticed the gazebo controller might also demonstrate incorrect behavior. For example, when the corrent postion is at 17, and I issue a command for 16.5, the controller sometimes direct the arm towards positive direction and reach 18, etc. |
|
Hi @haudren Good observation. I still do not know what causes this issue though. It seems to be a problem with the Gazebo controller. This controller seems to prefer symmetric angle limits (e.g. -X to +X rather than limits from 0 to 2X). I do not know why.... |
|
Hi @martine1406, I have encountered this strange behaviour a while ago. Apparently, there is a problem with the I am not using MoveIt! currently, but I stumbled upon this bug when I was trying to reset the arm in Gazebo through I ended up implementing my own plugin for getting the joint states. This plugin publishes joint position and velocity. It also provides a topic for applying torque to the robot joints (which I guess you wouldn't be needing it). Hope this helps, |
|
Hi @sahandrez I've tried your solution but when I launch the Robot in gazebo with use_ros_control:=false the arm shows as if there was no controller (not static in home position but jiggling). Am I doing something wrong? Also, would your plugin fix the inconsistent values on joint_5 and joint_6? Thanks in advance |
|
I'm having the same problem with j2n6s300. My setup is Ubuntu 16.04, ROS Kinetic and Gazebo 7. My launch sequence is as follows: The arm comes up fine in Gazebo and moves to the home position. I can move the fingers using MoveIt by setting the "Open" or "Closed" goal states. However, if I select the arm move group and try to set any goal state, even one slightly different from the current state, I get an error similar to the following: |
|
This thread has being inactive for over 2 years, I am closing this issue. If there is still a problem, please create a new issue. Thank You |
|
is the problem solved? I am using UBUNTU 20.04. The same problem? Can anyone help? |
|
Hi @ZZWang21, Can you elaborate on what you changed? What error messages do you get? How often do you have this issue? Does it happen in a particular sequence? In a specific position? Best, |
|
Currently I did not change anything. I am using arm to do reinforcement learning tasks. Every time the scene resets, the joint is 2pi more or less than the value I set. I have no idea why.
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Félix Maisonneuve ***@***.***>
Sent: Thursday, May 25, 2023 4:13:25 PM
To: Kinovarobotics/kinova-ros ***@***.***>
Cc: Zezhong Wang ***@***.***>; Mention ***@***.***>
Subject: Re: [Kinovarobotics/kinova-ros] MoveIt demo with Gazebo and j2s7s300 (#132)
Hi @ZZWang21<https://github.com/ZZWang21>,
You have the same behaviour? You get errors like
[ INFO] [1538058213.924470173, 102.585000000]: Planning attempt 1 of at most 1
[ WARN] [1538058213.924668692, 102.585000000]: Joint 'j2n6s300_joint_3' from the starting state is outside bounds by a significant margin: [ 12.898 ] should be in the range [ 0.331613 ], [ 5.95157 ] but the error above the ~start_state_max_bounds_error parameter (currently set to 0.1)
[ INFO] [1538058213.925556105, 102.586000000]: Planner configuration 'arm' will use planner 'geometric::RRTConnect'. Additional configuration parameters will be set when the planner is constructed.
[ WARN] [1538058213.925981734, 102.586000000]: RRTConnect: Skipping invalid start state (invalid bounds)
[ERROR] [1538058213.926134385, 102.587000000]: RRTConnect: Motion planning start tree could not be initialized!
Can you elaborate on what you changed? What error messages do you get? How often do you have this issue? Does it happen in a particular sequence? In a specific position?
Best,
Felix
—
Reply to this email directly, view it on GitHub<#132 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANHFTII2PPCSY3V33PQD2GTXH5ZJLANCNFSM4E5TOMIA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
This is interesting. Can you detail what is your exact sequence of commands and the behaviour you have? Best, |
|
Yes. Noetic with Gazebo11.
The robot goes to initial position. And it learns to Move to target using RL. After Every step it comes back to initial position. But after a certain number of cycles, the robot comes back to initial pose, but cannot move any more. Because the joint position out of bound, some joints are 2pi bigger than the initial position. But you know, 2pi bigger means the position is the same, but since it is out of bound, it will not move again.
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Félix Maisonneuve ***@***.***>
Sent: Thursday, May 25, 2023 8:04:27 PM
To: Kinovarobotics/kinova-ros ***@***.***>
Cc: Zezhong Wang ***@***.***>; Mention ***@***.***>
Subject: Re: [Kinovarobotics/kinova-ros] MoveIt demo with Gazebo and j2s7s300 (#132)
This is interesting.
If you are on Ubuntu20.04, this means you are using the Noetic branch with Gazebo11. Can you confirm?
Can you detail what is your exact sequence of commands and the behaviour you have?
Best,
Felix
—
Reply to this email directly, view it on GitHub<#132 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANHFTIKHQJ25HRRH7NJS67LXH6ULXANCNFSM4E5TOMIA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
This makes me think it might be a wrap around issue. Can you check what movement the simulation is doing before it fails to see if it could be something like this? |
Thanks for your reply. It was possible, but I currently cannot record what it was doing. Since I am doing reinforcement learning training on the robot and sometimes (you never know when), it comes up with a out of bound alarm and the training stop. It may be because during training, the robot goes back to the home position, it goes in the way you just described. But currently, I have no idea how to record everything. Do you know how to set it to go back to home position? Thanks very much. |
|
I think you have no choice but to send a command with the position of each joint. For the home position, you can find the position of eah joint in the Gazebo robot_launch.launch file : kinova-ros/kinova_gazebo/launch/robot_launch.launch Lines 37 to 45 in d8a6b5a Best, |
The following code runs moveit with the Gazebo model for robot j2s7s300 (7 dof robot with a spherical wrist)
roslaunch kinova_gazebo robot_launch.launch kinova_robotType:=j2s7s300then
roslaunch j2s7s300_moveit_config j2s7s300_gazebo_demo.launchthe planning in moveit fails every time with this warning:
[ WARN] [1525102790.308848354, 63.185000000]: Joint 'j2s7s300_joint_6' from the starting state is outside bounds by a significant margin: [ 7.4013 ] should be in the range [ 1.13446 ], [ 5.14872 ] but the error above the ~start_state_max_bounds_error parameter (currently set to 0.1)
Indeed, when we monitor the joint_states topic /j2s7s300/joint_states, you see that joint 6 is at 7.401301704590916, which is outside of its limits. I could not find much information on this error in gazebo, but it seems it might be related to an instability or something when the robot get's spawned.
I first tried to modify the controllers of the 7 dof robot here , but nothing would do. Then I tried to change the urdf file and change the angle limits on joint 6. I was very surprised to see that if I am more tolerant on the limits e.g.
<property name="joint_6_lower_limit" value="${30/180*J_PI}" /> <property name="joint_6_upper_limit" value="${330/180*J_PI}" />the robot was then spawned with angle 6 inside the limits. I do not get this exact behaviour....
The thing is, the real Kinova 7 dof robot with a spherical wrist has angle limits 65-295 degree on joint 6 for safety reasons. Changing the limits for this actuator in the urdf file means the gazebo model as well as the planning in moveit will not be really representative of the real robot's capabilities. Then, I tried to modify the frames orientation so the zero position on joint 6 in the urdf is when link5 and link6 form a straight line. This corresponds to 180 degree on joint 6 on the real robot.
The changes in the urdf file were the following:
joint 6 now defined as:
<property name="joint_6" value="joint_6" /> <property name="joint_6_type" value="revolute" /> <property name="joint_6_axis_xyz" value="0 0 1" /> <property name="joint_6_origin_xyz" value="0 0 -0.10375" /> <property name="joint_6_origin_rpy" value="${-J_PI/2} 0 0" /> <property name="joint_6_lower_limit" value="${-2.78}" /> <property name="joint_6_upper_limit" value="${2.78}" />instead of
<property name="joint_6" value="joint_6" /> <property name="joint_6_type" value="revolute" /> <property name="joint_6_axis_xyz" value="0 0 1" /> <property name="joint_6_origin_xyz" value="0 0 -0.10375" /> <property name="joint_6_origin_rpy" value="${J_PI/2} 0 ${J_PI}" /> <property name="joint_6_lower_limit" value="${65/180*J_PI}" /> <property name="joint_6_upper_limit" value="${295/180*J_PI}" />I also modified the start up position in move_robot.py from moveJoint ([0.0,2.9,0.0,1.3,4.2,1.4,0.0],prefix,nbJoints) to moveJoint ([0.0,2.9,0.0,1.3,1.5,-1.8,2.0],prefix,nbJoints) to take into account joint 6's new "zero position"
This is a working solution, but it requires to change what is published by kinova_arm.cpp on j2s7s300_driver/out/joint_angles for joint 6, and possibly kinova_joint_trajectory_controller.cpp.
I wondered if anyone has already experienced any issues with Gazebo not respecting joint limits given in the urdf at spawning? If so, let us know
Cheers
The text was updated successfully, but these errors were encountered: