Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ros_gz_sim::create use ROS parameters #459

Closed
mjcarroll opened this issue Nov 9, 2023 · 6 comments · Fixed by #475
Closed

Make ros_gz_sim::create use ROS parameters #459

mjcarroll opened this issue Nov 9, 2023 · 6 comments · Fixed by #475
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@mjcarroll
Copy link
Collaborator

Currently, the ros_gz_sim::create node uses gflags to configure where and how models are loaded.

For maximum compatibility with ROS, I think it makes sense to switch the gflags arguments to use rclcpp::Parameters.

@mjcarroll mjcarroll added the enhancement New feature or request label Nov 9, 2023
@mjcarroll mjcarroll added the good first issue Good for newcomers label Nov 9, 2023
@mjcarroll mjcarroll moved this from Inbox to To do in Core development Nov 10, 2023
@yaswanth1701
Copy link

So, one should add XYZ and RPY as rosparams right? or all the gflag arguments ?

@ahcorde
Copy link
Collaborator

ahcorde commented Nov 14, 2023

Hi @yaswanth1701, all the gflags arguments

@Ayush1285
Copy link
Contributor

Ayush1285 commented Nov 14, 2023

There is a gflag argument 'param', which allows us to pass any ros parameters which is not declared in the create.cpp file. So, now that we are converting gflag arguments to Parameters itself, we will lose this functionality, right?

@Ayush1285
Copy link
Contributor

@mjcarroll any comments?

@mjcarroll
Copy link
Collaborator Author

@Ayush1285 In my opinion, since this is currently primarily used from ROS launch files, it would make sense to port all available parameters to be ROS parameters. In the case that no ROS parameter arguments are available, we can revert to the gflags behavior. I think preserving behavior is also important for the existing launch files that are out there.

An alternative to the gflags "fallback" parsing is to provide two separate executables, one exclusively gflags and one exclusively ROS paramaters, but I think that would result in a good bit of duplication. I'll leave that up to whoever implements it to see which way works better.

I'm envisioning getting us positioned to take advantage of custom launch actions down the road, so the more "native" ROS support we have, the better.

@Ayush1285
Copy link
Contributor

I'm thinking about implementing this. I'll go with the first behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
Archived in project
4 participants