Open chapulina opened 6 years ago
A couple ideas I have for the port:
get_physics_properties
and set_physics_properties
services, which duplicate the functionality of the physics dynamic reconfigure in the current plugin. Replace with parameters for physics propertiesget_world_properties
. Replace with get_model_list
(perhaps under factory?). The other attributes are sim_time
(will come from clock) and rendering_enabled
(currently unused)spawn_sdf_model
and spawn_urdf_model
into spawn_model
. The plugin already checks the type internally, so might as well keep the interface agnostic for the userclear_body_wrench
/apply_body_wrench
to clear_link_wrench
/apply_link_wrench
to be more explicit with what this doesset_model_configuration
to set_model_joint_positions
Otherwise this splitting looks good to me! It makes sense to me to just put all the plugins (including the sensors, etc) into gazebo_ros
and not reintroduce gazebo_plugins
.
Started a migration page: ROS 2 Migration: gazebo_ros_api_plugin
Migration page for spawn / delete: ROS 2 Migration: Spawn and delete
I was thinking of dividing plugins into state
and properties
instead of by entity type (link
/ joint
/ model
/ world
). I'm also inclined to deprecate apply/clear_body_wrench
, since they duplicate gazebo_ros_force.
Thoughts, @j-rivero ?
I was thinking of dividing plugins into
state
andproperties
instead of by entity type (link
/joint
/model
/world
).
I can find more use cases for diving them into state
and properties
than by having them divided by type, so +1.
I'm also inclined to deprecate
apply/clear_body_wrench
, since they duplicate gazebo_ros_force.
I have no experience with both so can not comment anything against the removal.
I would be interested in having properties migrated to ros2, in a gazebo_ros_properties
plugin I guess. Please let me know if anyone is already doing this work, otherwise I can try to do it myself.
Update: followed at PR https://github.com/ros-simulation/gazebo_ros_pkgs/pull/868.
Regarding SetModelConfiguration service, is it already ported to ROS2?
If it isn't I might be able to do it, as I need it for my current project
The
gazebo_ros_api_plugin
is quite large and offers a lot of functionality all at once. While porting it to ROS 2, it would be nice to take the opportunity to also break that plugin into smaller ones so that:See the table below for a proposal of a split based on what kind of entity (model / link / joint / etc) an API targets.
I also considered a split which takes into account whether an API provides access to ground truth that wouldn't be available in the real world, or whether it allows altering simulation with a god's hand, i.e. in a way a robot wouldn't be able to in the real world. But after marking the API below with these 2 characteristics (to the best of my knowledge), it became clear to me that they really go hand-in-hand, and maybe the most useful approach would make each API disable-able within their plugins.
Another question I have is whether the new plugins should be in
gazebo_plugins
instead ofgazebo_ros
.gazebo_ros_force_system
gazebo_ros_force_system
gazebo_ros_properties
gazebo_ros_properties
gazebo_ros_force_system
gazebo_ros_force_system
gazebo_ros_state
gazebo_ros_properties
gazebo_ros_properties
gazebo_ros_state
gazebo_ros_state
gazebo_ros_state
gazebo_ros_state
gazebo_ros_state
joint
?gazebo_ros_properties
gazebo_ros_properties
get_model_list
gazebo_ros_properties
gazebo_ros_properties
gazebo_ros_properties
gazebo_ros_properties
gazebo_ros_factory
gazebo_ros_factory
gazebo_ros_factory
gazebo_ros_factory
gazebo_ros_init
gazebo_ros_init
gazebo_ros_init
gazebo_ros_init
gazebo_ros_init
gazebo_ros_init