Hi Felix,<br><br>(1) This statement is a warning:<br>[ WARN] [1297153951.492886546, 276.592000000]: State violates goal<br>
constraints.<br>
You don't usually have to worry about it because it just says that the current state does not match the goal condition.<br><br>(2) Can you check and make sure that the IK solution is within joint limits. The joint limits should come from the urdf. If you have limits that you want to specify that are different from the ones in the urdf, you can add them in a file pr2_arm_navigation_config/config/joint_limits.yaml. Could you please check the equivalent file that you have and make sure you have the right limits set. <br>
<br>(3) Visualize the solutions - you can look at the pr2 kinematics or the tutorial for motion_planning_visualization to see how you can visualize the entire robot state. This will help you debug errors as well. <br><br>
Send more questions if this is still not working.<br><br>Regards,<br>Sachin<br><br><br><div class="gmail_quote">On Tue, Feb 8, 2011 at 12:55 AM, Felix Messmer <span dir="ltr"><<a href="mailto:felix_messmer@web.de">felix_messmer@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Dear Gil, dear Sachin,<br>
<br>
thanks a lot for your help and the detailed explanation!<br>
The Error referring to the floating_trans_x joint doesn't appear<br>
anymore...thus, this seems to be fixed! Thanks!<br>
However, I still get an Error message that says that the IK solution<br>
doesn't obey the goal constraints and that joint limits are violated.<br>
Although, the pose goal is right next to the care-o-bot and the (arm!)<br>
IK-solution lies within the joint limits.<br>
<br>
____________________________________________________________________________________________________________________________________________<br>
<br>
[ INFO] [1297153951.402688697, 276.559000000]: Received new goal<br>
[ INFO] [1297153951.440344878, 276.576000000]: Planning to a pose goal<br>
[ INFO] [1297153951.440452615, 276.576000000]: IK request<br>
[ INFO] [1297153951.440494169, 276.576000000]: link_name : base_link<br>
[ INFO] [1297153951.440526016, 276.576000000]: frame_id : base_link<br>
[ INFO] [1297153951.440560919, 276.576000000]: position :<br>
(-0.055000,-0.754000,0.602000)<br>
[ INFO] [1297153951.440597076, 276.576000000]: orientation :<br>
(0.626000,-0.390000,0.651000,-0.178000)<br>
[ INFO] [1297153951.440626177, 276.576000000]:<br>
[ INFO] [1297153951.492602527, 276.592000000]: Link name arm_7_link<br>
Position constraint satisfied: desired:: -0.055000, -0.754000, 0.602000,<br>
current:: 2.306240, -0.754654, 2.724826, tolerance: 0.400000, 0.400000,<br>
0.400000<br>
[ WARN] [1297153951.492886546, 276.592000000]: State violates goal<br>
constraints.<br>
<br>
[ INFO] [1297153951.501037132, 276.596000000]: IK returned joint state<br>
for goal that doesn't seem to be valid<br>
[ WARN] [1297153951.501105392, 276.596000000]: IK solution doesn't obey<br>
goal constraints<br>
[ WARN] [1297153951.530798642, 276.603000000]: Joint limits violated.<br>
<br>
[ERROR] [1297153951.541223194, 276.603000000]: Will not plan to<br>
<div class="im">requested joint goal since it violates joint limits constraints<br>
</div>______________________________________________________________________________________________________________________________________________<br>
<br>
<br>
I couldn't look into it more closely, since I'm busy doing something<br>
else first.<br>
But it seems that this is due to the cob's ik_solver. It currently<br>
doesn't support all the services that the pr2_kinematics stack provides,<br>
e.g. constraint_aware IK.<br>
Maybe the planner expects some more information within the IK-response<br>
that our ik_solver currently just doesn't provide.<br>
<br>
I'll have a look at that as soon as possible and then get back to you!<br>
<br>
<br>
Best regards,<br>
Felix<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 2011-02-04 18:15, Gil Jones wrote:<br>
> Hi Felix,<br>
><br>
> As Sachin said, the bug you were seeing should be fixed. By way of<br>
> explanation, we were trying to accomplish a few things with the multi-dof<br>
> transform. The primary purpose is to supply a mechanism for a<br>
world->robot<br>
> transform that supplements the urdf, which doesn't and shouldn't really<br>
> supply information about how to transform between a fixed world frame<br>
and a<br>
> frame for the movable base. The world transform should be either be a<br>
3-dof<br>
> Planar Joint with (x,y,th) or a 6-dof Floating Joint with a full<br>
orientation<br>
> matrix. We found on the PR2 that we had to use a floating joint as there<br>
> can occasionally be enough of a pitch and roll in our IMU such that they<br>
> need to be accounted for. It's entirely fine to do what you've done<br>
below,<br>
> which is to say that you essentially don't care about the fixed transform<br>
> and will always be planning based on the current base position of the<br>
> robot. So that should be all you need to do.<br>
><br>
> Having a fixed reference transform should allow two important pieces of<br>
> functionality - as you say, it should allow you to plan to move the base,<br>
> and it should also allow you to pose the robot some where else in the<br>
world<br>
> and plan based on that new pose - for instance, you might be<br>
interested to<br>
> know whether an object across the room from the robot's current<br>
location can<br>
> be picked up given a particular approach pose. By specifying a new<br>
> multi-dof transform in the start_state message our system should support<br>
> such things, though it is not the case that our current planners fully<br>
> support the former use-case.<br>
><br>
> The other purpose of the multi-dof joints is to equip the system to<br>
use tf<br>
> transforms instead of just joint_state messages to populate the current<br>
> position of the robot. The system is set up to first try to set multi-dof<br>
> joints from individually labeled entries in the joint state and then<br>
to use<br>
> tf to get a pose transform for the entire joint if it needs to. The<br>
message<br>
> you are seeing refers to one of the labeled single dofs -<br>
'floating_trans_x'<br>
> - of the multi-dof joint 'base_joint'. The bug was that for the<br>
purposes of<br>
> checking joint limits the individually-labeled dofs were not being<br>
mapped to<br>
> the multi-dof joint.<br>
><br>
> As arm_navigation matures we will try to do a better job of making<br>
migration<br>
> guides that explain new features and inform users what they need to do to<br>
> adopt a new version. At this point we're focused on making relatively<br>
large<br>
> changes that we hope will make things work better and make it easier<br>
to get<br>
> our stacks working on other arms, but we still have a ways to go. We're<br>
> targeting e-turtle for a 0.9 or 1.0, at which point things should<br>
stabilize<br>
> a good deal.<br>
><br>
> Please let us know if the bug fix doesn't work or if you have other<br>
> problems.<br>
><br>
> -Gil<br>
><br>
> --<br>
> E. Gil Jones (<a href="mailto:gjones@willowgarage.com">gjones@willowgarage.com</a>)<br>
> Research Engineer<br>
> Willow Garage, Inc.<br>
> 68 Willow Road<br>
> Menlo Park, CA 94025<br>
</div></div> > 650.475.9772 <tel:+16504759772><br>
<div><div></div><div class="h5"> ><br>
><br>
> On Fri, Feb 4, 2011 at 1:23 AM, Sachin Chitta<br>
<<a href="mailto:sachinc@willowgarage.com">sachinc@willowgarage.com</a>>wrote:<br>
><br>
> > Hi Felix,<br>
> ><br>
> > This should be fixed in motion_planning_common 0.3.5 (thanks to Gil).<br>
> > Can you try it out and let us know.<br>
> ><br>
> > Thanks,<br>
> > Sachin<br>
> ><br>
> > On Wed, Feb 2, 2011 at 4:09 AM, "Felix Meßmer" <<a href="mailto:Felix_Messmer@web.de">Felix_Messmer@web.de</a>><br>
> > wrote:<br>
> > > Dear community,<br>
> > ><br>
> > > there is another feature in the unstable/diamondback version of the<br>
> > arm_navigation stack that I have problems with:<br>
> > > the multi_dof_joints parameter-option!<br>
> > ><br>
> > > When I use our old launch file<br>
> > (cob_arm_navigation/cob3_planning_environment.launch) that loads the<br>
> > collision_checks and planning_groups paramters to the parameter<br>
server, I<br>
> > get the following error message from both the trajectory_filter and the<br>
> > ompl_planning node:<br>
> > ><br>
> > > [ WARN] [1296646033.585385464]: No multi dof joints specified,<br>
including<br>
> > root to world conversion<br>
> > > [ WARN] [1296646033.585623806]: Can't do anything without a root<br>
> > transform<br>
> > ><br>
> > > I've adapted the planning_environment.launch file to also load the<br>
> > multi_dof_joints parameter (looking at the according pr2-config files).<br>
> > > But now planning reqest as in move_arm_simple_pose goal fail due<br>
to the<br>
> > following error message from the environment_server node and the<br>
move_arm<br>
> > action server node:<br>
> > ><br>
> > > [ WARN] [1296647088.916018038, 830.563000000]: No joint with name<br>
> > floating_trans_x<br>
> > > [ WARN] [1296647088.916446633, 830.563000000]: Joint limits violated.<br>
> > ><br>
> > > [ERROR] [1296647088.925356070, 830.563000000]: Will not plan to<br>
requested<br>
> > joint goal since it violates joint limits constraints<br>
> > ><br>
> > ><br>
> > > The multi_dof_joints.yaml file I use looks like this:<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
</div></div><div class="im"> > > > I guess the multi_dof_joint parameter is meant to introduce a<br>
joint that<br>
> > stands for the moving platform with 3 DoFs (trans_x, trans_y, rot_z)<br>
> > > Does that mean that if the pose goal is specified in a world/global<br>
> > coordinate system, the planner also considers and calculates a possibly<br>
> > necessary platform motion to reach the specied goal?<br>
> > ><br>
> > > Is there a parameter (use_multidof?) for the environment_server to<br>
> > deactivate multi_dof_joints?<br>
> > > OR:<br>
> > > What else do I have to add to use that feature?<br>
> > ><br>
> > ><br>
> > > I hope you can give me a short explanation on that. Thanks a lot!<br>
> > ><br>
> > ><br>
> > ><br>
> > > Regards,<br>
> > > Felix<br>
> > > ___________________________________________________________<br>
> > > <a href="http://WEB.DE" target="_blank">WEB.DE</a> DSL Doppel-Flat ab 19,99<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Sachin Chitta<br>Research Scientist<br>Willow Garage<br>