Issues with defining custom adapters

[dcconner]

I tried developing a custom controller that modified the inner workings of the controls while preserving the joint_trajectory_controller interface and our specific hardware interface by creating a new interface adapter and a new controller implementation that included this adapater header in its definition file.

I ran into 2 issues:

1. Duplicate function definitions were created by the joint trajectory controller implmentation. I fixed this by moving the non-templated functions from the impl.h file to the joint_trajectory_controller.cpp file in our fork. Code change is here:
   team-vigir@0a87546

To me this change should be generally applicable, and may be worthy of a pull request.

2. After this fix, the proper adapter was not being loaded. I double checked the plugin xml definitions and even added debug print of construction in controller_manager here:
   team-vigir/ros_control@3101cbd

The new controller type name is being requested, but for some reason the factory is creating an instance of the original controller type. We got around this under time pressure by just hacking both controllers, but we need to figure out what is wrong because we want to create different variations on a controller with same trajectory interface and hardware interface.

Before I spent too much time poking around the bowels of the controller manager, I wanted to check to see if others had seen this issue before, or had a suggestion as to the problem. Again, the proper name is requested and I don't get an error, just the wrong type is instantiated.

Unfortunately, this specific code is in a robot specific library, so it will take work to create a test case with just the ros_controllers package.

[adolfo-rt]

You don't say much how the new controller is being built. Is it a separate package with a different name?. It sounds like something is not right in how you expose the new plugin to ROS. This typically means:

• Export your plugin in your source file using the pluginlib macros.
• Creating the plugin XML description file.
• Registering the plugin to the ROS package system (package.xml)

This is well documented here.

If extending an existing package, i.e., adding more plugins to an existing library, make sure that there is no system-installed version of the original package that is being picked up instead.