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

Split repo into STRANDS vs scitos generic #166

Open
hawesie opened this issue Aug 4, 2021 · 5 comments
Open

Split repo into STRANDS vs scitos generic #166

hawesie opened this issue Aug 4, 2021 · 5 comments

Comments

@hawesie
Copy link
Member

hawesie commented Aug 4, 2021

I am in the process of setting up parts of the scitos stack on a scitos X3. This doesn't have all the things the STRANDS Scitos A5/G5 has, therefore I only need some of the packages from this repo. This led me to consider that we should split this into scitos_apps that work for all scitos robots, and strands_scitos_apps that are specific to the STRANDS robots. I think the generic parts would be at least:

scitos_cmd_vel_mux
scitos_dashboard
scitos_teleop

What do our users think? (probably just @marc-hanheide)

@marc-hanheide
Copy link
Member

Thanks @hawesie did you consider moving those packages into scitos_drivers repo rather than creating yet another repo? To me, that would probably make most sense.

@hawesie
Copy link
Member Author

hawesie commented Aug 5, 2021

That's a fantastic idea. Shall I go ahead and do that?

@marc-hanheide
Copy link
Member

Please do! Remember to ideally transfer with git history and updating the version. Indeed, the new version of all packages in the scitos_drivers must be the larger of the two sets of packages going in there, to ensure the update processes for packages all work. Bit annoying, but shouldn’t be a problem.

1 similar comment
@marc-hanheide
Copy link
Member

Please do! Remember to ideally transfer with git history and updating the version. Indeed, the new version of all packages in the scitos_drivers must be the larger of the two sets of packages going in there, to ensure the update processes for packages all work. Bit annoying, but shouldn’t be a problem.

@hawesie
Copy link
Member Author

hawesie commented Aug 5, 2021

Gotcha.

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

No branches or pull requests

2 participants