JointState is a frozen message currently. The option would be to use a
different message there that just contains position. This would create
yet another message and we want to keep the number of messages
representing basic quantities at a minimum. Having a couple of extra
fields that will be ignored is a small price to pay here. We can make it clear in the documentation that these fields in the jointstate message are ignored by the solvers.<br>
<br>I will look into your kinematics_utils package. <br><br>Sachin<br><br><div class="gmail_quote">On Tue, Jan 18, 2011 at 2:01 PM, Konrad Banachowicz <span dir="ltr"><<a href="mailto:konradb3@gmail.com">konradb3@gmail.com</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;">2011/1/18 Sachin Chitta <span dir="ltr"><<a href="mailto:sachinc@willowgarage.com" target="_blank">sachinc@willowgarage.com</a>></span><br>
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Konrad, <br><br>The GetKinematicSolverInfo was intended as a read-only information service that would provide information about the joint limits used in the solver. The service itself is a convenience service and not really essential since most of the information comes from the robot description. Note that none of the services impose any conditions on where the limits are sourced from. Currently, they are sourced from the robot description internally in the node but I could add an api where you can override those limits using ROS parameters. <br>
</blockquote></div><div>ok so there should be corresponding for "plugins"<br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
RobotState is intended for complete representation of a generic robot state and not just an arm. I am not sure what you mean by "contains alot of unnecessary data". Could you please clarify which fields are unnecessary.<br>
</blockquote></div><div> I was thinking about multi_dof_joint_state field and vellocity and effort fields of joint_state. Those field seem to be ignored by kinematics solvers.<br></div></div></blockquote><div><br><br><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I expect the core kinematics services (GetPositionIK, GetPositionFK) themselves to be stable. The only possible change is to add a "group name" so you would not have to specify every joint to be used by the solver. The other possible change would be to add a new service that lets you call IK on a vector of poses to save the trouble of calling a service multiple times. I would prefer not to do a wholesale change of API but would like to get some of the convenience elements (like group names) in.<br>
<br>I do have an "plugin" implementation of the kinematics in place right now but I have not pushed it out. It lets you configure and call solvers using the plugin architecture used by other components in ROS (like the navigation stack). I will push it out for review in a few days after putting up more documentation.<br>
</blockquote></div><div>Documentation would be very useful. <br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">You are welcome to send more such feedback. In fact, if anyone would like to step up and volunteer to help maintain the kinematics stacks and do some of these API changes (like Jack O'Quinn is maintaining camera drivers), that would be more than welcome.<br>
</blockquote></div><div>I have created kinematics_utils package containing useful functions from pr2_kinematics_utils and node capable of loading kinematics plugins and providing kinematics sevices. <br> <br></div><div><div>
</div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Sachin<div><div></div><div><br><br><div class="gmail_quote">On Sun, Jan 16, 2011 at 11:09 AM, Konrad Banachowicz <span dir="ltr"><<a href="mailto:konradb3@gmail.com" target="_blank">konradb3@gmail.com</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;">
2011/1/16 Herman Bruyninckx <span dir="ltr"><<a href="mailto:Herman.Bruyninckx@mech.kuleuven.be" target="_blank">Herman.Bruyninckx@mech.kuleuven.be</a>></span><br><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Sun, 16 Jan 2011, Konrad Banachowicz wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I started to move our code for our robot kinematics to ROS.<br>
I would like to know what is the stabilization status of kinematics stack,<br>
because latst review happend nearly year ago. <br>
I have some remarks and suggestions about kinematics stack :<br>
- kinematics serwices use motion_planning_msgs/RobotState which contains alot of<br>
unnecessary data.<br>
- SolverInfo contains limits field which duplicate data avalible through<br>
robot_description.<br>
</blockquote>
<br></div>
You might want to configure a solver with tighter limits than what the<br>
robot's mechanics impose...</blockquote></div><div>ok but those data are read-only by getSolverInfo service.<br>Currently every implementation simply send data readed from robot_description. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<div><div></div><div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- pr2_kinematics contains many useful functions in pr2_arm_kinematics_utils.cpp<br>
this could be moved to common package, maybe kinematics_utils.<br>
<br>
- common node for ik and ik_with_constraints should exist, using kinematics<br>
plugins.<br>
This would simplify implementation of kinematics for new robot.<br>
</blockquote>
<br></div></div><font color="#888888">
Herman</font><br></div>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">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>
<br></blockquote></div><br>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">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>
<br></blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br>Sachin Chitta<br>Research Scientist<br>Willow Garage<br>
</font><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">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>
<br></blockquote></div></div></div><br>
<br>_______________________________________________<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>
<br></blockquote></div><br><br clear="all"><br>-- <br>Sachin Chitta<br>Research Scientist<br>Willow Garage<br>