Instructions for making effective contributions to our projects.
To drive the rapid growth of reliable autonomous aircraft with a focus on research and commercial applications with the highest potential to improve the environment, improve access to affordable mobility, and expand access to public services and goods. We will drive this rapid growth by developing flight systems with a focus on data quality, reliability, and robustness at a revolutionary price.
We welcome code contributions, bug reports, suggested enhancements, and assistance with documentation or testing. Use the repo's issue tracking system to identify potential bugs and suggested enhancements. Issue pull requests for making code contributions and assisting with documentation. If you have an idea to contribute and are unsure of the best approach, please contact us at support@bolderflight.com to discuss.
When issuing a bug report, be specific about:
- The microprocessor used or Linux environment
- Steps to reproduce the bug
- Include code
Be sure to check out our Build Tools Guide for setting up your development environment.
Follow the Google C++ Style Guide. Any parameter or variable names, which contain unit specific data should be appended with an underscore and the units (i.e. accel_z_mps2). For derived units, use p to indicate "per" and append exponents. So, m/s/s would be mps2 and kg/m^3 would be kgpm3. If a common abbreviation already exists for the unit, use that instead (i.e. psi instead of lbpin2).
Prefer to use float instead of double unless there is a specific and demonstrated need for the additional resolution. Specify integer size in all cases where a certain number of bytes are expected (i.e. uint16_t where 2 bytes is assumed); otherwise use std::size_t or a signed int. Typically, we are not concerned with program size and int works well for integers and index values. If a certain number of bytes are needed they need to be called out directly since different compilers and platforms can change the number of bytes stored in a short, for instance. Do not assume that using unsigned int will prevent a negative input, instead use signed int and check for negative values.
Linting tests check for conformance to the style guide - analyzing the code for potential errors and leading to better readibility. cpplint should be used to conduct linting tests with verbosity level 0. cpplint is installed in the development environment.
If you use external sources, ensure they are licensed MIT, BSD, or a similarly permissive license. We would like to limit the amount of LGPL code and need to avoid GPL and unlicensed code.
If you would like to use external sources with licenses other than MIT or BSD, contact support@bolderflight.com to discuss options.
Develop examples demonstrating your code's functionality and include expected outputs in comments. These examples provide an easy access point to learning your code and ensuring that it installed correctly.
Tags are used to specify release version numbers in semver formatting. These tags are important because repositories using your code as a dependency will pull, build, and validate against a specific version, rather than continuously needing to manage code updates following HEAD.