It is surprisingly useful to have a purely kinematic simulation of a hardware interface in a combined_robot_hw. Using a custom adapter i already used it to allow for partially-simulated execution in a more complex combined_robot_hw setup, and it generally makes switching between real hardware and simulation in such projects much easier. I would however prefer this to be an upstream feature of ros_control_boilerplate (and am happy to provide a PR for it) for the following reasons:
- It would demonstrate how to properly write and export a hw interface using
pluginlib
- Adding a launch file to
rrbot_control could demonstrate how to use a combined_robot_hw
- It can be quite handy to use this as a placeholder when developing bigger
combined_robot_hw setups
Unfortunately i don't think simply changing SimHWInterface (or GenericHWInterface) would be possible without quite some restructuring, as pluginlib requires a parameterless constructor. Thus i would create an extra adapter class deriving from hardware_interface::RobotHW which would hold a SimHWInterface as a member and delay it's construction until init(), simply delegating all relevant calls from there on.
The way i see it the required steps for this are:
I'm happy to hear about opinions, otherwise i'd start implementing this in the next days.
It is surprisingly useful to have a purely kinematic simulation of a hardware interface in a
combined_robot_hw. Using a custom adapter i already used it to allow for partially-simulated execution in a more complexcombined_robot_hwsetup, and it generally makes switching between real hardware and simulation in such projects much easier. I would however prefer this to be an upstream feature ofros_control_boilerplate(and am happy to provide a PR for it) for the following reasons:pluginlibrrbot_controlcould demonstrate how to use acombined_robot_hwcombined_robot_hwsetupsUnfortunately i don't think simply changing
SimHWInterface(orGenericHWInterface) would be possible without quite some restructuring, aspluginlibrequires a parameterless constructor. Thus i would create an extra adapter class deriving fromhardware_interface::RobotHWwhich would hold aSimHWInterfaceas a member and delay it's construction untilinit(), simply delegating all relevant calls from there on.The way i see it the required steps for this are:
CombinedHWAdapterclassros_control_boilerplate/SimHWInterfacerrbot_control. Unfortunately running acombined_robot_hwfrom aGenericHWControlLoopdoesn't seem too nice.rrbot_controlREADME.mdI'm happy to hear about opinions, otherwise i'd start implementing this in the next days.