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

Move ZED config parameters to a config file #78

Open
wraftus opened this issue Mar 24, 2019 · 3 comments
Open

Move ZED config parameters to a config file #78

wraftus opened this issue Mar 24, 2019 · 3 comments

Comments

@wraftus
Copy link
Contributor

wraftus commented Mar 24, 2019

🚀 Feature Request

To make the zeds.launch file less cluttered and to make changing parameters easier in the future, we want to have a yaml file describe the params instead of within the launch file.

@wmmc88
Copy link
Member

wmmc88 commented Mar 24, 2019

As discussed here, i think we should have the yml cfg serve as defaults, but still have cl args for the camera properties. (all cameras would have the same resolution, framerate, etc)

@wmmc88
Copy link
Member

wmmc88 commented Mar 24, 2019

this would allow for on-the-fly tuning of those params without needing to edit files between launches. The preferable alternative would be to fork the zed ros wrapper and add a dynamic reconfigure server (and pr it maybe lol).

@matthew-reynolds
Copy link
Member

^ I would argue that the command-line args don't add on-the-fly tuning of those parameters, as you mentioned the only true on-the-fly would be via dynamic reconfigure.

I see no advantage to command-line over editing the files. Editing the files doesn't really take longer and is clearer as the number of parameters gets large (See ros_control's use of yaml). However, if we only have a small number of command-line arguments, there isn't a significant disadvantage either, as long as you remember to commit the new "defaults" you chose.

The main reason I prefer yaml here over command-line is perhaps just the way I'm looking at these options. I see them as static robot configuration parameters, once they're determined they will be (relatively) set in stone. I like the idea of treating them the same as we treat urdfs, the ros_control controller config files, etc.

As I said in the other chat though, if we are enforcing that all the cameras use the same frame rate and resolution (Which seems super restrictive to me but you guys know a lot more about it than I do), then there is very little cost to adding the launchfile arguments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants