Open canalteks opened 7 years ago
I am having similar issue here. I have my own RobotHW with JointStateInterface. It'll throw an error "Failed to load transmission 'xxxx'. It contains no valid hardware interface. I can control the motors fine but I will not be able to receive any feedback. The moment I register a JointStateInterface with my RobotHW class, it'll throw this error. But I need it in order to control the group of motors through joint trajectory controller.
But the unit test cases inside ros_control has exactly the same code. Has the developer not run into the same problem with registering JointStateInterface with RobotHW?
It took me a while to understand the problem, but I can confim @canalteks's code analysis.
Another problem exists for the other interface types, if you try to register them after running loader.load
.
As a workaround, instead of registering the interfaces yourself, you could use the interfaces from loader.getData()->joint_interface
I too have found my way to this bug. Gotta give @canalteks a hand in actually tracking down the problem. I just started getting very strange plugin load errors that gave me no indication of what the actual problem was.
Can we afford to eliminate the local joint state interface as the (this code) section of point 2 suggests? This would be a slightly breaking change but I think it could still fly for melodic.
any updates for this issue? I got a same error in melodic. How should I avoid this error?
@ompugao the way I get around it is I load all transmissions containing my custom hardware interfaces before all others. Bit hacky, but it works for me
I've been thinking about this recently working on similar stuff and I am opting for point 2. What do you guys think of such a change?
Dear developers,
I found that transmission_interface::TransmissionInterfaceLoader will throw an exception in loading new hardware_interface/Position,Velocity,EffortJointInterfaces from URDF::transmission tags.
This problem only occurs when the users used their own RobotHw with JointStateInterface.
It's because that
Then, the inconsistency of references between two JointStateInterfaces makes this problem.
I'll suggest following approaches,
yours sincerely.