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

Encapsulate Atlas specific API and types #30

Closed
3 of 4 tasks
mauricefallon opened this issue Jan 27, 2016 · 4 comments
Closed
3 of 4 tasks

Encapsulate Atlas specific API and types #30

mauricefallon opened this issue Jan 27, 2016 · 4 comments

Comments

@mauricefallon
Copy link
Contributor

I intend to gather up all Atlas specific code into a single place such that:

  • software builds without drc_atlas lcm types. There are 30 of these currently.
  • software builds without BDI proprietary library
  • this will also simplify the dependency tree
  • move us a couple of steps closer to full open source (i.e. checkout and build)

The steps:

  • Fish out the 30 LCM types into a pod
  • Move all dependent code into a single place: state-sync, bdi-footstep-translator.
  • Fix some minor dependencies on these types e.g. signal scope and the fall detector
  • Gather the dependent code and types with the driver (and disable by default)

Then during Valkyrie development, we will avoid the intermingling of our software and the manufacturer's API and proprietary files.

@wxmerkt
Copy link
Member

wxmerkt commented Jan 27, 2016

I've worked towards this direction today and made sure oh-distro compiles without access to private externals. To this end, dependent modules are automatically turned off so that make can run through cleanly, cf. https://github.com/oh-dev/oh-distro/tree/wolfgang-make-public-compilable.

I am currently still running tests on it before opening a PR. It does not include yet, however, the separation of LCM types and a cleaner refactoring.

[Edited to make clearer]

@wxmerkt
Copy link
Member

wxmerkt commented Jan 27, 2016

[If you're reading from email, please disregard my earlier comment - it is updated online on GitHub; apologies for the extra email noise]

@mauricefallon
Copy link
Contributor Author

The list of issues from that branch is useful. Judging from it, only a small number of issues needs be resolved.

Lets fix the Atlas dependency first.

This was referenced Jan 28, 2016
@wxmerkt wxmerkt mentioned this issue Jan 29, 2016
4 tasks
@mauricefallon
Copy link
Contributor Author

This wasn't fully complete as when the Atlas was used the control directory was dependent on atlas_collections, so had to be reverted. will explore again in future

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