|
1 | | -************************************************** |
2 | | -Contribute |
3 | | -************************************************** |
4 | | -All kinds of contributions are welcome, from raising issues with the software to software commits and pull requests |
5 | | -(PRs). Please see below for guidance and suggestions on how and where to contribute. |
6 | | - |
7 | | - |
8 | | -Issues & Improvement Suggestions |
9 | | -================================================== |
10 | | -Please take a look at the issues board on the Github page to see if someone already has raised a similar issue or |
11 | | -suggestion. |
12 | | - |
13 | | - |
14 | | -Commits & Pull Requests |
15 | | -================================================== |
16 | | -Pull requests (PRs) are very much welcome! Please follow the |
17 | | -`feature branch workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow>`_ when |
18 | | -submitting your pull request. |
19 | | - |
20 | | -* Take a look at the known issues or create one yourself for your PR before you start working so that others will also be aware of your pending work. You can also use it as an opportunity to get feedback on your idea before you commit to it further. |
21 | | - |
22 | | -* If your PR fixes or implements an issue, please link the issue in your pull request |
23 | | - |
24 | | -* In your commit messages, please describe not only *what* you have done, but *why* you have done it. This helps the reviewer understand your thought process faster. |
25 | | - |
26 | | - |
27 | | -Development Guidance |
28 | | -================================================== |
29 | | -If you are interested in contributing to GISNav as a developer, you may consider the guidance provided in this section. |
30 | | -These bullet points should be taken more as suggestions on where to find "low-hanging fruit" rather than as |
31 | | -recommendations on what to do. |
32 | | - |
33 | | -.. _Project Intention: |
34 | | - |
35 | | -Project Intention |
36 | | --------------------------------------------------- |
37 | | -GISNav demonstrates a map-based visual global positioning for airborne drones that complements and improves on |
38 | | -existing sensor fusion systems. It improves both local and global position and attitude estimate accuracy, and provides |
39 | | -backup global positioning for GNSS-denied flight. |
40 | | - |
41 | | -.. _Guiding Principles: |
42 | | - |
43 | | -Guiding Principles |
44 | | --------------------------------------------------- |
45 | | -The following principles have been used as design guidance when developing GISNav and that you can use to evaluate |
46 | | -whether a new feature could fit in: |
47 | | - |
48 | | -* Complement and improve but do not replace |
49 | | - |
50 | | - A natural application of map-based visual global positioning is complementing (but not replacing) GPS (GNSS) as |
51 | | - global position provider. |
52 | | - |
53 | | -* Maintainability and well-defined interfaces over premature optimization |
54 | | - |
55 | | - Open source drone autopilot software as well as deep learning based image matching are under active development. |
56 | | - Autonomous drone delivery services and other use scenarios are not well-developed. |
57 | | - |
58 | | -* Build on proven open technology stack |
59 | | - |
60 | | - The future-proof approach is to support open hardware platforms and FOSS software with existing wide adoption |
61 | | - |
62 | | -* Target future `commercial` use cases |
63 | | - |
64 | | - Future autonomous drone services will require precise and reliable navigation, especially within an urban or |
65 | | - semi-urban environment. Vision is a key enabler when a drone needs to e.g. autonomously land on a small back yard. |
66 | | - |
67 | | - |
68 | | -.. _Constraints: |
69 | | - |
70 | | -Constraints |
71 | | --------------------------------------------------- |
72 | | -The `Guiding Principles`_ impose constraints on GISNav, namely: |
73 | | - |
74 | | -* Favorable operating terrain for map-based visual matching is strongly featured urban and semi-urban areas and traffic corridors (roads or similar infrastructure), not featureless natural terrain |
75 | | -* Drone or UAV size, flight altitude or velocity constrained only to such degree that allows commercial GNSS receivers to work |
76 | | -* Emphasis on good flight conditions is a reasonable assumption for most commercial use cases |
77 | | -* Open-source software (and hardware) with permissive licenses only |
78 | | -* ROS is baked in |
79 | | - |
80 | | -Development Focus |
81 | | --------------------------------------------------- |
82 | | -Taking the `Constraints`_ into account, development focus could for example be in: |
83 | | - |
84 | | -* Easier adoption |
85 | | - |
86 | | - * Improving documentation |
87 | | - |
88 | | - * Developing pre-made Docker environments to speed up initial setup |
89 | | - |
90 | | - * Pre-made configurations for popular hardware platforms or autopilot technology stacks |
91 | | - |
92 | | - * Abstracting away current configuration quirks |
93 | | - |
94 | | - * PX4 could be complemented by other autopilot options such as Ardupilot through Mavlink compatible interface |
95 | | - |
96 | | -* Improved estimation accuracy, reliability or performance |
97 | | - |
98 | | - * Newer, better pose estimation algorithms or neural networks |
99 | | - |
100 | | - * Using elevation maps (DEMs) or other data from the underlying GIS system to complement orthoimagery |
101 | | - |
102 | | - For example, a DEM could be used to plug in the z-coordinates of the object points for the |
103 | | - :func:`cv2.solvePnPRansac` call that is currently used under the hood of :class:`.KeypointPoseEstimator`. |
104 | | - |
105 | | - * Support for stereo or other kinds of cameras |
106 | | - |
107 | | -* More testing |
108 | | - |
109 | | - * Better test coverage |
110 | | - |
111 | | - * SITL testing workbench development |
112 | | - |
113 | | - Have a way to fly premade flight plans in SITL and automatically parse the flight logs or import them into e.g. |
114 | | - a Jupyter notebook for further analysis. |
115 | | - |
116 | | -* Better customization |
117 | | - |
118 | | - * Have a way to re-initialize the dynamically loaded classes (:class:`.PoseEstimator`) at runtime to make it possible to swap in specialized neural nets for specific terrain via a ROS service |
119 | | - |
120 | | -* Better maintainability |
121 | | - |
122 | | - * Move to a more distributed 'ROS native' system in the long term where current modules that are managed by the :class:`.BaseNode` are spun as independent ROS nodes if possible. |
| 1 | +.. include:: ../../CONTRIBUTING.md |
| 2 | + :parser: myst_parser.sphinx_ |
0 commit comments