[lwr_hw] enhancement #42
Conversation
- A small fix in the name of the gazebo plugin. - Deleted unsused transmission, and robotNamespace tag I don't what I did with the urdf, I don't remember I touched it, perhaps only fixing indentations, but it gives me a lot of changes, and some not trivial.
One class to define the robot: lwr_hw The class parses urdf, transmission, register interfaces, everything that has to do with the abstraction of the arm, only dependencies to ros-controls. With 3 pure virtual functions init(), read() and write() to implement different hooks FRI, Gazebo, Vrep, etc. Now lwr_hw_real and lwr_hw_sim only implements those 3 functions, and in the lwr_hw_real, also the doSwitch() to chain the switch to FRI/KRL. Hence, no more different KRL script, only one that manages the switch. The lwr_hw_real_node is almost untouched, but still one pending issue to solve, getting the node namespace should be clean, it adds "//" that need to be removed. The lwr_hw_sim_plugin is merely a gazebo model plugin that instantiate the lwr_hw_sim plugin, so no more different robot interfaces, this is the lwr 4+ plugin. Added a document that explains how KRC/KRL works for reference. Questions?
- Updates in the package.xml's dependencies - Deleted the state_publisher.launch since gravity compensation is done differently - Changing all controller names to lowercase to differentiate from the types.
Some directions to where lwr_controllers should go until a ImpedanceJointInterface (for full exposal of FRI values) or joint_mode_controller (see pal-robotics-forks/ros_controllers#41), or to allow multiple command interfaces for a resource? Too many options !
* unisgned int -> int in n_joints_ loops * Fixes in the KRL script * Changing name of files to reflect the used low-level interface (hence the lwr_hw.launch and kuka_lwr.gazebo.xacro as well)
- Update, switch works fine but still need to work on the calling functions. - Initial work in supporting Standford library (fork https://github.com/iocroblab/fril)
|
[Update]
|
…kuka-lwr into lwr_hw_enhancement
Update travis to compile with indgo in ubuntu 14.04 BETA
|
Final comment on the enhancement, update in travis config to compile in Ubuntu 14.04 🍻 |
|
What remains, just need to think of how to deal with 3 things:
One more thing, I like minimal interfaces in general, specially to the urdf model, but I'm thinking that, due to robot composability issues, it might be useful to have a flag to load or not the kuka plugin when you instantiate the model (default: true, of course), i.e. something like: Any ideas? |
…ack to original config file for the Stanford library.
|
Alright! I managed to use the Stanford library as well which is really nice done to do the controller switch as well. Some limits are to be increased as explained in the README Hopefully I will test it during the week, after that, I'll do the merge... |
|
@carlosjoserg: wow, I had completely overlooked this, I just found out about it now! 🙈 It sounds awesome, I'll get a look at it in depth. |
|
I think the major issue that remains is impedance mode. The cleanest solution that comes to my mind would unfortunately require a lot of work: if it were possible to create composite interfaces, then we could write an "ImpedanceJointInterface" which would lock the Position and Effort interfaces, and accept setPosition, setStiffness, setDamping and setEffort commands, redirecting setPosition to the PositionJointInterface's setCommand, setEffort to EffortJointInterface's setCommand, and taking care of damping and effort. This would have the advantage of fitting into the framework, and allow to clearly state why the position and effort interfaces are activated at once. What do you think about it? |
|
Yes, I know what you mean, I agree it would be nice to just say Impedance = Effort (joint) + Poisition (joint) + Position (stiffness) + Position (damping), however it might not be available in short times, and I'm not sure now how to tackle it. |
- Updated doc to explain how to use the base class. - Updated launch files to consider the new param "name" for nodes - A check in the transmission parsing, return false if no transmission is found - Updated the single_lwr example to reflect the new "name" param for nodes - Added some info prints - Added emergency stop for the kuka fri node
|
That was the last commit including naming fixes and added the e-stop for the kuka fri node. I don't think I will be able to test the Stanford interface #sigh, so, most likely I'll merge tomorrow morning, because changes start to accumulate. |
🔨 in progress...
The most important changes concern the [lwr_hw] package. The other ones are a consequence of those changes.
A good consequence is that this does not depend in the fork of ros control, since the lwr_hw_sim plugin knows the urdf naming convention and the number of joints, so it only suffices to have the name of the robot, and all joint names are known for that instance of the arm, and the transmissions are filtered out according to that value, see here.
As described in #19 (comment), the package uses the joint command interfaces as a (temporal) solution to switching control strategies. I think a more suitable way would be to develop either a ImpedanceJointInterface that expose the FRI command values and use a controller, or having Pos, Sitff and Damping as dynamic paramters of all controllers when switching to EffortJointInterface (hence JOINT_IMPEDANCE -> Strategy 30 in FRI) as the PID gains, or wait for something like a joint_mode_controller.
In the meantime, the drawback is that I couldn't find a way to have more than one controller to act in a commanding interfaces, so the old
joint_position_controllerandjoint_stiffness_controllercan't work simultaneously, since the first triggers the strategy 10 (in fact, the latter as well as it uses thePositionJointInterface, but it'll do nothing because those commands will not be written to the robot, real & sim)ATTENTION: I haven't tried the new single script because I'm not in the lab, but I will tomorrow and come back, but in the meantime I thought you might be reviewing the changes.
Comments are very well welcome !