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

Package for Distribution #1

Open
bradshjg opened this issue Feb 7, 2019 · 3 comments
Open

Package for Distribution #1

bradshjg opened this issue Feb 7, 2019 · 3 comments

Comments

@bradshjg
Copy link

bradshjg commented Feb 7, 2019

This looks super interesting and I don't understand much of it, but let me know if you'd like any help packaging it for distribution. I do understand that 😄.

@magicbycalvin
Copy link
Member

That is actually one of the things I am not great at. If you'd like to help with that, I would really appreciate it! Let me know if there is any information you need.

@bradshjg
Copy link
Author

bradshjg commented Feb 9, 2019

I'd be happy to help, but it'll definitely involve work on your part 😄 (mostly style related)

Right now it's not clear from the code what the public interface of this code should be (e.g. I'd be surprised if appendToDataFrame in the iterateSingleVehicle_MP module should be public). Also I can't tell if the gjk package would be part a distribution or not, it isn't used in any other modules. I can live with the non-standard naming conventions, but it would be great to at least consider moving to pep8.

I'll also need help to modify the given tests so that the package can be properly tested. It looks like they print out stuff that you check by hand, but I'd need them to make assertions to be testable.

I don't actually know about the intent of this codebase to know if it would be helpful to others, but I'd be happy to help package it (with the above caveats).

@magicbycalvin
Copy link
Member

I am more than happy to put in the effort to make this happen. I like to have my own test code when working with and modifying this library. It is clear that it should not be in the root directory, but would it need to be completely removed or should I create a tests folder? Pretty much everything other than the bezier.py and optimization.py files are meant for testing or examples.

Regarding the proper way to organize this project, the Bezier library should be standalone but it is specifically made for trajectories (it should work just fine for someone who may want to use it for drawing graphics or something else similar but no tests have been performed for those cases). The optimization.py file is meant to be a way to bridge the Bezier library with the desired use of optimal trajectory generation.

I do plan on utilizing the gjk code for certain uses in the future. The gjk code will most likely end up being called from the optimization.py file.

I can certainly move to PEP8. I have been following PEP8 for simple context such as whitespace rules but I am not familiar with the naming conventions. I'll take a look at it, but could you give me an example or two of the naming convention changes you'd like?

I've never written built in test functions. How would you recommend I move forward with that? My best guess is to create a function or a module that tests everything and uses a mix of try and assert statements.

In its most basic form, the goal of this package is to offer users a computationally efficient way to generate optimal trajectories for whatever autonomous vehicle they would like.

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