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. I will look into your kinematics_utils package. Sachin On Tue, Jan 18, 2011 at 2:01 PM, Konrad Banachowicz wrote: > 2011/1/18 Sachin Chitta > >> Hi Konrad, >> >> 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. >> > ok so there should be corresponding for "plugins" > >> 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. >> > 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. > > 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. >> >> 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. >> > Documentation would be very useful. > >> 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. >> > I have created kinematics_utils package containing useful functions from > pr2_kinematics_utils and node capable of loading kinematics plugins and > providing kinematics sevices. > > >> Sachin >> >> >> On Sun, Jan 16, 2011 at 11:09 AM, Konrad Banachowicz wrote: >> >>> 2011/1/16 Herman Bruyninckx >>> >>>> On Sun, 16 Jan 2011, Konrad Banachowicz wrote: >>>> >>>> I started to move our code for our robot kinematics to ROS. >>>>> I would like to know what is the stabilization status of kinematics >>>>> stack, >>>>> because latst review happend nearly year ago. >>>>> I have some remarks and suggestions about kinematics stack : >>>>> - kinematics serwices use motion_planning_msgs/RobotState which >>>>> contains alot of >>>>> unnecessary data. >>>>> - SolverInfo contains limits field which duplicate data avalible >>>>> through >>>>> robot_description. >>>>> >>>> >>>> You might want to configure a solver with tighter limits than what the >>>> robot's mechanics impose... >>> >>> ok but those data are read-only by getSolverInfo service. >>> Currently every implementation simply send data readed from >>> robot_description. >>> >>>> >>>> >>>> - pr2_kinematics contains many useful functions in >>>>> pr2_arm_kinematics_utils.cpp >>>>> this could be moved to common package, maybe kinematics_utils. >>>>> >>>>> - common node for ik and ik_with_constraints should exist, using >>>>> kinematics >>>>> plugins. >>>>> This would simplify implementation of kinematics for new robot. >>>>> >>>> >>>> Herman >>>> _______________________________________________ >>>> ros-users mailing list >>>> ros-users@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-users >>>> >>>> >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-users >>> >>> >> >> >> -- >> Sachin Chitta >> Research Scientist >> Willow Garage >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> >> > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > -- Sachin Chitta Research Scientist Willow Garage