F parameterise using local hardware interface param #110
Conversation
Update our master
…from the local namespace
|
Aren't these parameter lookups relative to the "current namespace" already? |
Most are, but not this one: The rest use
|
|
Then I would propose to rectify that, instead of adding a parameter. @fmauch: opinion? |
|
This handle is indeed not a global one but should be namespaced, as well. It lives on the same level as the controllers. If the driver is not namespaced, it is equivalent of the global namespace. Running the driver with a namespace yields From my point of view this is intended, but of course, we can discuss that. Adding a separate parameter for this also seems not the right way of doing this to me. |
This is indeed what I also had understood, and tried to convey with my not too articulate comment above. |
|
Hi, what we forgot to mention is that we are running a multiple arm configuration using CombinedRobotHw. Therefore both arms' RobotHw's are running in the same process. That's why we want to add the option to read the joint list from the local configuration of each RobotHw ( The new parameter defaults to the previous behaviour, so no one would notice any difference. This would ensure compatibility of this driver with CombinedRobotHw. |
|
I believe it'd be still nicer to just use Adding a parameter for this seems really undesirable. |
|
Using Currently you are expecting to read Would you then expect to change the way |
|
Then we would have to create a second yaml file containing only the joint names. We could load this into the Then, someone changing the robot's joint names will have to adapt both files (the |
|
That sounds good. |
|
I'm not entirely sure we need to |
But if we keep it in the same |
Yes, that would conflict with the combined_robot_hw use case. In that case the controller parameters are loaded in the top level, as there is only one controller manager. A certain controller can control resources belonging to different underlying RobotHw components. Another small difference in the combined use case is that |
|
@fmauch @gavanderhoorn I think this is pending a decision on your side. Could we resume the discussion? |
|
Hi @fmauch @gavanderhoorn , have either of you had any further thoughts on this? |
|
Sorry, I am still not fully convinced and also with #198 I don't want to rush anything there. Adding a parameter for this seems awkward to me. I'd rather raise the question whether it has to be the |
|
Closing, as #227 got merged. |
In it's current form, this driver won't allow multiple arms to exist in the same namespace. This pr fixes that by adding a parameter that allows the hardware_interface/joints parameter to be loaded from the drivers local namespace instead of the global one.