You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Create CombinedHWAdapter class
Export interface correctly as ros_control_boilerplate/SimHWInterface
Add node src to rrbot_control. Unfortunately running a combined_robot_hw from a GenericHWControlLoop doesn't seem too nice.
Add sample launch files to rrbot_control
Add short description to README.md
I'm happy to hear about opinions, otherwise i'd start implementing this in the next days.
The text was updated successfully, but these errors were encountered:
I have just stumbled over this issue after opening PR #42 which is intended to bring support for combined_robot_hw.
Definitely agree that an adapter could be a good solution. More concerns and ideas can be found in the PR, I don't want to cross-post too much.
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_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 ofros_control_boilerplate
(and am happy to provide a PR for it) for the following reasons:pluginlib
rrbot_control
could demonstrate how to use acombined_robot_hw
combined_robot_hw
setupsUnfortunately i don't think simply changing
SimHWInterface
(orGenericHWInterface
) would be possible without quite some restructuring, aspluginlib
requires a parameterless constructor. Thus i would create an extra adapter class deriving fromhardware_interface::RobotHW
which would hold aSimHWInterface
as 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:
CombinedHWAdapter
classros_control_boilerplate/SimHWInterface
rrbot_control
. Unfortunately running acombined_robot_hw
from aGenericHWControlLoop
doesn't seem too nice.rrbot_control
README.md
I'm happy to hear about opinions, otherwise i'd start implementing this in the next days.
The text was updated successfully, but these errors were encountered: