2011/1/18 Sachin Chitta > 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. > But why that would need new message, putting string[] joint_names float64[] joint_positions directly into the service would not be sufficient ? > I will look into your kinematics_utils package. > I forgot to send you link to my repo : https://github.com/konradb3/sandbox > > 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 > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >