├── .gitignore ├── .nojekyll ├── .travis.yml ├── CNAME ├── Jenkinsfile ├── LANGS.md ├── LICENSE ├── README.md ├── assets ├── getting_started │ ├── centos │ │ ├── centos_installation.png │ │ ├── centos_sw_selection.png │ │ └── qt_setup.png │ ├── qt_creator_build_qgc.png │ ├── qt_creator_select_components.jpg │ ├── qt_project_installer.png │ └── visual_studio_select_features.png ├── site │ └── logo_qgc_rgb_horizontal.png ├── slack.svg └── tools │ ├── mocklink_connected.jpg │ └── mocklink_waiting_for_connection.jpg ├── book.json ├── crowdin.yml ├── en ├── README.md ├── ReleaseBranchingProcess.md ├── SUMMARY.md ├── classes │ └── README.md ├── command_line_options.md ├── communication_flow.md ├── contribute │ ├── README.md │ ├── coding_style.md │ ├── dev_call.md │ ├── licences.md │ ├── pull_requests.md │ └── unit_tests.md ├── custom_build │ ├── CreateRepos.md │ ├── FirstRunPrompts.md │ ├── FlyView.md │ ├── Plugins.md │ ├── ReleaseBranchingProcess.md │ ├── ResourceOverride.md │ ├── Toolbar.md │ ├── custom_build.md │ ├── customization.md │ └── mavlink.md ├── fact_system.md ├── file_formats │ ├── README.md │ ├── mavlink.md │ ├── parameters.md │ └── plan.md ├── firmware_plugin.md ├── getting_started │ ├── CentOS.md │ ├── README.md │ └── container.md ├── plan │ └── MissionCommandTree.md ├── tools │ ├── README.md │ └── mock_link.md ├── ui_design │ ├── README.md │ ├── controls.md │ ├── font_palette.md │ └── multi_device_pattern.md └── views │ ├── README.md │ ├── fly.md │ ├── plan.md │ ├── settings.md │ └── setup.md ├── favicon.ico └── zh ├── GitBranching.md ├── README.md ├── ReleaseBranchingProcess.md ├── SUMMARY.md ├── classes └── README.md ├── command_line_options.md ├── communication_flow.md ├── contribute ├── README.md ├── coding_style.md ├── dev_call.md ├── licences.md ├── pull_requests.md └── unit_tests.md ├── custom_build ├── CreateRepos.md ├── FirstRunPrompts.md ├── FlyView.md ├── GitBranching.md ├── Plugins.md ├── ReleaseBranchingProcess.md ├── ResourceOverride.md ├── Toolbar.md ├── custom_build.md ├── customization.md ├── mavlink.md └── upstream_merge.md ├── fact_system.md ├── file_formats ├── README.md ├── mavlink.md ├── parameters.md └── plan.md ├── firmware_plugin.md ├── getting_started ├── CentOS.md ├── README.md └── container.md ├── plan └── MissionCommandTree.md ├── tools ├── README.md └── mock_link.md ├── ui_design ├── README.md ├── controls.md ├── font_palette.md └── multi_device_pattern.md └── views ├── README.md ├── fly.md ├── plan.md ├── settings.md └── setup.md /.gitignore: -------------------------------------------------------------------------------- 1 | ## Dependency directory 2 | ## Commenting this out is preferred by some people, see 3 | ## https://docs.npmjs.com/misc/faq#should-i-check-my-node_modules-folder-into-git 4 | node_modules 5 | 6 | # Book build output 7 | _book 8 | 9 | # eBook build output 10 | *.epub 11 | *.mobi 12 | *.pdf 13 | 14 | -------------------------------------------------------------------------------- /.nojekyll: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/.nojekyll -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: ruby 2 | rvm: 3 | - 2.2.2 4 | 5 | addons: 6 | apt: 7 | packages: 8 | - libcurl4-openssl-dev # required to avoid SSL errors 9 | 10 | install: 11 | - npm install gitbook-cli -g 12 | - gitbook install 13 | - gitbook build 14 | - gem install html-proofer 15 | 16 | script: 17 | 18 | - htmlproofer ./_book --empty-alt-ignore true --check-external-hash true --http-status-ignore 503 --url-ignore 'https://img.shields.io/badge/discuss-dev-ff69b4.svg,https://img.shields.io/github/release/mavlink/QGroundControl.svg' 19 | 20 | env: 21 | global: 22 | - NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer 23 | 24 | 25 | ## Allow links to fail any time and be displayed as warnings. 26 | matrix: 27 | allow_failures: 28 | - rvm: 2.2.2 29 | 30 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | dev.qgroundcontrol.com 2 | -------------------------------------------------------------------------------- /Jenkinsfile: -------------------------------------------------------------------------------- 1 | pipeline { 2 | agent { 3 | docker { 4 | image 'px4io/px4-docs:2020-01-05' 5 | } 6 | } 7 | stages { 8 | 9 | stage('Build') { 10 | environment { 11 | HOME = "${WORKSPACE}" 12 | } 13 | 14 | steps { 15 | sh('export') 16 | checkout(scm) 17 | sh('gitbook install') 18 | sh('gitbook build') 19 | stash(includes: '_book/', name: 'gitbook') 20 | // publish html 21 | publishHTML(target: [ 22 | reportTitles: 'QGC Dev Guide', 23 | allowMissing: false, 24 | alwaysLinkToLastBuild: true, 25 | keepAll: true, 26 | reportDir: '_book', 27 | reportFiles: '*', 28 | reportName: 'QGC Dev Guide' 29 | ]) 30 | } 31 | 32 | } // Build 33 | 34 | stage('Deploy') { 35 | environment { 36 | GIT_AUTHOR_EMAIL = "bot@px4.io" 37 | GIT_AUTHOR_NAME = "PX4BuildBot" 38 | GIT_COMMITTER_EMAIL = "bot@px4.io" 39 | GIT_COMMITTER_NAME = "PX4BuildBot" 40 | } 41 | 42 | steps { 43 | sh('export') 44 | unstash('gitbook') 45 | withCredentials([usernamePassword(credentialsId: 'px4buildbot_github_personal_token', passwordVariable: 'GIT_PASS', usernameVariable: 'GIT_USER')]) { 46 | sh('git clone https://${GIT_USER}:${GIT_PASS}@github.com/mavlink/dev.qgroundcontrol.com.git') 47 | sh('rm -rf dev.qgroundcontrol.com/${BRANCH_NAME}') 48 | sh('mkdir -p dev.qgroundcontrol.com/${BRANCH_NAME}') 49 | sh('cp -r _book/* dev.qgroundcontrol.com/${BRANCH_NAME}/') 50 | sh('cd dev.qgroundcontrol.com; git add ${BRANCH_NAME}; git commit -a -m "gitbook build update `date`"') 51 | //sh('cp -r _book/* dev.qgroundcontrol.com/') 52 | //sh('cd dev.qgroundcontrol.com; git add .; git commit -a -m "gitbook build update `date`"') 53 | sh('cd dev.qgroundcontrol.com; git push origin master') 54 | 55 | } 56 | } 57 | post { 58 | always { 59 | sh('rm -rf dev.qgroundcontrol.com') 60 | } 61 | } 62 | when { 63 | anyOf { 64 | branch "master" 65 | branch "v3.*" 66 | branch "v4.*" 67 | branch "v5.*" 68 | branch "pr-jenkins" 69 | } 70 | } 71 | 72 | } // Deploy 73 | } // stages 74 | 75 | options { 76 | buildDiscarder(logRotator(numToKeepStr: '10', artifactDaysToKeepStr: '30')) 77 | skipDefaultCheckout() 78 | timeout(time: 60, unit: 'MINUTES') 79 | } 80 | 81 | } 82 | -------------------------------------------------------------------------------- /LANGS.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/LANGS.md -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | CC BY 4.0 2 | 3 | Licence: https://creativecommons.org/licenses/by/4.0/legalcode 4 | Human-readable format: https://creativecommons.org/licenses/by/4.0/ 5 | 6 | Creative Commons Attribution 4.0 International Public License 7 | ============================================================== 8 | 9 | Creative Commons Attribution 4.0 International Public License 10 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 11 | 12 | Section 1 – Definitions. 13 | 14 | a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 15 | b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 16 | c. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 17 | d. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 18 | e. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 19 | f. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 20 | g. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 21 | h. Licensor means the individual(s) or entity(ies) granting rights under this Public License. 22 | i. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 23 | j. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 24 | k. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 25 | 26 | Section 2 – Scope. 27 | 28 | a. License grant. 29 | 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 30 | A. reproduce and Share the Licensed Material, in whole or in part; and 31 | B. produce, reproduce, and Share Adapted Material. 32 | 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 33 | 3. Term. The term of this Public License is specified in Section 6(a). 34 | 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 35 | 5. Downstream recipients. 36 | A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 37 | B. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 38 | 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 39 | b. Other rights. 40 | 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 41 | 2. Patent and trademark rights are not licensed under this Public License. 42 | 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 43 | 44 | 45 | Section 3 – License Conditions. 46 | 47 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 48 | a. Attribution. 49 | 1. If You Share the Licensed Material (including in modified form), You must: 50 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 51 | i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 52 | ii. a copyright notice; 53 | iii. a notice that refers to this Public License; 54 | iv. a notice that refers to the disclaimer of warranties; 55 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 56 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 57 | C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 58 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 59 | 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 60 | 4. If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License. 61 | 62 | 63 | Section 4 – Sui Generis Database Rights. 64 | 65 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 66 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 67 | b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and 68 | c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 69 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 70 | 71 | 72 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 73 | 74 | a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. 75 | b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. 76 | c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 77 | 78 | 79 | Section 6 – Term and Termination. 80 | 81 | a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 82 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 83 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 84 | 2. upon express reinstatement by the Licensor. 85 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 86 | c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 87 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 88 | 89 | 90 | Section 7 – Other Terms and Conditions. 91 | 92 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 93 | b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 94 | 95 | 96 | Section 8 – Interpretation. 97 | 98 | a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 99 | b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 100 | c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 101 | d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 102 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # QGroundControl Dev Guide - ARCHIVED 2 | 3 | > **Note** BOTH GUIDE AND DEV SOURCES HAVE MOVED TO QGroundControl Repo: https://github.com/mavlink/qgroundcontrol/tree/master/docs/en 4 | 5 | This repo will be archived shortly. 6 | -------------------------------------------------------------------------------- /assets/getting_started/centos/centos_installation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/getting_started/centos/centos_installation.png -------------------------------------------------------------------------------- /assets/getting_started/centos/centos_sw_selection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/getting_started/centos/centos_sw_selection.png -------------------------------------------------------------------------------- /assets/getting_started/centos/qt_setup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/getting_started/centos/qt_setup.png -------------------------------------------------------------------------------- /assets/getting_started/qt_creator_build_qgc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/getting_started/qt_creator_build_qgc.png -------------------------------------------------------------------------------- /assets/getting_started/qt_creator_select_components.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/getting_started/qt_creator_select_components.jpg -------------------------------------------------------------------------------- /assets/getting_started/qt_project_installer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/getting_started/qt_project_installer.png -------------------------------------------------------------------------------- /assets/getting_started/visual_studio_select_features.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/getting_started/visual_studio_select_features.png -------------------------------------------------------------------------------- /assets/site/logo_qgc_rgb_horizontal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/site/logo_qgc_rgb_horizontal.png -------------------------------------------------------------------------------- /assets/slack.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | slack 19 | slack 20 | Join us! 21 | Join us! 22 | 23 | 24 | 25 | -------------------------------------------------------------------------------- /assets/tools/mocklink_connected.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/tools/mocklink_connected.jpg -------------------------------------------------------------------------------- /assets/tools/mocklink_waiting_for_connection.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/assets/tools/mocklink_waiting_for_connection.jpg -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "gitbook": ">= 3.2.2", 3 | "title": "QGroundControl Developer Guide", 4 | "variables": { 5 | "logo": "./assets/site/logo_qgc_rgb_horizontal.png", 6 | "qgc_version": "master", 7 | "qt_version": "5.15.2" 8 | }, 9 | "plugins": [ 10 | "youtube", 11 | "richquotes@git+https://github.com/Dronecode/gitbook-plugin-richquotes.git", 12 | "anchors", 13 | "page-toc-button", 14 | "collapsible-menu", 15 | "language-picker", 16 | "custom-favicon", 17 | "language-redirect@git+https://github.com/hamishwillee/gitbook-plugin-language-redirect.git", 18 | "toolbar@git+https://github.com/hamishwillee/gitbook-plugin-toolbar.git", 19 | "versions-select@git+https://github.com/Dronecode/gitbook-plugin-versions-select.git", 20 | "theme-dronecode@git+https://github.com/dronecode/theme-dronecode.git" 21 | ], 22 | "pluginsConfig": { 23 | "language-redirect": { 24 | "baseurl": "https://donlakeflyer.gitbooks.io/qgroundcontrol-developers-guide/" 25 | }, 26 | "richquotes": 27 | { 28 | "tip": { 29 | "alert": "success", 30 | "picto": "fa-thumbs-o-up" 31 | } 32 | }, 33 | "favicon": "favicon.ico", 34 | 35 | "versions": { 36 | "gitbookConfigURL": "https://raw.githubusercontent.com/mavlink/qgc-dev-guide/master/book.json", 37 | "options": [ 38 | { 39 | "value": "https://dev.qgroundcontrol.com/master/en/", 40 | "text": "master" 41 | } 42 | ] 43 | }, 44 | 45 | "toolbar": { 46 | "buttons": 47 | [ 48 | { 49 | "label": "Bug tracker", 50 | "icon": "fa fa-bug", 51 | "position" : "left", 52 | "url": "https://github.com/mavlink/qgc-dev-guide/issues/new?title=Doc+Bug:+{{title}}&body=DESCRIBE+PROBLEM+WITH+DOCS+HERE%0A%0ABug+Page:+[{{title}}]({{url}})" 53 | 54 | }, 55 | { 56 | "label": "GitHub", 57 | "icon": "fa fa-github", 58 | "url": "https://github.com/mavlink/qgc-dev-guide" 59 | }, 60 | { 61 | "label": "Edit page on github", 62 | "icon": "fa fa-pencil-square-o", 63 | "position" : "left", 64 | "url": "https://github.com/mavlink/qgc-dev-guide/edit/master/{{filepath_lang}}" 65 | } 66 | ] 67 | } 68 | 69 | 70 | } 71 | 72 | 73 | } 74 | -------------------------------------------------------------------------------- /crowdin.yml: -------------------------------------------------------------------------------- 1 | files: 2 | - source: /en/**/*.md 3 | translation: /%two_letters_code%/**/%original_file_name% 4 | -------------------------------------------------------------------------------- /en/README.md: -------------------------------------------------------------------------------- 1 | # QGroundControl Dev Guide 2 | 3 | [![Releases](https://img.shields.io/github/release/mavlink/QGroundControl.svg)](https://github.com/mavlink/QGroundControl/releases) [![Discuss](https://img.shields.io/badge/discuss-dev-ff69b4.svg)](http://discuss.px4.io/c/qgroundcontrol/qgroundcontrol-developers) 4 | 5 | This developer guide is the best source for information if you want to build, modify or extend [QGroundControl](http://qgroundcontrol.com) (QGC). 6 | It shows how to obtain and build the source code, explains how QGC works, and provides guidelines for contributing code to the project. 7 | 8 | > **Tip** This guide is for **developers**! To learn how to **use** *QGroundControl*, see the [User Guide](https://docs.qgroundcontrol.com/en/). 9 | 10 | 11 | > **Note** This guide is an active work in progress - information should be correct, but may not be complete! 12 | > If you find that it is missing helpful information (or errors) please raise an [issue](https://github.com/mavlink/qgc-dev-guide/issues). 13 | 14 | ## Design Philosophy 15 | 16 | QGC is designed to provide a single codebase that can run across multiple OS platforms as well as multiple device sizes and styles. 17 | 18 | The QGC user interface is implemented using [Qt QML](http://doc.qt.io/qt-5/qtqml-index.html). QML provides for hardware acceleration which is a key feature on lower powered devices such as tablets or phones. QML also provides features which allows us to more easily create a single user interface which can adapt itself to differing screen sizes and resolution. 19 | 20 | The QGC UI targets itself more towards a tablet+touch style of UI than a desktop mouse-based UI. This make a single UI easier to create since tablet style UI also tends to work fine on desktop/laptops. 21 | 22 | ## Support {#support} 23 | 24 | Development questions can be raised in the [QGroundControl Developer](http://discuss.px4.io/c/qgroundcontrol/qgroundcontrol-developers) discuss category. 25 | 26 | ## Contribution 27 | 28 | Information about contributing, including coding styles, testing and licenses can be found in [Code Submissions](contribute/README.md). 29 | 30 | > **Tip** We expect all contributors to adhere to the [QGroundControl code of conduct](https://github.com/mavlink/qgroundcontrol/blob/master/CODE_OF_CONDUCT.md). 31 | This code aims to foster an open and welcoming environment. 32 | 33 | ### Coordination Call 34 | 35 | The developer team meets bi-weekly to discuss the highest priority issues, project coordination, and discuss any Issues, PRs, or Questions from the Community. ([Developer Call Details](contribute/dev_call.md)) 36 | 37 | ### Translations 38 | 39 | We use [Crowdin](https://crowdin.com) to make it easier to manage translation for both *QGroundControl* and the documentation. 40 | 41 | The translation projects (and join links) are listed below: 42 | * [QGroundControl](https://crowdin.com/project/qgroundcontrol) ([join](https://crwd.in/qgroundcontrol)) 43 | * [QGroundControl User Guide](https://crowdin.com/project/qgroundcontrol-user-guide) ([join](https://crwd.in/qgroundcontrol-user-guide)) 44 | * [QGroundControl Developer Guide](https://crowdin.com/project/qgroundcontrol-developer-guide) ([join](https://crwd.in/qgroundcontrol-developer-guide)) 45 | 46 | The PX4 Developer Guide contains additional information about the (common) docs/translation toolchain: 47 | - [Documentation](https://dev.px4.io/en/contribute/docs.html) 48 | - [Translation](https://dev.px4.io/en/contribute/docs.html) 49 | 50 | 51 | ## License 52 | 53 | *QGroundControl* source code is [dual-licensed under Apache 2.0 and GPLv3](https://github.com/mavlink/qgroundcontrol/blob/master/COPYING.md). 54 | For more information see: [Licenses](contribute/licences.md). 55 | 56 | ## Governance 57 | 58 | The QGroundControl mission planner is hosted under the governance of the [Dronecode Project](https://www.dronecode.org/). 59 | 60 | Dronecode Logo 61 | Linux Foundation Logo 62 |
 
63 | -------------------------------------------------------------------------------- /en/ReleaseBranchingProcess.md: -------------------------------------------------------------------------------- 1 | # QGroundControl Release/Branching process 2 | 3 | ## Semantic Versioning 4 | 5 | QGC uses semantic versioning for the version numbers associated with its releases. 6 | Semantic versioning is a 3-component number in the format of `vX.Y.Z`, where: 7 | 8 | * `X` is the major version. 9 | * `Y` is the minor version. 10 | * `Z` is the patch version. 11 | 12 | ## Stable Builds 13 | 14 | The current stable build is the highest quality build available for QGC. 15 | [Patch releases](#patch_releases) of the stable build are regularly made to fix important issues. 16 | 17 | Stable builds are built from a separate branch that is named with the format: `Stable_VX.Y` (note, there is no patch number!) 18 | The branch has one or more git tags for each patch release (with the format `vX.Y.Z`), indicating the point in the repo source code that the associated patch release was created from. 19 | 20 | ### Patch Releases {#patch_releases} 21 | 22 | A patch release contains fixes to the stable release that are important enough to *require* an update, and are safe enough that the stable release continues to maintain high quality. 23 | 24 | Patch releases increment the patch version number only. 25 | 26 | ### Patch - Development Stage 27 | 28 | Approved fixes to the stable release are commited to the current stable branch. 29 | These fixes continue to queue up in the stable branch until a patch release is made (see next step). 30 | 31 | Commits/changes to the stable branch must also be brought over to the master branch (either through cherry pick or separate pulls). 32 | 33 | ### Patch - Release Stage 34 | 35 | At the point where the decision is made to do a patch release, the release binaries are created and a new *tag* is added to the stable branch (with the same patch release number) indicating the associated source code. 36 | 37 | > **Note** New branches are not created for patch releases - only for major and minor releases. 38 | 39 | 40 | ## Daily Builds 41 | 42 | ### Development Stage 43 | 44 | Daily builds are built from the `master` branch, and this is where all new major feature development happens. 45 | The state of master represents either the next minor point release, or a new major version release (depending on the level of change). 46 | 47 | There are no git tags associated with a released daily builds. 48 | The released daily build will always match repo HEAD. 49 | 50 | ### Release Stage 51 | 52 | When the decision is made to release a new major/minor version the master branch tends to go through an intial lockdown mode. 53 | This is where only important fixes for the release are accepted as pull requests. 54 | 55 | > **Note** During the lockdown phase, new features are not allowed in master. 56 | 57 | Once the level of fixes associated with the release slows down to a low level, a new stable branch is created (at this point the `master` branch can move forward again as the latest and greatest). 58 | 59 | Fixes continue in the stable branch until it is deemed ready to release (ideally after a short time)! 60 | At that point the new stable branch is tagged with the new version tag and the first stable release is made. 61 | 62 | ## Custom Builds 63 | 64 | A proposed strategy for branching on custom builds can be found [here](custom_build/ReleaseBranchingProcess.md). 65 | 66 | ## Process to create a new Stable 67 | 68 | ### Major/Minor Version 69 | 70 | 1. Create a branch from master named `Stable_VX.Y` where `X` is the major version number and `Y` is the minor version number. 71 | 1. Create a tag on the HEAD of master name `dX.Y` where the minor version is one greater than the new Stable. For example if you are create a new Stable 4.2 version then the tag would be 'd4.3'. This tag is used to create the version numbers for Android daily builds. Example: `git tag -a d4.3.0 -m "QGroundControl Daily Android Version Base"`. 72 | 1. Create an annotated tag on the newly created Stable branch named `vX.Y.0` with the correct major/minor version number. Example: `git tag -a v4.2.0 -m "QGroundControl v4.2.0"`. Pushing this tag to the repo will start a build. 73 | 1. Once the build completes verify the builds are pushed up to S3 correctly and sanity check that they at least boot correctly. Location on S3 will be `https://qgroundcontrol.s3.us-west-2.amazonaws.com/latest/...`. 74 | 1. Update the `https://qgroundcontrol.s3.us-west-2.amazonaws.com/builds/latest/QGC.version.txt` text file to the latest Stable version. This will notify uses there is a new Stable available the next time they launch QGC. 75 | 76 | ### Patch Version 77 | 78 | Creating a new Patch Version is the same except you skip steps 1 and 2 and in step 3 you bump the patch version number up as needed. -------------------------------------------------------------------------------- /en/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | * [Overview](README.md) 4 | * [Getting Started with source & builds](getting_started/README.md) 5 | * [Build using Containers](getting_started/container.md) 6 | * [Using QGC on CentOS](getting_started/CentOS.md) 7 | * [QGC Release/Branching Process](ReleaseBranchingProcess.md) 8 | * [Communication Flow](communication_flow.md) 9 | * [Plugin Architecture](firmware_plugin.md) 10 | * [Class Hierarchy](classes/README.md) 11 | * [User Interface Design](ui_design/README.md) 12 | * [Multi-Device Design Pattern](ui_design/multi_device_pattern.md) 13 | * [Font and Colour Palette](ui_design/font_palette.md) 14 | * [UI Controls](ui_design/controls.md) 15 | * [Fact System](fact_system.md) 16 | * [Top Level Views](views/README.md) 17 | * [Settings View](views/settings.md) 18 | * [Setup View](views/setup.md) 19 | * [Plan View](views/plan.md) 20 | * [Dynamic UI for mission item editing](plan/MissionCommandTree.md) 21 | * [Fly View](views/fly.md) 22 | * [File Formats](file_formats/README.md) 23 | * [Parameters](file_formats/parameters.md) 24 | * [Plan](file_formats/plan.md) 25 | * [MAVLink Logs](file_formats/mavlink.md) 26 | * [Developer Tools](tools/README.md) 27 | * [Mock Link](tools/mock_link.md) 28 | * [Command Line Options](command_line_options.md) 29 | * [Custom Builds](custom_build/custom_build.md) 30 | * [Initial Repository Setup For Custom Build](custom_build/CreateRepos.md) 31 | * [Custom Build Plugins](custom_build/Plugins.md) 32 | * [Resources Overrides](custom_build/ResourceOverride.md) 33 | * [Customization](custom_build/customization.md) 34 | * [First Run Prompts](custom_build/FirstRunPrompts.md) 35 | * [Toolbar customization](custom_build/Toolbar.md) 36 | * [Fly View Customization](custom_build/FlyView.md) 37 | * [Release/Branching Process For Custom Builds](custom_build/ReleaseBranchingProcess.md) 38 | * [MAVLink](custom_build/mavlink.md) 39 | * [Code Submission](contribute/README.md) 40 | * [Developer Call](contribute/dev_call.md) 41 | * [Coding Style](contribute/coding_style.md) 42 | * [Unit Tests](contribute/unit_tests.md) 43 | * [Pull Requests](contribute/pull_requests.md) 44 | * [Licenses](contribute/licences.md) 45 | 46 | ## Dronecode Shortcuts 47 | 48 | * [QGroundControl User Guide](https://docs.qgroundcontrol.com/en/) 49 | * [PX4 User Guide](https://docs.px4.io/en/) 50 | * [PX4 Developer Guide](https://dev.px4.io/en/) 51 | * [MAVLink Guide](https://mavlink.io/en/) 52 | * [MAVSDK](https://mavsdk.mavlink.io/) 53 | * [Dronecode Camera Manager](https://camera-manager.dronecode.org/en/) 54 | -------------------------------------------------------------------------------- /en/classes/README.md: -------------------------------------------------------------------------------- 1 | # Class Hierarchy (high level) 2 | 3 | ## LinkManager, LinkInterface 4 | 5 | A "Link" in QGC is a specific type of communication pipe with the vehicle such as a serial port or UDP over WiFi. The base class for all links is LinkInterface. Each link runs on it's own thread and sends bytes to MAVLinkProtocol. 6 | 7 | The `LinkManager` object keeps track of all open links in the system. `LinkManager` also manages automatic connections through serial and UDP links. 8 | 9 | ## MAVLinkProtocol 10 | 11 | There is a single `MAVLinkProtocol` object in the system. It's job is to take incoming bytes from a link and translate them into MAVLink messages. MAVLink HEARTBEAT messages are routed to ``MultiVehicleManager``. All MAVLink messages are routed to Vehicle's which are associated with the link. 12 | 13 | ## MultiVehicleManager 14 | 15 | There is a single `MultiVehicleManager` object within the system. When it receives a HEARTBEAT on a link which has not been previously seen it creates a Vehicle object. `MultiVehicleManager` also keeps tracks of all Vehicles in the system and handles switching from one active vehicle to another and correctly handling a vehicle being removed. 16 | 17 | ## Vehicle 18 | 19 | The Vehicle object is the main interface through which the QGC code communicates with the physical vehicle. 20 | 21 | Note: There is also a UAS object associated with each Vehicle which is a deprecated class and is slowly being phased out with all functionality moving to the Vehicle class. No new code should be added here. 22 | 23 | ## FirmwarePlugin, FirmwarePluginManager 24 | 25 | The FirmwarePlugin class is the base class for firmware plugins. A firmware plugin contains the firmware specific code, such that the Vehicle object is clean with respect to it supporting a single standard interface to the UI. 26 | 27 | FirmwarePluginManager is a factory class which creates a FirmwarePlugin instance based on the MAV_AUTOPILOT/MAV_TYPE combination for the Vehicle. 28 | -------------------------------------------------------------------------------- /en/command_line_options.md: -------------------------------------------------------------------------------- 1 | # Command Line Options 2 | 3 | You can start *QGroundControl* with command line options. These are used to enable logging, run unit tests, and simulate different host environments for testing. 4 | 5 | ## Starting QGroundControl with Options 6 | 7 | You will need to open a command prompt or terminal, change directory to where **qgroundcontrol.exe** is stored, and then run it. This is shown below for each platform (using the `--logging:full` option): 8 | 9 | Windows Command Prompt: 10 | ```bash 11 | cd "\Program Files (x86)\qgroundcontrol" 12 | qgroundcontrol --logging:full 13 | ``` 14 | OSX Terminal app (**Applications/Utilities**): 15 | ```bash 16 | cd /Applications/qgroundcontrol.app/Contents/MacOS/ 17 | ./qgroundcontrol --logging:full 18 | ``` 19 | Linux Terminal: 20 | ```bash 21 | ./qgroundcontrol-start.sh --logging:full 22 | ``` 23 | 24 | ## Options 25 | The options/command line arguments are listed in the table below. 26 | 27 | Option | Description 28 | --- | --- 29 | `--clear-settings` | Clears the app settings (reverts *QGroundControl* back to default settings). 30 | `--logging:full` | Turns on full logging. See [Console Logging](https://docs.qgroundcontrol.com/en/SettingsView/console_logging.html#logging-from-the-command-line). 31 | `--logging:full,LinkManagerVerboseLog,ParameterLoaderLog` | Turns on full logging and turns off the following listed comma-separated logging options. 32 | `--logging:LinkManagerLog,ParameterLoaderLog` | Turns on the specified comma separated logging options 33 | `--unittest:name` | (Debug builds only) Runs the specified unit test. Leave off `:name` to run all tests. 34 | `--unittest-stress:name` | (Debug builds only) Runs the specified unit test 20 times in a row. Leave off :name to run all tests. 35 | `--fake-mobile` | Simulates running on a mobile device. 36 | `--test-high-dpi` | Simulates running *QGroundControl* on a high DPI device. 37 | 38 | 39 | Notes: 40 | * Unit tests are included in debug builds automatically (as part of *QGroundControl*). *QGroundControl* runs under the control of the unit test (it does not start normally). 41 | -------------------------------------------------------------------------------- /en/communication_flow.md: -------------------------------------------------------------------------------- 1 | # Communication Flow 2 | 3 | Description of the high level communication flow which takes place during a vehicle auto-connect. 4 | 5 | * LinkManager always has a UDP port open waiting for a vehicle heartbeat 6 | * LinkManager detects a new known device type (Pixhawk, SiK Radio, PX4 Flow) that makes a UDP connection to the computer 7 | * LinkManager creates a new SerialLink between the computer and the device 8 | * Incoming bytes from the Link are sent to MAVLinkProtocol 9 | * MAVLinkProtocol converts the bytes into a MAVLink message 10 | * If the message is a `HEARTBEAT` the MultiVehicleManager is notified 11 | * MultiVehicleManager is notified of the `HEARTBEAT` and creates a new vehicle object based on the information in the `HEARTBEAT` message 12 | * The vehicle object instantiates the plugins that matches the vehicle 13 | * The ParameterLoader associated with the vehicle object sends a `PARAM_REQUEST_LIST` to the connected device to load parameters using the parameter protocol 14 | * Once the parameter load is complete, the MissionManager associated with the vehicle object requests the mission items from the connected device using the mission protocol 15 | * Once parameter load is complete, the VehicleComponents display their UI in the Setup view 16 | -------------------------------------------------------------------------------- /en/contribute/README.md: -------------------------------------------------------------------------------- 1 | # Code Submission 2 | 3 | This section contains topics about the contributing code, including coding style, testing and the format of pull requests. 4 | 5 | > **Note** QGroundControl (QGC) is [dual-licensed as Apache 2.0 and GPLv3](../contribute/licences.md). All contributions have to be made under both licenses. -------------------------------------------------------------------------------- /en/contribute/coding_style.md: -------------------------------------------------------------------------------- 1 | # Coding Style 2 | 3 | High level style information: 4 | 5 | * Tabs expanded to 4 spaces 6 | * Pascal/CamelCase naming conventions 7 | 8 | The style itself is documents in the following example files: 9 | 10 | * [CodingStyle.cc](https://github.com/mavlink/qgroundcontrol/blob/master/CodingStyle.cc) 11 | * [CodingStyle.h](https://github.com/mavlink/qgroundcontrol/blob/master/CodingStyle.h) 12 | * [CodingStyle.qml](https://github.com/mavlink/qgroundcontrol/blob/master/CodingStyle.qml) -------------------------------------------------------------------------------- /en/contribute/dev_call.md: -------------------------------------------------------------------------------- 1 | # Bi-Weekly Dev Call 2 | 3 | The QGroundControl developer team syncs up on technical details and in-depth analysis. There is also a space in the agenda to discuss pull requests, major impacting issues and Q&A. 4 | 5 | ## Who Should attend: 6 | * Community members 7 | * Core project maintiners 8 | * Component maintainers 9 | * Dronecode members 10 | 11 | 12 | > **Note** The calls are open for anyone interested to attend, it's a great opportunity to meet the team and contribute to the ongoing development of the project. 13 | 14 | ## What gets discussed? 15 | The main agenda for the call is very simple, and usually remains the same with a few exceptions which are made aware to the community in advance. The calls typically last up to 60 minutes. 16 | 17 | The developer team goes through the issue tracker, including the current queue of Pull Requests, 18 | 19 | ## Agenda 20 | While the agenda below is the norm, we might 21 | * Community Q&A (Open mic, you can bring your own topics, we can discuss your PRs/Issues/Questions) 22 | * Update on the project [High Priority Issues](https://github.com/mavlink/qgroundcontrol/projects/2) tracker 23 | * Developer team coordination 24 | 25 | > **Note** If you want to guarantee your Pull Request get's discussed on the next developer call, make sure you add the "dev-call" label on GitHub. We expect the author and the assigned reviewer to be on the call. 26 | 27 | ## Schedule 28 | * Time: Bi-Weekly on Tuesdays at 17h00 CET, 12h00 EST, 08h00 PST ([subscribe to the calendar](https://www.dronecode.org/calendar/)) 29 | * The call is hosted on Jitsi the open platform ([QGC Bi-Weekly](https://meet.jit.si/GCS-bi-weekly)) 30 | * the Agenda is published on the [PX4 Discuss - weekly-dev-call](https://discuss.px4.io/c/weekly-dev-call/qgc-developer-call/48) 31 | -------------------------------------------------------------------------------- /en/contribute/licences.md: -------------------------------------------------------------------------------- 1 | # Licences 2 | 3 | ## QGroundControl License 4 | 5 | *QGroundControl* (QGC) is dual-licensed as Apache 2.0 and GPLv3. All contributions have to be made under both licenses. Users of the codebase are free to use it under either license. 6 | 7 | > **Warning** *QGroundControl* licensing rules out the re-use of any copyleft (e.g. GPL) licensed code. All contributions must be original or from a compatible license (BSD 2/3 clause, MIT, Apache 2.0). 8 | 9 | The dual approach is necessary to be able to offer *QGroundControl* through the iOS and Android app stores and offers the open source community choice. 10 | 11 | ### Apache 2.0 License 12 | 13 | The [Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0) License is a permissive license which allows QGC to be built and used in any environment, including proprietary applications. It allows QGC to be built for mobile app stores. When building with Apache 2.0 a commercial Qt license is required. 14 | 15 | ### GPL v3 License 16 | 17 | The [GPL v3 License](http://www.gnu.org/licenses/gpl-3.0.en.html) is a strong copyleft license. When building QGC under this license the open source version of Qt can be used. Our licensing grants the permission to use a later version of the license, however, contributions have to be made under 3.0. 18 | 19 | 20 | ## Documentation, Artwork, Images 21 | 22 | The QGroundControl documentation, artwork and images are licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). 23 | 24 | 25 | ## See Also 26 | 27 | * [qgroundcontrol/COPYING.md](https://github.com/mavlink/qgroundcontrol/blob/master/COPYING.md) 28 | * [qgroundcontrol/CONTRIBUTING.md](https://github.com/mavlink/qgroundcontrol/blob/master/CONTRIBUTING.md) 29 | * [qgc-user-guide/LICENSE](https://github.com/mavlink/qgc-user-guide/blob/master/LICENSE) 30 | * [qgc-dev-guide/LICENSE](https://github.com/mavlink/qgc-dev-guide/blob/master/LICENSE) 31 | 32 | -------------------------------------------------------------------------------- /en/contribute/pull_requests.md: -------------------------------------------------------------------------------- 1 | # Pull Requests 2 | 3 | All pull requests go through the QGC CI build system which builds release and debug version. Builds will fail if there are compiler warnings. Also unit tests are run against supported OS debug builds. -------------------------------------------------------------------------------- /en/contribute/unit_tests.md: -------------------------------------------------------------------------------- 1 | # Unit Tests 2 | 3 | *QGroundControl* (QGC) contains a set of unit tests that must pass before a pull request will be accepted. The addition of new complex subsystems to QGC should include a corresponding new unit test to test it. 4 | 5 | The full list of unit tests can be found in [UnitTestList.cc](https://github.com/mavlink/qgroundcontrol/blob/master/src/qgcunittest/UnitTestList.cc). 6 | 7 | To run unit tests: 8 | 1. Build in `debug` mode with `UNITTEST_BUILD` definition. 9 | 1. Copy the **deploy/qgroundcontrol-start.sh** script in the **debug** directory 10 | 1. Run *all* unit tests from the command line using the `--unittest` command line option. 11 | For Linux this is done as shown: 12 | ``` 13 | qgroundcontrol-start.sh --unittest 14 | ``` 15 | 1. Run *individual* unit tests by specifying the test name as well: `--unittest:RadioConfigTest`. 16 | For Linux this is done as shown: 17 | ``` 18 | qgroundcontrol-start.sh --unittest:RadioConfigTest 19 | ``` 20 | -------------------------------------------------------------------------------- /en/custom_build/CreateRepos.md: -------------------------------------------------------------------------------- 1 | # Initial Repository Setup For Custom Build 2 | 3 | The suggested mechanism for working on QGC and a custom build version of QGC is to have two separate repositories. The first repo is your main QGC fork. The second repo is your custom build repo. 4 | 5 | ## Main QGC Respository 6 | 7 | This repo is used to work on changes to mainline QGC. When creating your own custom build it is not uncommon to discover that you may need a tweak/addition to the custom build to achieve what you want. By discussing those needed changes firsthand with QGC devs and submitting pulls to make the custom build architecture better you make QGC more powerful for everyone and give back to the community. 8 | 9 | The best way to create this repo is to fork the regular QGC repo to your own GitHub account. 10 | 11 | ## Custom Build Repository 12 | 13 | This is where you will do your main custom build development. All changes here should be within the custom directory as opposed to bleeding out into the regular QGC codebase. 14 | 15 | Since you can only fork a repo once, the way to create this repo is to "Create a new repository" in your GitHub account. Do not add any additional files to it like gitignore, readme's and so forth. Once it is created you will be given the option to setup up the Repo. Now you can select to "import code from another repository". Just import the regular QGC repo using the "Import Code" button. 16 | -------------------------------------------------------------------------------- /en/custom_build/FirstRunPrompts.md: -------------------------------------------------------------------------------- 1 | # First Run Prompts 2 | 3 | When QGC is started for the first time it prompts the user to specify some initial settings. At the time of writing this documentation those are: 4 | 5 | * Unit Settings - What units does the user want to use for display. 6 | * Offline Vehicle Settings - Vehicle information for creating Plans while not connected to a vehicle. 7 | 8 | The custom build architecure includes mechanisms for a custom build to both override the display of these prompts and/or create your own first run prompts. 9 | 10 | ## First Run Prompt Dialog 11 | Each first run prompt is a simple dialog which can display ui to the user. Whether the specific dialog has already been show to the user or not is stored in a setting. Here is the code for the upstream first run prompt dialogs: 12 | 13 | * [Units Settings](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirstRunPromptDialogs/UnitsFirstRunPrompt.qml) 14 | * [Offline Vehicle Settings](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirstRunPromptDialogs/OfflineVehicleFirstRunPrompt.qml) 15 | 16 | ## Standard First Run Prompt Dialogs 17 | Each dialog has a unique ID associated with it. When that dialog is shown to the user that ID is registered as having already been displayed so it only happens once (unless you clear settings). The set of first run prompt which are included with upstream QGC are considered the "Standard" set. QGC gets the list of standard prompts to display from the `QGCCorePlugin::firstRunPromptStdIds` call. 18 | 19 | ``` 20 | /// Returns the standard list of first run prompt ids for possible display. Actual display is based on the 21 | /// current AppSettings::firstRunPromptIds value. The order of this list also determines the order the prompts 22 | /// will be displayed in. 23 | virtual QList firstRunPromptStdIds(void); 24 | ``` 25 | 26 | You can override this method in your custom build if you want to hide some of those. 27 | 28 | ## Custom First Run Prompt Dialogs 29 | Custom builds have the ability to create their own set of additional first run prompts as needed through the use of the following QGCCorePlugin method overrides: 30 | 31 | ``` 32 | /// Returns the custom build list of first run prompt ids for possible display. Actual display is based on the 33 | /// current AppSettings::firstRunPromptIds value. The order of this list also determines the order the prompts 34 | /// will be displayed in. 35 | virtual QList firstRunPromptCustomIds(void); 36 | ``` 37 | ``` 38 | /// Returns the resource which contains the specified first run prompt for display 39 | Q_INVOKABLE virtual QString firstRunPromptResource(int id); 40 | ``` 41 | 42 | Your QGCCorePlugin should override these two methods as well as provide static consts for the ids of your new first run prompts. Look at how the standard set is implemented for how to do this and take the same approach. 43 | 44 | ## Order Of Display 45 | The set of first run prompts shown to the user are in the order returned by the `QGCCorePlugin::firstRunPromptStdIds` and `QGCCorePlugin::firstRunPromptCustomIds` with standard prompts shown before the custom prompts. Only the prompts which have not been previously shown to the user are shown. 46 | 47 | ## Always On Prompts 48 | By setting the `markAsShownOnClose: false` property in your prompt ui implementation you can create a prompt which will show up each time QGC starts. This can be used for things like showing usage tips to your users. If you do this it is best to make sure that this is displayed last. -------------------------------------------------------------------------------- /en/custom_build/FlyView.md: -------------------------------------------------------------------------------- 1 | # Fly View Customization 2 | 3 | The Fly View is designed in such a way that it can be cusomtized in multiple ways from simple to more complex. It is designed in three separate layers each of which are customizable providing different levels of change. 4 | 5 | 6 | ## Layers 7 | 8 | * There are three layers to the fly view from top to bottom visually: 9 | * [`FlyView.qml`](https://github.com/mavlink/qgroundcontrol/blob/master/src/FlightDisplay/FlyView.qml) This is the base layer of ui and business logic to control map and video switching. 10 | * [`FlyViewWidgetsOverlay.qml`](https://github.com/mavlink/qgroundcontrol/blob/master/src/FlightDisplay/FlyViewWidgetLayer.qml) This layer includes all the remaining widgets for the fly view. 11 | * [`FlyViewCustomLayer.qml`](https://github.com/mavlink/qgroundcontrol/blob/master/src/FlightDisplay/FlyViewCustomLayer.qml) This is a layer you override using resource override to add your own custom layer. 12 | 13 | ### Inset Negotiation using `QGCToolInsets` 14 | An important aspect of the Fly View is that it needs to understand how much central space it has in the middle of it's map window which is not obstructed by ui widgets which are at the edges of the window. It uses this information to pan the map when the vehicle goes out of view. This need to be done not only for the window edges but also for the widgets themselve such that the map pans before it goes under a widget. 15 | 16 | This is done through the use of the [`QGCToolInsets`](https://github.com/mavlink/qgroundcontrol/blob/master/src/QmlControls/QGCToolInsets.qml) object included in each layer. This objects provides inset information for each window edge informing the system as to how much real estate is taken up by edge based ui. Each layer is given the insets of the layer below it through `parentToolInsets` and then reports back the new insets taking into account the layer below and it's own additions through `toolInsets`. The final results total inset is then given to the map so it can do the right thing. The best way to understand this is to look at both the upstream and custom example code. 17 | 18 | ### `FlyView.qml` 19 | The base layer for the view is also the most complex from ui interactions and business logic. It includes the main display elements of map and video as well as the guided controls. Although you can resource override this layer it is not recommended. And if you do you better really (really) know what you are doing. The reason it is a separate layer is to make the layer above much simpler and easier to customize. 20 | 21 | ### `FlyViewWidgetsOverlay.qml` 22 | This layer contains all the remaining controls of the fly view. You have the ability to hide the controls through use of [`QGCFlyViewOptions`](https://github.com/mavlink/qgroundcontrol/blob/master/src/api/QGCOptions.h). But in order to change the layout of the upstream controls you must use a resource override. If you look at the source you'll see that the controls themselves are well encapsulated such that it should not be that difficult to create your own override which repositions them and/or adds your own ui. While maintaining a connection to the upstream implementaions of the controls. 23 | 24 | ### `FlyViewCustomLayer.qml` 25 | This provides the simplest customization ability to the Fly View. Allowing you the add ui elements which are additive to the existing upstream controls. The upstream code adds no ui elements and is meant to be the basis for your own custom code used as a resource override for this qml. The custom example code provides you with an example of how to do it. 26 | 27 | ## Recommendations 28 | 29 | ### Simple customization 30 | The best place to start is using a custom layer override plus turning off ui elements from the widgets layer (if needed). I would recommend trying to stick with only this if at all possible. It provides the greatest abilty to not get screwed by upstream changes in the layers below. 31 | 32 | ### Moderate complexity customization 33 | If you really need to reposition upstream ui elements then your only choice is overriding `FlyViewWidgetsOverlay.qml`. By doing this you are distancing yourself a bit from upstream changes. Although you will still get changes in the upstream controls for free. If there is a whole new control added to the fly view upstream you won't get it until you add it to your own override. 34 | 35 | ### Highly complex customization 36 | The last and least recommended customization mechanism is overriding `FlyView.qml`. By doing this you are distancing yourself even further from getting upstream changes for free. -------------------------------------------------------------------------------- /en/custom_build/Plugins.md: -------------------------------------------------------------------------------- 1 | # Custom Build Plugins 2 | 3 | The mechanisms for customizing QGC for a custom build is through the existing ```FirmwarePlugin```, ```AutoPilotPlugin``` and ```QGCCorePlugin``` architectures. By creating subclasses of these plugins in your custom build you can change the behavior of QGC to suit your needs without needed to modify the upstream code. 4 | 5 | 6 | ## QGCCorePlugin 7 | 8 | This allows you to modify the parts of QGC which are not directly related to vehicle but are related to the QGC application itself. This includes things like application settings, color palettes, branding and so forth. -------------------------------------------------------------------------------- /en/custom_build/ReleaseBranchingProcess.md: -------------------------------------------------------------------------------- 1 | # Release Process for Custom Builds [WIP Docs] 2 | 3 | One of the trickier aspects of creating your own custom build is the process to keep it up to date with regular QGC. This document describes a suggested process to follow. But in reality you are welcome to use whatever branching and release strategy you want for your custom builds. 4 | 5 | ## Upstream QGC release/branching strategy 6 | The best place to start is understanding the mechanism QGC uses to do it's own releases. We will layer a custom build release process on top of that. You can find standard QGC [release process here](../ReleaseBranchingProcess.md). 7 | 8 | ## Custom build/release types 9 | Regular QGC has two main build types: Stable and Daily. The build type for a custom build is more complex. Throughout this discussion we will use the term "upstream" to refer to the main QGC repo (https://github.com/mavlink/qgroundcontrol). Also when we talk about a "new" upstream stable release, this means a major/minor release, not a patch release. 10 | 11 | ### Synchronized Stable 12 | This type of release is synchronized with the release of an upstream stable. Once QGC releases stable you then release a version of your custom build which is based on this stable. This build will include all the new features from upstream including the new feature in your own custom code. 13 | 14 | ### Out-Of-Band Stable 15 | This a subsequent release of your custom build after you have released a synchronized stable but prior to upstream releasing a new stable. It only includes new features from your own custom build and include no new features from upstream. Work on this type of release would occur on a branch which is either based on your latest synchronized stable or your last out of band release if it exists. You can release out of band stable releases at any time past your first synchronized stable release. 16 | 17 | ### Daily 18 | Your custom daily builds are built from your ```master``` branch. It is important to keep your custom master up to date with QGC master. If you lag behind you may be surprised by upstream features which require some effort to integrate with your build. Or you may even require changes to "core" QGC in order to work with your code. 19 | If you don't let QGC development team know soon enough, it may end up being too late to get things changed. 20 | 21 | ## Options for your first build 22 | ### Starting with a Synchronized Stable release 23 | It is suggested that you start with releasing a Synchronized Stable. This isn't necessary but it is the simplest way to get started. To set your self up for a synchronized stable you create your own branch for development which is based on the upstream current stable. 24 | 25 | ### Starting with Daily builds 26 | The reason why you may consider this as your starting point is because you need features which are only in upstream master for your own custom builds. In this case you will have to live with releasing custom Daily builds until the next upstream stable. At which point you would release you first Synchronized Stable. For this setup you use your master branch and keep it in sync with upstream master as you develop. 27 | 28 | ## After you release your first Synchronized Stable 29 | 30 | ### Patch Releases 31 | As upstream QGC does patch releases on Stable you should also release your own patch releases based on upstream to keep your stable up to date with latest criticial bug fixes. 32 | 33 | ### Out-Of-Band, Daily: One or the other or both? 34 | At this point you can decide which type of releases you want to follow. You can also decide to possibly do both. You can do smaller new features which don't require new upstream features using out of band releases. And you can do major new feature work as daily/master until the point you can do a new synchronized stable. -------------------------------------------------------------------------------- /en/custom_build/ResourceOverride.md: -------------------------------------------------------------------------------- 1 | # Resource Overrides 2 | 3 | A "resource" in QGC source code terminology is anything found in the [qgroundcontrol.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/qgroundcontrol.qrc) and [qgcresources.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/qgcresources.qrc) file. By overriding a resource you can replace it with your own version of it. This could be as simple as a single icon, or as complex as replacing an entire Vehicle Setup page of qml ui code. 4 | 5 | Be aware that using resource overrides does not isolate you from upstream QGC changes like the plugin architecture does. In a sense you are directly modify the upstream QGC resources used by the main code. 6 | 7 | ## Exclusion Files 8 | 9 | The first step to overriding a resource is to "exclude" it from the standard portion of the upstream build. This means that you are going to provide that resource in your own custom build resource file(s). There are two files which achieve this: [qgroundcontrol.exclusion]() and [qgcresources.exclusion](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/qgcresources.exclusion). They correspond directly with the *.qrc counterparts. In order to exclude a resource, copy the resource line from the .qrc file into the appropriate .exclusion file. 10 | 11 | ## Custom version of excluded resources 12 | 13 | You must include the custom version of the overriden resouce in you custom build resource file. The resource alias must exactly match the upstream alias. The name and actual location of the resource can be anywhere within your custom directory structure. 14 | 15 | ## Generating the new modified versions of standard QGC resource file 16 | 17 | This is done using the ```updateqrc.py``` python script. It will read the upstream ```qgroundcontrol.qrc``` and ```qgcresources.qrc``` file and the corresponding exclusion files and output new versions of these files in your custom directory. These new versions will not have the resources you specified to exclude in them. The build system for custom builds uses these generated files (if they exist) to build with instead of the upstream versions. The generated version of these file should be added to your repo. Also whenever you update the upstream portion of QGC in your custom repo you must re-run ```python updateqrc.py``` to generate new version of the files since the upstream resources may have changed. 18 | 19 | ## Custom Build Example 20 | 21 | You can see an examples of custom build qgcresource overrides in the repo custom build example: 22 | 23 | * [qgcresources.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/qgcresources.exclusion) 24 | * [custom.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/custom.qrc) 25 | -------------------------------------------------------------------------------- /en/custom_build/Toolbar.md: -------------------------------------------------------------------------------- 1 | # Toolbar Customization 2 | The toolbar can be customized in a number of ways to fit your custom build needs. The toolbar internally is made up of a number of sections from left to right: 3 | 4 | * View Switching 5 | * Indicators 6 | * App Indicators 7 | * Vehicle Indicators 8 | * Vehicle Mode Indicators 9 | * Connection Management 10 | * Branding 11 | 12 | The Indicator section varies based on the view currently displayed: 13 | 14 | * Fly View - Shows all indicators 15 | * Plan View - Show no indicators and has its own custom indicator section for Plan status values 16 | * Other Views - Do not show Vehicle Mode Indicators 17 | 18 | ## Customization Possibilities 19 | 20 | ### Indicators 21 | 22 | You can add your own indicators for display or remove any of the upstream indicators. The mechanism you use depends on the indicator type. 23 | 24 | #### App Indicators 25 | These provide information to the user which is not associated with a vehicle. For example RTK status. To manipulate the list of app indicators you use `QGCPlugin::toolbarIndicators`. 26 | 27 | #### Vehicle Indicators 28 | These are indicators which are associated with information about the vehicle. They are only available when a vehicle is connected. To manipulate the list of vehicle indicators you override `FirmwarePlugin::toolIndicators`. 29 | 30 | #### Vehicle Mode Indicators 31 | These are indicators which are associated with information about the vehicle. They require additional UI provided by the Fly View to complete their actions. An example is Arming and Disarming. They are only available when a vehicle is connected. To manipulate the list of vehicle mode indicators you override `FirmwarePlugin::modeIndicators`. 32 | 33 | ### Modifying the toolbar UI itself 34 | This is accomplished by using resource overrides on the qml files associated with the toolbar. This provides a high level of customization but also a higher level of complexity. The primary ui for the toolbar is in `MainToolBar.qml`. The main window code in `MainRootWindow.qml` interacts with the toolbar to show different indicator sections based on current view as well as whether the mode indicators show or not also based on current view. 35 | 36 | If you want full control over the toolbar then you can override `MainToolBar.qml` and make your own completely different version. You will need to pay special attention to the interactions of the main toolbar with `MainRootWindow.qml` since you are going to need to replicated those interactions in your own custom version. 37 | 38 | There are two standard indicator ui sections of the toolbar: 39 | 40 | #### `MainToolBarIndicators.qml` 41 | This is used for all views except Plan. It display all the indicators in a row. Although you can override this file, in reality it doesn't do much other than layout for indicators. 42 | 43 | #### `PlanToolBarIndicators.qml` 44 | This is used by the Plan view to show the status values. If you want to change that ui you can override this file and provide your own custom version. -------------------------------------------------------------------------------- /en/custom_build/custom_build.md: -------------------------------------------------------------------------------- 1 | # Custom Builds 2 | 3 | A custom build allows third parties to create their own version of QGC in a way that allows them to easily keep up to date with changes which are being made in regular QGC. QGC has an architecture built into it which allows custom builds to modify and add to the feature set of regular QGC. 4 | 5 | Some possibilities with a custom build 6 | 7 | * Fully brand your build 8 | * Define a single flight stack to avoid carrying over unnecessary code 9 | * Implement your own, autopilot and firmware plugin overrides 10 | * Implement your own camera manager and plugin overrides 11 | * Implement your own QtQuick interface module 12 | * Implement your own toolbar, toolbar indicators and UI navigation 13 | * Implement your own Fly View overlay (and how to hide elements from QGC such as the flight widget) 14 | * Implement your own, custom QtQuick camera control 15 | * Implement your own, custom Pre-flight Checklist 16 | * Define your own resources for all of the above 17 | 18 | One of the downsides of QGC providing both generic support for any vehicle which supports mavlink as well as providing firmware specific support for both PX4 Pro and ArduPilot is complexity of the user interface. Since QGC doesn't know any information about your vehicle ahead of time it requires UI bits which can get in the way if the vehicle you fly only uses PX4 Pro firmware and is a multi-rotor vehicle. If that is a known thing then the UI can be simplified in various places. Also QGC targets both DIY users who are building their own vehicles from scratch as well as commercial users of off the shelf vehicles. Setting up a DIY drone from scratch requires all sort of functionality which is not needed for users of off the shelf vehicles. So for off the shelf vehicle users all the DIY specific stuff is just extra noise they need to look past. Creating a custom build allows you to specify exact details for your vehicle and hide things which are irrelevant thus creating an even simple user experience for your users than regular generic QGC. 19 | 20 | There is a plugin architecture in QGC which allows for this custom build creation. They can be found in QGCCorePlugin.h, FirmwarePlugin.h and AutoPilotPlugin.h associated classes. To create a custom build you create subclasses of the standard plugins overriding the set of methods which are appropriate for you usage. 21 | 22 | There is also a mechanism which allows you to override resources so you can change the smaller visual elements in QGC. 23 | 24 | Also internal to QGC is the concept of an "Advanced Mode". Whereas a standard QGC builds always runs in advanced mode. A custom build always starts out in regular/not advanced mode. There is an easier mechanism in the build to turn on advanced mode which is to click the fly view button 5 times in a row fairly quickly. If you do this in a custom build you will be warned about entering advanced mode. The concept here is to hide things which normal users should not have access to behind advanced mode. For example a commercial vehicle will not need access to most setup pages which are oriented to DIY setup. So a custom build can hide this. The custom example code shows how to do this. 25 | 26 | If you want to understand the possibilities, the first step is to read through those files which document what is possible. Next look through the [```custom-example```](https://github.com/mavlink/qgroundcontrol/tree/master/custom-example) source code including the [README](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/README.md). -------------------------------------------------------------------------------- /en/custom_build/customization.md: -------------------------------------------------------------------------------- 1 | # Customization 2 | 3 | The following topics explain how to customise various views and other parts of the UI. 4 | 5 | * [First Run Prompts](../custom_build/FirstRunPrompts.md) 6 | * [Toolbar customization](../custom_build/Toolbar.md) 7 | * [Fly View Customization](../custom_build/FlyView.md) -------------------------------------------------------------------------------- /en/custom_build/mavlink.md: -------------------------------------------------------------------------------- 1 | # MAVLink Customisation 2 | 3 | QGC communicates with flight stacks using [MAVLink](https://mavlink.io/en/), a very lightweight messaging protocol that has been designed for the drone ecosystem. 4 | 5 | QGC includes the [all.xml](https://mavlink.io/en/messages/all.html) dialect by default. The `all.xml` includes all other dialects in the [mavlink/mavlink](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0 ) repository, and allows it to communicate with both PX4 and Ardupilot. 6 | Previous versions of QGC (v4.2.8 and earlier), used the `ArduPilotMega.xml` dialect. 7 | 8 | In order to add support for a new set of messages you should add them to [development.xml](https://mavlink.io/en/messages/development.html), [ArduPilotMega.xml](https://mavlink.io/en/messages/ardupilotmega.html), or [common.xml](https://mavlink.io/en/messages/common.html) (for PX4), or fork *QGroundControl* and include your own dialect. 9 | 10 | To modify the version of MAVLink used by QGC: 11 | 12 | - Replace the pre-build C library at [/qgroundcontrol/libs/mavlink/include/mavlink](https://github.com/mavlink/qgroundcontrol/tree/master/libs/mavlink/include/mavlink). 13 | - By default this is a submodule importing https://github.com/mavlink/c_library_v2 14 | - You can change the submodule, or [build your own libraries](https://mavlink.io/en/getting_started/generate_libraries.html) using the MAVLink toolchain. 15 | - You can change the whole dialect used by setting it in [`MAVLINK_CONF`](https://github.com/mavlink/qgroundcontrol/blob/master/QGCExternalLibs.pri#L52) when running *qmake*. 16 | 17 | -------------------------------------------------------------------------------- /en/fact_system.md: -------------------------------------------------------------------------------- 1 | # Fact System 2 | 3 | The Fact System provides a set of capabilities which standardizes and simplifies the creation of the QGC user interface. 4 | 5 | ## Fact {#fact} 6 | 7 | A Fact represents a single value within the system. 8 | 9 | ## FactMetaData 10 | 11 | There is `FactMetaData` associated with each fact. It provides details on the Fact in order to drive automatic user interface generation and validation. 12 | 13 | ## Fact Controls 14 | 15 | A Fact Control is a QML user interface control which connects to a Fact and it's `FactMetaData` to provide a control to the user to modify/display the value associated with the Fact. 16 | 17 | ## FactGroup 18 | 19 | A *Fact Group* is a group of [Facts](#fact). 20 | It is used to organise facts and manage user defined facts. 21 | 22 | ## Custom Build Support 23 | 24 | User defined facts can be added by overriding `factGroups` function of `FirmwarePlugin` in a custom firmware plugin class. 25 | These functions return a name to fact group map that is used to identify added fact groups. 26 | A custom fact group can be added by extending `FactGroup` class. 27 | FactMetaDatas could be defined using the appopriate `FactGroup` constructor by providing a json file containing necessery information. 28 | 29 | Changing the metadata of existing facts is also possible by overriding `adjustMetaData` of `FirmwarePlugin` class. 30 | 31 | A fact associated with a vehicle (including facts belonging to fact groups returned in `factGroups` function of the vehicles Firmware plugin) can be reached using `getFact("factName")` or `getFact("factGroupName.factName")` 32 | 33 | For additional information please refer to comments in [FirmwarePlugin.h](https://github.com/mavlink/qgroundcontrol/blob/v4.0.8/src/FirmwarePlugin/FirmwarePlugin.h). 34 | -------------------------------------------------------------------------------- /en/file_formats/README.md: -------------------------------------------------------------------------------- 1 | # File Formats 2 | 3 | This section contains topics about the file formats used/supported by *QGroundControl*. -------------------------------------------------------------------------------- /en/file_formats/mavlink.md: -------------------------------------------------------------------------------- 1 | # MAVLink Log Format 2 | 3 | *QGroundControl* allows you to generate plain MAVLink packet logs that can be 4 | replayed (with QGroundControl) to watch a mission again for analysis. 5 | 6 | The format is binary: 7 | 8 | * Byte 1-8: Timestamp in microseconds since Unix epoch as unsigned 64 bit integer 9 | * Byte 9-271: MAVLink packet (263 bytes maximum packet length, not all bytes have to be actual data, the packet might be shorter. Includes packet start sign) 10 | 11 | ## Debugging 12 | 13 | To check your data, open your written file in a hex editor. You should see after 8 bytes **0x55**. The first 8 bytes should also convert to a valid timestamp, so something either close to zero or around the number **1294571828792000** (which is the current Unix epoch timestamp in microseconds). 14 | 15 | ## C++ Sketch for logging MAVLink 16 | 17 | The code fragment below shows how to implement logging using [C++ streams](http://www.cplusplus.com/reference/iostream/istream/) from the C++ standard library. 18 | 19 | ```cpp 20 | //write into mavlink logfile 21 | const int len = MAVLINK_MAX_PACKET_LEN+sizeof(uint64_t); 22 | uint8_t buf[len]; 23 | uint64_t time = getSystemTimeUsecs(); 24 | memcpy(buf, (void*)&time, sizeof(uint64_t)); 25 | mavlink_msg_to_send_buffer(buf+sizeof(uint64_t), msg); 26 | mavlinkFile << buf << flush; 27 | ``` -------------------------------------------------------------------------------- /en/file_formats/parameters.md: -------------------------------------------------------------------------------- 1 | # Parameters File Format 2 | 3 | ``` 4 | # Onboard parameters for Vehicle 1 5 | # 6 | # # Vehicle-Id Component-Id Name Value Type 7 | 1 1 ACRO_LOCKING 0 2 8 | 1 1 ACRO_PITCH_RATE 180 4 9 | 1 1 ACRO_ROLL_RATE 180 4 10 | 1 1 ADSB_ENABLE 0 2 11 | ``` 12 | 13 | Above is an example of a parameter file with four parameters. The file can include as many parameters as needed. 14 | 15 | Comments are preceded with a `#`. 16 | 17 | This header: `# MAV ID COMPONENT ID PARAM NAME VALUE` describes the format for each row: 18 | 19 | * `Vehicle-Id` Vehicle id 20 | * `Component-Id` Component id for parameter 21 | * `Name` Parameter name 22 | * `Value` Parameter value 23 | * `Type` Parameter type using MAVLink `MAV_PARAM_TYPE_*` enum values 24 | 25 | A parameter file contains the parameters for a single Vehicle. It can contain parameters for multiple components within that Vehicle. 26 | -------------------------------------------------------------------------------- /en/firmware_plugin.md: -------------------------------------------------------------------------------- 1 | # Plugin Architecture 2 | 3 | Although the MAVLink spec defines a standard communication protocol to communicate with a vehicle. There are many aspects of that spec that are up for interpretation by the firmware developers. Because of this there are many cases where communication with a vehicle running one firmware is be slightly different than communication with a vehicle running a different firmware in order to accomplish the same task. Also each firmware may implement a different subset of the MAVLink command set. 4 | 5 | Another major issue is that the MAVLink spec does not cover vehicle configuration or a common parameter set. Due to this all code which relates to vehicle setup ends up being firmware specific. Also any code which must refer to a specific parameter is also firmware specific. 6 | 7 | Given all of these differences between firmware implementations it can be quite tricky to create a single ground station application that can support each without having the codebase degrade into a massive pile of if/then/else statements peppered everywhere based on the firmware the vehicle is using. 8 | 9 | QGC uses a plugin architecture to isolate the firmware specific code from the code which is generic to all firmwares. There are two main plugins which accomplish this ```FirmwarePlugin``` and ```AutoPilotPlugin```. 10 | 11 | This plugin architecture is also used by custom builds to allow ever further customization beyond when standard QGC can provide. 12 | 13 | ## FirmwarePlugin 14 | 15 | This is used to create a standard interface to parts of Mavlink which are generally not standardized. 16 | 17 | ## AutoPilotPlugin 18 | 19 | This is used to provide the user interface for Vehicle Setup. 20 | 21 | ## QGCCorePlugin 22 | 23 | This is used to expose features of the QGC application itself which are not related to a Vehicle through a standard interface. This is then used by custom builds to adjust the QGC feature set to their needs. -------------------------------------------------------------------------------- /en/getting_started/CentOS.md: -------------------------------------------------------------------------------- 1 | # Using QGC on CentOS 7 2 | 3 | ## OS Installation 4 | 5 | To install CentOS 7: 6 | 1. Fetch the latest [CentOS 7 ISO from here](http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1810.iso) 7 | 1. Make a bootable USB stick out of the ISO e.g. by [following this guide](https://linuxize.com/post/how-to-create-a-bootable-centos-7-usb-stick/). 8 | 1. Boot the target device from the stick. 9 | 10 | 11 | The following examples show how to boot the target device from the stick. 12 | 13 | 14 | **Example:** *Panasonic Toughpad FZ-M1* (attaching a keyboard and mouse to the device to follow this guide is recommended). 15 | 1. Enter the BIOS menu by holding **Delete** on an attached USB keyboard or pressing all hardware buttons around the power button during boot. 16 | 1. Once inside the BIOS switch to the *Exit* tab using the arrow keys or the touchscreen. 17 | 1. Select your previously created and plugged in USB stick under Boot device override. 18 | 19 | 20 | **Example** [UAV Components Micronav](https://www.uavcomp.com/command-control/micronav/) device: 21 | 1. The setup of CentOS will not start with the default configuration. 22 | To solve this 23 | 1. Go to the BIOS menu as explained in the example above. 24 | 1. Disable the "Extension Port" device under the "Advanced" tab. 25 | 1. "Exit and save" the BIOS menu on the Exit page of the BIOS and try again. 26 | 1. After CentOS is installed, you revert the changes again so that the Microhard network works. 27 | 1. Make sure to never do a warm reboot but always first shut down the device if you want to reboot into Linux. 28 | Otherwise the Microhard network adapter will not work properly and slows down the whole system. 29 | 30 | 31 | ### CentOS Software Selection Installation Options 32 | 33 | These were the options used to setup a CentOS development system. 34 | Use it as a guideline. 35 | 36 | ![CentOS Installation](../../assets/getting_started/centos/centos_installation.png) 37 | 38 | ![CentOS Software Selection](../../assets/getting_started/centos/centos_sw_selection.png) 39 | 40 | ### Update GStreamer 41 | 42 | Once CentOS is installed and booted we need to set up the environment for QGC. 43 | First, we need to update GStreamer to a more recent version. 44 | This guide follows Alice Wonder's tips found here: https://media.librelamp.com 45 | 46 | ``` 47 | sudo yum install epel-release -y 48 | wget http://awel.domblogger.net/7/media/x86_64/awel-media-release-7-6.noarch.rpm 49 | sudo yum localinstall awel-media-release-7-6.noarch.rpm -y 50 | sudo yum clean all 51 | sudo yum update 52 | sudo yum install gstreamer1* --skip-broken -y 53 | ``` 54 | **Note:** Make sure these are installed (vaapi for Intel GPUs) 55 | ``` 56 | sudo yum install gstreamer1-vaapi 57 | sudo yum install gstreamer1-libav 58 | ``` 59 | **Note:** Install these to enable hardware accelerated video decoding 60 | ``` 61 | sudo yum install libva 62 | sudo yum install libva-utils 63 | sudo yum install libva-intel-driver 64 | ``` 65 | If libva-intel-driver is not found you can download it and install it manually 66 | ``` 67 | wget http://download1.rpmfusion.org/free/el/updates/7/x86_64/l/libva-intel-driver-1.8.3-4.el7.x86_64.rpm 68 | sudo yum localinstall libva-intel-driver-1.8.3-4.el7.x86_64.rpm -y 69 | ``` 70 | 71 | ### Installing SDL2 72 | 73 | SDL2 is used for joystick support. 74 | 75 | ``` 76 | sudo yum install SDL2 SDL2-devel -y 77 | ``` 78 | 79 | ### Update Kernel (optional) 80 | 81 | > **Tip** If your Joystick gets recognized and shows up as `/dev/input/js0` when you run the command `/dev/input/*` you can skip this step. 82 | 83 | We recommend updating the kernel for: 84 | - Better touch screen responsiveness. 85 | - Correct recognition of some USB devices - in particular joysticks. 86 | 87 | The following joysticks are known not do work out of the box with the default CentOS 7 kernel (3.10.0): 88 | - Logitech F310 89 | - Microsoft Xbox 360 controller (USB) 90 | 91 | 92 | To fix the joystick not being recognized (even if the same unit is working under Windows or Ubuntu) please [follow this guide to update the kernel](https://www.howtoforge.com/tutorial/how-to-upgrade-kernel-in-centos-7-server/). 93 | 94 | Here's a short summary of the commands that you need to execute to update the kernel: 95 | ``` 96 | sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org 97 | sudo rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm 98 | sudo yum --enablerepo=elrepo-kernel install kernel-ml -y 99 | ``` 100 | 101 | Reboot your device afterwards and make sure the new kernel version shows up as the default start option in the GRUB menu on boot. 102 | 103 | > **Note** You might need to disable secure boot in the BIOS to allow the new kernel to be booted. 104 | 105 | ## Running QGC on CentOS 106 | 107 | Before launching QGC, you need to make sure the current user has access to the dialout group (serial port access permission): 108 | ``` 109 | sudo usermod -a -G dialout $USER 110 | ``` 111 | 112 | ### Firewall 113 | 114 | The default firewall security level of Red Hat distributions like CentOS block MAVLink communication and also the camera video stream. 115 | So you need to create rules to open the incoming ports for MAVLink and camera stream. 116 | For non-production local environment testing purposes ONLY you can temporarily disable the firewall using the following commands ([from here](https://www.liquidweb.com/kb/how-to-stop-and-disable-firewalld-on-centos-7/)): 117 | 118 | Temporary: 119 | ``` 120 | systemctl stop firewalld 121 | ``` 122 | 123 | Permanent (at your own risk): 124 | ``` 125 | systemctl disable firewalld 126 | ``` 127 | 128 | Undo permanent change: 129 | ``` 130 | systemctl enable firewalld 131 | ``` 132 | 133 | ### Connection problems with multiple networks 134 | 135 | In our test with CentOS we had problems when connecting to multiple networks through multiple network devices even with appropriate IP address and subnet assignment. 136 | 137 | Issues consisted of: 138 | - Losing Internet access when connecting to a second network 139 | - Having flaky connection to the vehicle with a lot of hiccups and packet losses (e.g. 30 seconds perfect connection 4 seconds of packet loss in a regular pattern) 140 | 141 | If you face any of these problems avoid them by only connecting one network at a time e.g. switching between WiFi and Microhard. 142 | 143 | ### Executing a Prebuilt QGC Binary 144 | 145 | - Get hold of an archive containing a prebuilt binary of QGC for CentOS. 146 | At the moment there is no automatic deployment for this build if you urgently need one get in touch with the developers. 147 | - [Unpack the archive](https://www.hostdime.com/kb/hd/command-line/how-to-tar-untar-and-zip-files). 148 | - Go inside the unpacked files and locate the script named `qgroundcontrol-run.sh` 149 | - Run it by executing the command 150 | ``` 151 | ./qgroundcontrol-run.sh 152 | ``` 153 | 154 | ## Building QGC on CentOS 155 | 156 | ### Installing Qt 157 | ``` 158 | mkdir ~/devel 159 | cd ~/devel 160 | ``` 161 | 162 | Install Qt 5.12.4 from the Qt installation script that can be downloaded [here](https://www.qt.io/download-thank-you?os=linux&hsLang=en). 163 | Once downloaded, make it executable and run it: 164 | ``` 165 | chmod +x qt-unified-linux-x64-3.1.1-online.run 166 | ./qt-unified-linux-x64-3.1.1-online.run 167 | ``` 168 | 169 | Select the following options and install it under `~/devel/Qt`: 170 | 171 | ![Qt Software Selection](../../assets/getting_started/centos/qt_setup.png) 172 | 173 | ### Clone and Build QGC 174 | 175 | ``` 176 | git clone --recursive https://github.com/mavlink/qgroundcontrol.git 177 | mkdir build 178 | cd build 179 | ``` 180 | For a debug/test build: 181 | ``` 182 | ../Qt/5.12.4/gcc_64/bin/qmake ../qgroundcontrol/qgroundcontrol.pro -spec linux-g++ CONFIG+=debug 183 | ``` 184 | For a release build: 185 | ``` 186 | ../Qt/5.12.4/gcc_64/bin/qmake ../qgroundcontrol/qgroundcontrol.pro -spec linux-g++ CONFIG+=qtquickcompiler 187 | ``` 188 | Build it: 189 | ``` 190 | make -j4 191 | ``` 192 | 193 | You can alternatively launch *QtCreator* (found under `~/devel/Qt/Tools/QtCreator/bin/qtcreator`), load the `qgroundcontro.pro` project and build/debug from within its IDE. 194 | 195 | By default, this will build the regular QGC. 196 | To build the sample, customized UI version, follow [these instructions](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/README.md). 197 | -------------------------------------------------------------------------------- /en/getting_started/README.md: -------------------------------------------------------------------------------- 1 | # Getting Started 2 | 3 | This topic explains how to get the *QGroundControl* source code and build it either natively or within a *Vagrant* environment. 4 | It also provides information about optional or OS specific functionality. 5 | 6 | ## Daily Builds 7 | 8 | If you just want to test (and not debug) a recent build of *QGroundControl* you can use the [Daily Build](https://docs.qgroundcontrol.com/en/releases/daily_builds.html). Versions are provided for all platforms. 9 | 10 | ## Source Code 11 | 12 | Source code for *QGroundControl* is kept on GitHub here: https://github.com/mavlink/qgroundcontrol. 13 | It is [dual-licensed under Apache 2.0 and GPLv3](https://github.com/mavlink/qgroundcontrol/blob/master/COPYING.md). 14 | 15 | To get the source files: 16 | 1. Clone the repo (or your fork) including submodules: 17 | ``` 18 | git clone --recursive -j8 https://github.com/mavlink/qgroundcontrol.git 19 | ``` 20 | 2. Update submodules (required each time you pull new source code): 21 | ``` 22 | git submodule update --recursive 23 | ``` 24 | 25 | > **Tip** Github source-code zip files cannot be used because these do not contain the appropriate submodule source code. 26 | > You must use git! 27 | 28 | 29 | ## Build QGroundControl 30 | 31 | ### Using Containers 32 | We support Linux builds using a container found on the source tree of the repository, which can help you develop and deploy the QGC apps without having to install any of the requirements on your local environment. 33 | 34 | [Container Guide](../getting_started/container.md) 35 | 36 | ### Native Builds 37 | 38 | *QGroundControl* builds are supported for macOS, Linux, Windows, iOS and Android. 39 | *QGroundControl* uses [Qt](http://www.qt.io) as its cross-platform support library and uses [QtCreator](http://doc.qt.io/qtcreator/index.html) as its default build environment. 40 | 41 | - **macOS:** v10.11 or higher 42 | - **Ubuntu:** 64 bit, gcc compiler 43 | - **Windows:** Vista or higher, [Visual Studio 2019 compiler](#vs) (64 bit) 44 | - **iOS:** 10.0 and higher 45 | - **Android:** Android 5.0 and later. 46 | - Standard QGC is built against ndk version 19. 47 | - Java JDK 11 is required. 48 | - **Qt version:** {{ book.qt_version }} **(only)** 49 | > **Warning** **Do not use any other version of Qt!** 50 | QGC has been thoroughly tested with the specified version of Qt ({{ book.qt_version }}). 51 | There is a significant risk that other Qt versions will inject bugs that affect stability and safety (even if QGC compiles). 52 | 53 | For more information see: [Qt 5 supported platform list](http://doc.qt.io/qt-5/supported-platforms.html). 54 | 55 | 56 | > **Note** Native [CentOS Builds](../getting_started/CentOS.md) are also supported, but are documented separately (as the tested environment is different). 57 | 58 | #### Install Visual Studio 2019 (Windows Only) {#vs} 59 | 60 | The Windows compiler can be found here: [Visual Studio 2019 compiler](https://visualstudio.microsoft.com/vs/older-downloads/) (64 bit) 61 | 62 | When installing, select *Desktop development with C++* as shown: 63 | 64 | ![Visual Studio 2019 - Select Desktop Environment with C++](../../assets/getting_started/visual_studio_select_features.png) 65 | 66 | > **Note** Visual Studio is ONLY used to get the compiler. Actually building *QGroundControl* should be done using [Qt Creator](#qt-creator) or [qmake](#qmake) as outlined below. 67 | 68 | 69 | #### Install Qt 70 | 71 | You **need to install Qt as described below** instead of using pre-built packages from say, a Linux distribution, because *QGroundControl* needs access to private Qt headers. 72 | 73 | To install Qt: 74 | 75 | 1. Download and run the [Qt Online Installer](http://www.qt.io/download-open-source) 76 | - **Ubuntu:** 77 | - Set the downloaded file to executable using: `chmod +x`. 78 | - Install to default location for use with **./qgroundcontrol-start.sh.** If you install Qt to a non-default location you will need to modify **qgroundcontrol-start.sh** in order to run downloaded builds. 79 | 1. In the installer *Select Components* dialog choose: {{ book.qt_version }}. 80 | 81 | > **Note** If the version needed is not displayed, check the archive (show archive and refresh). 82 | 83 | Then install just the following components: 84 | - **Windows**: *MSVC 2019 64 bit* 85 | - **MacOS**: *macOS* 86 | - **Linux**: *Desktop gcc 64-bit* 87 | - All: 88 | - *Qt Charts* 89 | - *Android ARMv7* (optional, used to build Android) 90 | 91 | ![QtCreator Select Components (Windows)](../../assets/getting_started/qt_creator_select_components.jpg) 92 | 1. Install Additional Packages (Platform Specific) 93 | - **Ubuntu:** `sudo apt-get install speech-dispatcher libudev-dev libsdl2-dev patchelf build-essential curl` 94 | - **Fedora:** `sudo dnf install speech-dispatcher SDL2-devel SDL2 systemd-devel patchelf` 95 | - **Arch Linux:** `pacman -Sy speech-dispatcher patchelf` 96 | - **Android:** [Qt Android Setup](http://doc.qt.io/qt-5/androidgs.html) 97 | > **Note** JDK11 is required (install if needed)! 98 | 1. Install Optional/OS-Specific Functionality 99 | 100 | > **Note** Optional features that are dependent on the operating system and user-installed libraries are linked/described below. 101 | These features can be forcibly enabled/disabled by specifying additional values to qmake. 102 | 103 | - **Video Streaming/Gstreamer:** - see [Video Streaming](https://github.com/mavlink/qgroundcontrol/blob/master/src/VideoReceiver/README.md). 104 | - **Airmap SDK:** - TBD. 105 | 1. Disable platform-specific optional features that are enabled (but not installed), by default. 106 | 107 | > **Note** This currently applies to Airmap on Linux, which is optional but enabled by default. 108 | 109 | - **Ubuntu:** 110 | - Airmap: Create a file named **user_config.pri** (in the repo root directory) containing the text `DEFINES += DISABLE_AIRMAP`. 111 | This can be done in a bash terminal using the command: 112 | ``` 113 | echo -e "DEFINES += DISABLE_AIRMAP\r\n" | tee user_config.pri 114 | ``` 115 | 116 | #### Building using Qt Creator {#qt-creator} 117 | 118 | 1. Launch *Qt Creator* and open the **qgroundcontrol.pro** project. 119 | 1. In the **Projects** section, select the appropriate kit for your needs: 120 | - **OSX:** Desktop Qt {{ book.qt_version }} clang 64 bit 121 | > **Note** iOS builds must be built using [XCode](http://doc.qt.io/qt-5/ios-support.html). 122 | - **Ubuntu:** Desktop Qt {{ book.qt_version }} GCC 64bit 123 | - **Windows:** Desktop Qt {{ book.qt_version }} MSVC2019 **64bit** 124 | - **Android:** Android for armeabi-v7a (GCC 4.9, Qt {{ book.qt_version }}) 125 | - JDK11 is required. 126 | You can confirm it is being used by reviewing the project setting: **Projects > Manage Kits > Devices > Android (tab) > Android Settings > _JDK location_**. 127 | 1. Build using the "hammer" (or "play") icons: 128 | 129 | ![QtCreator Build Button](../../assets/getting_started/qt_creator_build_qgc.png) 130 | 131 | #### Build using qmake on CLI {#qmake} 132 | 133 | Example commands to build a default QGC and run it afterwards: 134 | 135 | 1. Make sure you cloned the repository and updated the submodules before, see chapter *Source Code* above and switch into the repository folder: 136 | ``` 137 | cd qgroundcontrol 138 | ``` 139 | 1. Create and enter a shadow build directory: 140 | ``` 141 | mkdir build 142 | cd build 143 | ``` 144 | 1. Configure the build using the qmake script in the root of the repository: 145 | ``` 146 | qmake ../ 147 | ``` 148 | 1. Run make to compile and link. 149 | To accelerate the process things you can use the `-j{number of threads}` parameter. 150 | ``` 151 | make -j12 152 | ``` 153 | > **Note** You can also specify build time flags here. 154 | > For example, you could disable airmap inclusion using the command: 155 | > ``` 156 | > DEFINES+=DISABLE_AIRMAP make build 157 | > ``` 158 | 159 | 1. Run the QGroundcontrol binary that was just built: 160 | ``` 161 | ./staging/QGroundControl 162 | ``` 163 | 164 | ### Vagrant 165 | 166 | [Vagrant](https://www.vagrantup.com/) can be used to build and run *QGroundControl* within a Linux virtual machine (the build can also be run on the host machine if it is compatible). 167 | 168 | 1. [Download](https://www.vagrantup.com/downloads.html) and [Install](https://www.vagrantup.com/docs/getting-started/) Vagrant 169 | 1. From the root directory of the *QGroundControl* repository run `vagrant up` 170 | 1. To use the graphical environment run `vagrant reload` 171 | 172 | ### Additional Build Notes for all Supported OS 173 | 174 | * **Parallel builds:** For non Windows builds, you can use the `-j#` option to run parellel builds. 175 | * **Location of built files:** Individual build file results can be found in the `build_debug` or `build_release` directories. The built executable can be found in the `debug` or `release` directory. 176 | * **If you get this error when running _QGroundControl_**: `/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found.`, you need to either update to the latest *gcc*, or install the latest *libstdc++.6* using: `sudo apt-get install libstdc++6`. 177 | * **Unit tests:** To run the [unit tests](../contribute/unit_tests.md), build in `debug` mode with `UNITTEST_BUILD` definition, and then copy `deploy/qgroundcontrol-start.sh` script into the `debug` directory before running the tests. 178 | 179 | 180 | ## Building QGC Installation Files 181 | 182 | You can additionally create installation file(s) for *QGroundControl* as part of the normal build process. 183 | 184 | > **Note** On Windows you will need to first install [NSIS](https://sourceforge.net/projects/nsis/). 185 | 186 | To add support for installation file creation you need to add `CONFIG+=installer` to your project file, or when you call *qmake*. 187 | 188 | To do this in *Qt Creator*: 189 | - Open **Projects > Build > Build Steps > qmake > Additional arguments**. 190 | - Enter `CONFIG+=installer` as shown: 191 | ![Installer](../../assets/getting_started/qt_project_installer.png) 192 | -------------------------------------------------------------------------------- /en/getting_started/container.md: -------------------------------------------------------------------------------- 1 | # Building using Containers 2 | 3 | The community created a docker image that makes it much easier to build a Linux-based QGC application. 4 | This can give you a massive boost in productivity and help with testing. 5 | 6 | ## About the Container 7 | 8 | The Container is located in the `./deploy/docker` directory. 9 | It's based on ubuntu 20.04. 10 | It pre-installs all the dependencies at build time, including Qt, thanks to a script located in the same directory, `install-qt-linux.sh`. 11 | The main advantage of using the container is the usage of the `CMake` build system and its many improvements over `qmake` 12 | 13 | ## Building the Container 14 | 15 | Before using the container, you have to build the image. 16 | You can accomplish this using docker, running the following script from the root of the QGC source code directory. 17 | 18 | ``` 19 | docker build --file ./deploy/docker/Dockerfile-build-linux -t qgc-linux-docker . 20 | ``` 21 | 22 | > **Note** The `-t` flag is essential. 23 | Keep in mind this is tagging the image for later reference since you can have multiple builds of the same container 24 | 25 | 26 | > **Note** If building on a Mac computer with an M1 chip you must also specify the build option `--platform linux/x86_64` as shown: 27 | > ``` 28 | > docker build --platform linux/x86_64 --file ./deploy/docker/Dockerfile-build-linux -t qgc-linux-docker . 29 | > ``` 30 | > Otherwise you will get a build error like: 31 | > ``` 32 | > qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory 33 | > ``` 34 | 35 | 36 | ## Building QGC using the Container 37 | 38 | To use the container to build QGC, you first need to define a directory to save the artifacts. 39 | We recommend you create a `build` directory on the source tree and then run the docker image using the tag provided above as follows, from the root directory: 40 | 41 | ``` 42 | mkdir build 43 | docker run --rm -v ${PWD}:/project/source -v ${PWD}/build:/project/build qgc-linux-docker 44 | ``` 45 | 46 | > **Note** If using the script to build the Linux image on a Windows host, you would need to reference the PWD differently. 47 | > On Windows the docker command is: 48 | > 49 | > ``` 50 | > docker run --rm -v %cd%:/project/source -v %cd%/build:/project/build qgc-linux-docker 51 | > ``` 52 | 53 | Depending on your system resources, or the resources assigned to your Docker Daemon, the build step can take some time. 54 | 55 | 56 | ## Troubleshooting 57 | 58 | ### Windows: 'bash\r': No such file or directory 59 | 60 | This error indicates that a Linux script is being run with Windows line endings, which might occur if `git` was configured to use Windows line endings: 61 | ``` 62 | > [4/7] RUN /tmp/qt/install-qt-linux.sh: 63 | #9 0.445 /usr/bin/env: 'bash\r': No such file or directory 64 | ``` 65 | 66 | One fix is to force Linux line endings using the command: 67 | ``` 68 | git config --global core.autocrlf false 69 | ``` 70 | Then update/recreate your local repository. 71 | -------------------------------------------------------------------------------- /en/plan/MissionCommandTree.md: -------------------------------------------------------------------------------- 1 | # Mission Command Tree 2 | 3 | QGC creates the user interface for editing a specific mission item command dynamically from a hierarchy of json metadata. This hierarchy is called the Mission Command Tree. This way only json metadata must be created when new commands are added. 4 | 5 | ## Why a tree? 6 | 7 | The tree is needed to deal with the idosyncracies of differening firmware supporting commands differently and/or different vehicle types supporting the commands in different ways. The simplest example of that is mavlink spec may include command parameters which are not supported by all firmwares. Or command parameters which are only valid for certain vehicle types. Also in some cases a GCS may decide to hide some of the command parameters from view to end users since they are too complex or cause usability problems. 8 | 9 | The tree is the MissionCommandTree class: [MissionCommandTree.cc](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandTree.cc), [MissionCommandTree.h](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandTree.h) 10 | 11 | ### Tree Root 12 | 13 | The root of the tree is json metadata which matches the mavlink spec exactly. 14 | 15 | Here you can see an example of the root [json](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoCommon.json#L27) for ```MAV_CMD_NAV_WAYPOINT```: 16 | 17 | ``` 18 | { 19 | "id": 16, 20 | "rawName": "MAV_CMD_NAV_WAYPOINT", 21 | "friendlyName": "Waypoint", 22 | "description": "Travel to a position in 3D space.", 23 | "specifiesCoordinate": true, 24 | "friendlyEdit": true, 25 | "category": "Basic", 26 | "param1": { 27 | "label": "Hold", 28 | "units": "secs", 29 | "default": 0, 30 | "decimalPlaces": 0 31 | }, 32 | "param2": { 33 | "label": "Acceptance", 34 | "units": "m", 35 | "default": 3, 36 | "decimalPlaces": 2 37 | }, 38 | "param3": { 39 | "label": "PassThru", 40 | "units": "m", 41 | "default": 0, 42 | "decimalPlaces": 2 43 | }, 44 | "param4": { 45 | "label": "Yaw", 46 | "units": "deg", 47 | "nanUnchanged": true, 48 | "default": null, 49 | "decimalPlaces": 2 50 | } 51 | }, 52 | ``` 53 | 54 | Note: In reality this based information should be provided by mavlink itself and not needed to be part of a GCS. 55 | 56 | ### Leaf Nodes 57 | 58 | The leaf nodes then provides metadata which can override values for the command and/or remove parameters from display to the user. The full tree hierarchy is this: 59 | 60 | - Root - Generic Mavlink 61 | - Vehicle Type Specific - Vehicle specific overrides to the generic spec 62 | - Firmware Type Specific - One optional leaf node for each firmware type (PX4/ArduPilot) 63 | - Vehicle Type Specific - One optional leaf node for each vehicel type (FW/MR/VTOL/Rover/Sub) 64 | 65 | Note: In reality this override capability should be part of mavlink spec and should be able to be queried from the vehicle. 66 | 67 | ### Building the instance tree from the full tree 68 | 69 | Since the json metadata provides information for all firmware/vehicle type combinations the actual tree to use must be built based on the firmware and vehicle type which is being used to create a Plan. This is done through a process call "collapsing" the full tree to a firmware/vehicle specific tree ([code](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandTree.cc#L119)). 70 | 71 | The steps are as follows: 72 | * Add the root to the instance tree 73 | * Apply the vehicle type specific overrides to the instance tree 74 | * Apply the firmware type specific overrides to the instance tree 75 | * Apply the firmware/vehicle type specific overrides to the instance tree 76 | 77 | The resulting Mission Command Tree is then used to build UI for the Plan View item editors. In reality it is used for more than just that, there are many other places where knowing more information about a specific command id is useful. 78 | 79 | ## Example hierarchy for ```MAV_CMD_NAV_WAYPOINT``` 80 | 81 | Let's walk through an example hierarchy for ```MAV_CMD_NAV_WAYPOINT```. Root information is shown above. 82 | 83 | ### Root - Vehicle Type Specific leaf node 84 | The next level of the hiearchy is generic mavlink but vehicle specific. Json files are here: [MR](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoMultiRotor.json), [FW](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoFixedWing.json), [ROVER](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoRover.json), [Sub](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoSub.json), [VTOL](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoVTOL.json). And here are the overrides for (Fixed Wings)(https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoFixedWing.json#L7): 85 | 86 | ``` 87 | { 88 | "id": 16, 89 | "comment": "MAV_CMD_NAV_WAYPOINT", 90 | "paramRemove": "4" 91 | }, 92 | ``` 93 | 94 | What this does is remove the editing UI for param4 which is Yaw and not used by fixed wings. Since this is a leaf node of the root, this applies to all fixed wing vehicle no matter the firmware type. 95 | 96 | ### Root - Firmware Type Specific leaf node 97 | The next level of the hiearchy are overrides which are specific to a firmware type but apply to all vehicle types. Once again lets loook at the waypoint overrides: 98 | 99 | [ArduPilot](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/APM/MavCmdInfoCommon.json#L6): 100 | 101 | ``` 102 | { 103 | "id": 16, 104 | "comment": "MAV_CMD_NAV_WAYPOINT", 105 | "paramRemove": "2" 106 | }, 107 | ``` 108 | 109 | [PX4](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/PX4/MavCmdInfoCommon.json#L7): 110 | 111 | ``` 112 | { 113 | "id": 16, 114 | "comment": "MAV_CMD_NAV_WAYPOINT", 115 | "paramRemove": "2,3" 116 | }, 117 | ``` 118 | 119 | You can see that for both firmwares param2 which is acceptance radius is removed from the editing ui. This is a QGC specific decision. It is generally safer and easier to use the firmwares generic acceptance radius handling than the specify a value. So we've decided to hide it from users. 120 | 121 | You can also see that for PX4 param3/PassThru is removed since it is not supported by PX. 122 | 123 | ### Root - Firmware Type Specific - Vehicle Type Specific leaf node 124 | The last level of the hiearchy is both firmware and vehicle type specific. 125 | 126 | [ArduPilot/MR](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/APM/MavCmdInfoMultiRotor.json#L7): 127 | 128 | ``` 129 | { 130 | "id": 16, 131 | "comment": "MAV_CMD_NAV_WAYPOINT", 132 | "paramRemove": "2,3,4" 133 | }, 134 | ``` 135 | 136 | Here you can see that for an ArduPilot Multi-Rotor vehicle param2/3/4 Acceptance/PassThru/Yaw are removed. Yaw for example is removed because it is not supported. Due to quirk of how this code works, you need to repeat the overrides from the lower level. 137 | 138 | ## Mission Command UI Info 139 | Two classes define the metadata associated with a command: 140 | 141 | * MissionCommandUIInfo - Metadata for the entire command 142 | * MissionCmdParamInfo - Metadata for a param in a command 143 | 144 | The source is commented with full details of the json keys which are supported. 145 | 146 | [MissionCommandUIInfo](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandUIInfo.h#L82): 147 | 148 | ``` 149 | /// UI Information associated with a mission command (MAV_CMD) 150 | /// 151 | /// MissionCommandUIInfo is used to automatically generate editing ui for a MAV_CMD. This object also supports the concept of only having a set of partial 152 | /// information for the command. This is used to create overrides of the base command information. For on override just specify the keys you want to modify 153 | /// from the base command ui info. To override param ui info you must specify the entire MissionParamInfo object. 154 | /// 155 | /// The json format for a MissionCommandUIInfo object is: 156 | /// 157 | /// Key Type Default Description 158 | /// id int reauired MAV_CMD id 159 | /// comment string Used to add a comment 160 | /// rawName string required MAV_CMD enum name, should only be set of base tree information 161 | /// friendlyName string rawName Short description of command 162 | /// description string Long description of command 163 | /// specifiesCoordinate bool false true: Command specifies a lat/lon/alt coordinate 164 | /// specifiesAltitudeOnly bool false true: Command specifies an altitude only (no coordinate) 165 | /// standaloneCoordinate bool false true: Vehicle does not fly through coordinate associated with command (exampl: ROI) 166 | /// isLandCommand bool false true: Command specifies a land command (LAND, VTOL_LAND, ...) 167 | /// friendlyEdit bool false true: Command supports friendly editing dialog, false: Command supports 'Show all values" style editing only 168 | /// category string Advanced Category which this command belongs to 169 | /// paramRemove string Used by an override to remove params, example: "1,3" will remove params 1 and 3 on the override 170 | /// param[1-7] object MissionCommandParamInfo object 171 | /// 172 | ``` 173 | 174 | [MissionCmdParamInfo](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandUIInfo.h#L25): 175 | 176 | ``` 177 | /// UI Information associated with a mission command (MAV_CMD) parameter 178 | /// 179 | /// MissionCommandParamInfo is used to automatically generate editing ui for a parameter associated with a MAV_CMD. 180 | /// 181 | /// The json format for a MissionCmdParamInfo object is: 182 | /// 183 | /// Key Type Default Description 184 | /// label string required Label for text field 185 | /// units string Units for value, should use FactMetaData units strings in order to get automatic translation 186 | /// default double 0.0/NaN Default value for param. If no default value specified and nanUnchanged == true, then defaultValue is NaN. 187 | /// decimalPlaces int 7 Number of decimal places to show for value 188 | /// enumStrings string Strings to show in combo box for selection 189 | /// enumValues string Values associated with each enum string 190 | /// nanUnchanged bool false True: value can be set to NaN to signal unchanged 191 | ``` 192 | -------------------------------------------------------------------------------- /en/tools/README.md: -------------------------------------------------------------------------------- 1 | # Developer Tools 2 | 3 | *QGroundControl* makes a number of tools available primarily for autopilot developers. 4 | These ease common developer tasks including setting up simulated connections for testing, 5 | and accessing the System Shell over MAVLink. 6 | 7 | > **Note** [Build the source in debug mode](https://github.com/mavlink/qgroundcontrol#supported-builds) to enable these tools. 8 | 9 | Tools include: 10 | 11 | - **[Mock Link](../tools/mock_link.md)** (Daily Builds only) - Creates and stops multiple simulated vehicle links. 12 | - **[Replay Flight Data](https://docs.qgroundcontrol.com/en/app_menu/replay_flight_data.html)** - Replay a telemetry log (User Guide). 13 | - **[MAVLink Inspector](https://docs.qgroundcontrol.com/en/app_menu/mavlink_inspector.html)** - Display received MAVLink messages/values. 14 | - **[MAVLink Analyzer](https://docs.qgroundcontrol.com/en/app_menu/mavlink_analyzer.html)** - Plot trends for MAVLink messages/values. 15 | - **[Custom Command Widget](https://docs.qgroundcontrol.com/en/app_menu/custom_command_widget.html)** - Load custom/test QML UI at runtime. 16 | - **[Onboard Files](https://docs.qgroundcontrol.com/en/app_menu/onboard_files.html)** - Navigate vehicle file system and upload/download files. 17 | - **[HIL Config Widget](https://docs.qgroundcontrol.com/en/app_menu/hil_config.html)** - Settings for HIL simulators. 18 | - **[MAVLink Console](https://docs.qgroundcontrol.com/en/analyze_view/mavlink_console.html)** (PX4 Only) - Connect to the PX4 nsh shell and send commands. 19 | -------------------------------------------------------------------------------- /en/tools/mock_link.md: -------------------------------------------------------------------------------- 1 | # Mock Link 2 | 3 | *Mock Link* allows you to create and stop links to multiple simulated (mock) vehicles in *QGroundControl* debug builds. 4 | 5 | The simulation does not support flight, but does allow easy testing of: 6 | 7 | * Mission upload/download 8 | * Viewing and changing parameters 9 | * Testing most setup pages 10 | * Multiple vehicle UIs 11 | 12 | It is particularly useful for unit testing error cases for mission upload/download. 13 | 14 | ## Using Mock Link 15 | 16 | To use *Mock Link*: 17 | 18 | 1. Create a debug build by [building the source](https://github.com/mavlink/qgroundcontrol#supported-builds). 19 | 1. Access *Mock Link* by selecting the *Application Settings* icon in the top toolbar and then **Mock Link** in the sidebar: 20 | 21 | ![](../../assets/tools/mocklink_waiting_for_connection.jpg) 22 | 23 | 1. The buttons in the panel can be clicked to create a vehicle link of the associated type. 24 | 25 | * Each time you click a button a new connection will be created. 26 | * When there is more than one connection the multiple-vehicle UI will appear. 27 | 28 | ![](../../assets/tools/mocklink_connected.jpg) 29 | 30 | 1. Click the **Stop one Mock Link** to stop the currently active vehicle. 31 | 32 | Using *Mock Link* is then more or less the same as using any other vehicle, except that the simulation does not allow flight. 33 | -------------------------------------------------------------------------------- /en/ui_design/README.md: -------------------------------------------------------------------------------- 1 | # User Interface Design 2 | 3 | The main pattern for UI design in QGC is a UI page written in QML, many times communicating with a custom "Controller" written in C++. This follows a somewhat hacked variant of the MVC design pattern. 4 | 5 | The QML code binds to information associated with the system through the following mechanisms: 6 | * The custom controller 7 | * The global ``QGroundControl`` object which provides access to things like the active Vehicle 8 | * The FactSystem which provides access to parameters and in some cases custom Facts. 9 | 10 | Note: Due to the complexity of the QML used in QGC as well as it's reliance on communication with C++ objects to drive the ui it is not possible to use the QML Designer provided by Qt to edit QML. -------------------------------------------------------------------------------- /en/ui_design/controls.md: -------------------------------------------------------------------------------- 1 | # User Interface Controls 2 | 3 | QGC provides a base set of controls for building user interface. In general they tend to be thin layers above the base QML Controls supported by Qt which respect the QGC color palette. 4 | 5 | ``` 6 | import QGroundControl.Controls 1.0 7 | ``` 8 | 9 | ## Qt Controls 10 | 11 | The following controls are QGC variants of standard Qt QML Controls. They provide the same functionality as the corresponding Qt controls except for the fact that they are drawn using the QGC palette. 12 | 13 | * QGCButton 14 | * QGCCheckBox 15 | * QGCColoredImage 16 | * QGCComboBox 17 | * QGCFlickable 18 | * QGCLabel 19 | * QGCMovableItem 20 | * QGCRadioButton 21 | * QGCSlider 22 | * QGCTextField 23 | 24 | ## QGC Controls 25 | 26 | These custom controls are exclusive to QGC and are used to create standard UI elements. 27 | 28 | * DropButton - RoundButton which drops out a panel of options when clicked. Example is Sync button in Plan view. 29 | * ExclusiveGroupItem - Used as a base Item for custom controls which supports the QML ExclusiveGroup concept. 30 | * QGCView - Base control for all top level views in the system. Provides support for FactPanels and displaying QGCViewDialogs and QGCViewMessages. 31 | * QGCViewDialog - Dialog which pops out from the right side of a QGCView. You can specific the accept/reject buttons for the dialog as well as the dialog contents. Example usage is when you click on a parameter and it brings up the value editor dialog. 32 | * QGCViewMessage - A simplified version of QGCViewDialog which allows you to specify buttons and a simple text message. 33 | * QGCViewPanel - The main view contents inside of a QGCView. 34 | * RoundButton - A round button control which uses an image as its inner contents. 35 | * SetupPage - The base control for all Setup vehicle component pages. Provides a title, description and component page contents area. -------------------------------------------------------------------------------- /en/ui_design/font_palette.md: -------------------------------------------------------------------------------- 1 | # Font and Palette 2 | 3 | QGC has a standard set of fonts and color palette which should be used by all user interface. 4 | 5 | ``` 6 | import QGroundControl.Palette 1.0 7 | import QGroundControl.ScreenTools 1.0 8 | ``` 9 | 10 | ## QGCPalette 11 | 12 | This item exposes the QGC color palette. There are two variants of this palette: light and dark. The light palette is meant for outdoor use and the dark palette is for indoor. Normally you should never specify a color directly for UI, you should always use one from the palette. If you don't follow this rule, the user interface you create will not be capable of changing from a light/dark style. 13 | 14 | ## QGCMapPalette 15 | 16 | The map palette is used for colors which are used to draw over a map. Due to the the different map styles, specifically satellite and street you need to have different colors to draw over them legibly. Satellite maps needs lighter colors to be seen whereas street maps need darker colors to be seen. The ``QGCMapPalette`` item provides a set of colors for this as well as the ability to switch between light and dark colors over maps. 17 | 18 | ## ScreenTools 19 | 20 | The ScreenTools item provides values which you can use to specify font sizing. It also provides information on screen size and whether QGC is running on a mobile device. 21 | 22 | -------------------------------------------------------------------------------- /en/ui_design/multi_device_pattern.md: -------------------------------------------------------------------------------- 1 | # Multi-Device Design Pattern 2 | 3 | QGroundControl is designed to run on multiple device types from desktop to laptop to tablet to small phone sized screens using mouse and touch. Below is the description of how QGC does it and the reasoning behind it. 4 | 5 | ## Efficient 1 person dev team 6 | The design pattern that QGC development uses to solve this problem is based around making new feature development quick and allowing the code base to be testable and maintained by a very small team (let's say 1 developer as the default dev team size). The pattern to achieve this is followed very strictly, because not following it will lead to slower dev times and lower quality. 7 | 8 | Supporting this 1 person dev team concept leads to some tough decisions which not everyone may be happy about. But it does lead to QGC being released on many OS and form factors using a single codebase. This is something most other ground stations out there are not capable of achieving. 9 | 10 | What about contributors you ask? QGC has a decent amount of contributors. Can't they help move things past this 1 person dev team concept? Yes QGC has quite a few contributors. But unfortunately they come and go over time. And when they go, the code they contributed still must be maintained. Hence you fall back to the 1 person dev team concept which is mostly what has been around as an average over the last three years of development. 11 | 12 | ## Target Device 13 | 14 | The priority target for QGC UI design is a tablet, both from a touch standpoint and a screen size standpoint (think 10" Samsung Galaxy tab). Other device types and sizes may see some sacrifices of visuals and/or usability due to this decision. The current order when making priority based decisions is Tablet, Laptop, Desktop, Phone (any small screen). 15 | 16 | ### Phone sized screen support 17 | 18 | As specified above, at this point smaller phone sized screens are the lowest level priority for QGC. More focus is put onto making active flight level displays, such as the Fly view, more usable. Less focus is placed on Setup related views such as Setup and Plan. Those specific views are tested to be functionally usable on small screens but they may be painful to use. 19 | 20 | ## Development tools used 21 | ### Qt Layout controls 22 | QGC does not have differently coded UIs which are targeted to different screen sizes and/or form factors. In general it uses QML Layout capabilities to reflow a single set of QML UI code to fit different form factors. In some cases it provides less detail on small screen sizes to make things fit. But that is a simple visibility pattern. 23 | 24 | ### FactSystem 25 | Internal to QGC is a system which is used to manage all of the individual pieces of data within the system. This data model is then connected to controls. 26 | 27 | ### Heavy reliance on reusable controls 28 | QGC UI is developed from a base set of reusable controls and UI elements. This way any new feature added to a reusable control is now available throughout the UI. These reusable controls also connect to FactSystem Facts which then automatically provides appropriate UI. 29 | 30 | ## Cons for this design pattern 31 | 32 | * The QGC user interface ends up being a hybrid style of desktop/laptop/tablet/phone. Hence not necessarily looking or feeling like it is optimized to any of these. 33 | * Given the target device priority list and the fact that QGC tends to just re-layout the same UI elements to fit different form factors you will find this hybrid approach gets worse as you get farther away from the priority target. Hence small phone sized screens taking the worst hit on usability. 34 | * The QGC reusable control set may not provide the absolute best UI in some cases. But it is still used to prevent the creation of additional maintenance surface area. 35 | * Since the QGC UI uses the same UI code for all OSes, QGC does not follow the UI design guidelines specified by the OS itself. It has it's own visual style which is somewhat of a hybrid of things picked from each OS. Hence the UI looks and works mostly the same on all OS. Once again this means for example that QGC running on Android won't necessarily look like an android app. Or QGC running on an iPhone will not look or work like most other iPhone apps. That said the QGC visual/functional style should be understandable to these OS users. 36 | 37 | ## Pros for this design pattern 38 | 39 | * It takes less time to design a new feature since the UI coding is done once using this hybrid model and control set. Layout reflow is quite capable in Qt QML and becomes second nature once you get used to it. 40 | * A piece of UI can be functionally tested on one platform since the functional code is the same across all form factors. Only layout flow must be visually checked on multiple devices but this is fairly easily done using the mobile simulators. In most cases this is what is needed: 41 | * Use desktop build, resizing windows to test reflow. This will generally cover a tablet sized screen as well. 42 | * Use a mobile simulator to visually verify a phone sized screen. On OSX XCode iPhone simulator works really well. 43 | * All of the above are critical to keeping our hypothetical 1 person dev team efficient and to keep quality high. 44 | 45 | ## Future directions 46 | 47 | * Raise phone (small screen) level prioritization to be more equal to Tablet. Current thinking is that this won't happen until a 3.3 release time frame (release after current one being worked on). 48 | 49 | -------------------------------------------------------------------------------- /en/views/README.md: -------------------------------------------------------------------------------- 1 | # Top Level Views 2 | 3 | This section contains topics about the code for the top level views: settings, setup, plan and fly. -------------------------------------------------------------------------------- /en/views/fly.md: -------------------------------------------------------------------------------- 1 | # Fly View 2 | 3 | * Top level QML code is in **FlightDisplayView.qml** 4 | * QML code communicates with `MissionController` (C++) for mission display 5 | * Instrument widgets communicate with active Vehicle object 6 | * Two main inner views are: 7 | * `FlightDisplayViewMap` 8 | * `FlightDisplayViewVideo` 9 | 10 | -------------------------------------------------------------------------------- /en/views/plan.md: -------------------------------------------------------------------------------- 1 | # Plan View 2 | 3 | * Top level QML code is in [PlanView.qml](https://github.com/mavlink/qgroundcontrol/blob/master/src/PlanView/PlanView.qml) 4 | * Main visual UI is a FlightMap control 5 | * QML communicates with MissionController (C++) which provides the view with the mission item data and methods 6 | -------------------------------------------------------------------------------- /en/views/settings.md: -------------------------------------------------------------------------------- 1 | # Settings View 2 | 3 | * Top level QML code is **AppSettings.qml** 4 | * Each button loads a separate QML page 5 | 6 | -------------------------------------------------------------------------------- /en/views/setup.md: -------------------------------------------------------------------------------- 1 | # Setup View 2 | 3 | * Top level QML code implemented in **SetupView.qml** 4 | * Fixed set of buttons/pages: Summary, Firmware 5 | * Remainder of buttons/pages come from AutoPilotPlugin VehicleComponent list 6 | 7 | -------------------------------------------------------------------------------- /favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mavlink/qgc-dev-guide/1248b0c472b29d0c5b809e9d0f01ef80ced0e884/favicon.ico -------------------------------------------------------------------------------- /zh/GitBranching.md: -------------------------------------------------------------------------------- 1 | # Git Branching 2 | 3 | ## Semantic Versioning 4 | 5 | QGC uses semantic version for the version numbers associated with its releases. Semantic versioning is a 3-component number in the format of `vX.Y.Z`, where: 6 | 7 | * `X` is the major version. 8 | * `Y` is the minor version. 9 | * `Z` is the patch version. 10 | 11 | ## Stable Builds 12 | 13 | The current stable build is the highest quality build available for QGC. [Patch releases](#patch_releases) of the stable build are regularly made to fix important issues. 14 | 15 | Stable builds are built from a separate branch that is named with the format: `Stable_VX.Y` (note, there is no patch number!) The branch has one or more git tags for each patch release (with the format `vX.Y.Z`), indicating the point in the repo source code that the associated patch release was created from. 16 | 17 | ### Patch Releases {#patch_releases} 18 | 19 | A patch release contains fixes to the stable release that are important enough to *require* an update, and are safe enough that the stable release continues to maintain high quality. 20 | 21 | Patch releases increment the patch version number only. 22 | 23 | ### Patch - Development Stage 24 | 25 | Approved fixes to the stable release are commited to the current stable branch. These fixes continue to queue up in the stable branch until a patch release is made (see next step). 26 | 27 | Commits/changes to the stable branch must also be brought over to the master branch (either through cherry pick or separate pulls). 28 | 29 | ### Patch - Release Stage 30 | 31 | At the point where the decision is made to do a patch release, the release binaries are created and a new *tag* is added to the stable branch (with the same patch release number) indicating the associated source code. 32 | 33 | > **Note** New branches are not created for patch releases - only for major and minor releases. 34 | 35 | 36 | ## Daily Builds 37 | 38 | ### Development Stage 39 | 40 | Daily builds are built from the `master` branch, and this is where all new major feature development happens. The state of master represents either the next minor point release, or a new major version release (depending on the level of change). 41 | 42 | There are no git tags associated with a released daily builds. The released daily build will always match repo HEAD. 43 | 44 | ### Release Stage 45 | 46 | When the decision is made to release a new major/minor version the master branch tends to go through an intial lockdown mode. This is where only important fixes for the release are accepted as pull requests. 47 | 48 | > **Note** During the lockdown phase, new features are not allowed in master. 49 | 50 | Once the level of fixes associated with the release slows down to a low level, a new stable branch is created (at this point the `master` branch can move forward again as the latest and greatest). 51 | 52 | Fixes continue in the stable branch until it is deemed ready to release (ideally after a short time)! At that point the new stable branch is tagged with the new version tag and the first stable release is made. 53 | 54 | ## Custom Builds 55 | 56 | A proposed strategy for branching on custom builds can be found [here](custom_build/GitBranching.md). 57 | -------------------------------------------------------------------------------- /zh/README.md: -------------------------------------------------------------------------------- 1 | # QGroundControl开发指南 2 | 3 | [![版本发布](https://img.shields.io/github/release/mavlink/QGroundControl.svg)](https://github.com/mavlink/QGroundControl/releases) [![Discuss](https://img.shields.io/badge/discuss-dev-ff69b4.svg)](http://discuss.px4.io/c/qgroundcontrol/qgroundcontrol-developers) 4 | 5 | 如果要构建，修改或扩展QGroundControl（QGC），此开发人员指南是获取信息的最佳来源。 它展示了如何获取和构建源代码，解释了QGC的工作原理，并提供了为项目贡献代码的指南。 6 | 7 | > **Tip** 本指南适用于开发人员！ 要了解如何使用QGroundControl，请参阅“用户指南”。 8 | 9 | 10 | 11 | > **Note** 本指南的编写是一项正在进行的活动 - 信息应该是正确的，但可能不完整！ 如果您发现它缺少有用的信息（或错误），请提出问题。 12 | 13 | ## 设计理念 14 | 15 | QGC 的设计是为了提供一个能够跨越多个操作系统平台以及多种设备的单个代码库。 16 | 17 | QGC 用户界面使用[Qt QML](http://doc.qt.io/qt-5/qtqml-index.html)实现。 QML提供硬件加速，这是平板电脑或手机等低功率设备的关键功能。 QML还提供了一些功能，使我们能够更轻松地创建单个用户界面，以适应不同的屏幕尺寸和分辨率。 18 | 19 | 与基于桌面鼠标的UI相比，QGC UI更倾向于平板电脑+触摸式UI。 这使得单个UI更容易创建，因为平板电脑样式UI也可以在台式机/笔记本电脑上正常工作。 20 | 21 | ## 支持 {#support} 22 | 23 | Development questions can be raised in the [QGroundControl Developer](http://discuss.px4.io/c/qgroundcontrol/qgroundcontrol-developers) discuss category. 24 | 25 | ## 贡献 26 | 27 | 有关贡献的信息，包括编码样式，测试和许可证，可以在代码提交中找到。 28 | 29 | > **Tip** We expect all contributors to adhere to the [QGroundControl code of conduct](https://github.com/mavlink/qgroundcontrol/blob/master/CODE_OF_CONDUCT.md). This code aims to foster an open and welcoming environment. 30 | 31 | ### Coordination Call 32 | 33 | The developer team meets bi-weekly to discuss the highest priority issues, project coordination, and discuss any Issues, PRs, or Questions from the Community. ([Developer Call Details](contribute/dev_call.md)) 34 | 35 | ### Translations 36 | 37 | We use [Crowdin](https://crowdin.com) to make it easier to manage translation for both *QGroundControl* and the documentation. 38 | 39 | The translation projects (and join links) are listed below: 40 | 41 | - [QGroundControl](https://crowdin.com/project/qgroundcontrol)（[加入](https://crwd.in/qgroundcontrol)） 42 | - [QGroundControl使用指南](https://crowdin.com/project/qgroundcontrol-user-guide)（[加入](https://crwd.in/qgroundcontrol-user-guide)） 43 | - [QGroundControl开发者指南](https://crowdin.com/project/qgroundcontrol-developer-guide)（[加入](https://crwd.in/qgroundcontrol-developer-guide)） 44 | 45 | The PX4 Developer Guide contains additional information about the (common) docs/translation toolchain: 46 | 47 | - [文档](https://dev.px4.io/en/contribute/docs.html) 48 | - [翻译](https://dev.px4.io/en/contribute/docs.html) 49 | 50 | ## 许可证 51 | 52 | *QGroundControl* source code is [dual-licensed under Apache 2.0 and GPLv3](https://github.com/mavlink/qgroundcontrol/blob/master/COPYING.md). For more information see: [Licenses](contribute/licences.md). 53 | 54 | ## 管理 55 | 56 | The QGroundControl mission planner is hosted under the governance of the [Dronecode Project](https://www.dronecode.org/). 57 | 58 | Dronecode Logo 59 | Linux Foundation Logo 60 | 61 |
 
62 | -------------------------------------------------------------------------------- /zh/ReleaseBranchingProcess.md: -------------------------------------------------------------------------------- 1 | # QGroundControl Release/Branching process 2 | 3 | ## Semantic Versioning 4 | 5 | QGC uses semantic versioning for the version numbers associated with its releases. Semantic versioning is a 3-component number in the format of `vX.Y.Z`, where: 6 | 7 | * `X` is the major version. 8 | * `Y` is the minor version. 9 | * `Z` is the patch version. 10 | 11 | ## Stable Builds 12 | 13 | The current stable build is the highest quality build available for QGC. [Patch releases](#patch_releases) of the stable build are regularly made to fix important issues. 14 | 15 | Stable builds are built from a separate branch that is named with the format: `Stable_VX.Y` (note, there is no patch number!) The branch has one or more git tags for each patch release (with the format `vX.Y.Z`), indicating the point in the repo source code that the associated patch release was created from. 16 | 17 | ### Patch Releases {#patch_releases} 18 | 19 | A patch release contains fixes to the stable release that are important enough to *require* an update, and are safe enough that the stable release continues to maintain high quality. 20 | 21 | Patch releases increment the patch version number only. 22 | 23 | ### Patch - Development Stage 24 | 25 | Approved fixes to the stable release are commited to the current stable branch. These fixes continue to queue up in the stable branch until a patch release is made (see next step). 26 | 27 | Commits/changes to the stable branch must also be brought over to the master branch (either through cherry pick or separate pulls). 28 | 29 | ### Patch - Release Stage 30 | 31 | At the point where the decision is made to do a patch release, the release binaries are created and a new *tag* is added to the stable branch (with the same patch release number) indicating the associated source code. 32 | 33 | > **Note** New branches are not created for patch releases - only for major and minor releases. 34 | 35 | 36 | ## Daily Builds 37 | 38 | ### Development Stage 39 | 40 | Daily builds are built from the `master` branch, and this is where all new major feature development happens. The state of master represents either the next minor point release, or a new major version release (depending on the level of change). 41 | 42 | There are no git tags associated with a released daily builds. The released daily build will always match repo HEAD. 43 | 44 | ### Release Stage 45 | 46 | When the decision is made to release a new major/minor version the master branch tends to go through an intial lockdown mode. This is where only important fixes for the release are accepted as pull requests. 47 | 48 | > **Note** During the lockdown phase, new features are not allowed in master. 49 | 50 | Once the level of fixes associated with the release slows down to a low level, a new stable branch is created (at this point the `master` branch can move forward again as the latest and greatest). 51 | 52 | Fixes continue in the stable branch until it is deemed ready to release (ideally after a short time)! At that point the new stable branch is tagged with the new version tag and the first stable release is made. 53 | 54 | ## Custom Builds 55 | 56 | A proposed strategy for branching on custom builds can be found [here](custom_build/ReleaseBranchingProcess.md). 57 | 58 | ## Process to create a new Stable 59 | 60 | ### Major/Minor Version 61 | 62 | 1. Create a branch from master named `Stable_VX.Y` where `X` is the major version number and `Y` is the minor version number. 63 | 1. Create a tag on the HEAD of master name `dX.Y` where the minor version is one greater than the new Stable. For example if you are create a new Stable 4.2 version then the tag would be 'd4.3'. This tag is used to create the version numbers for Android daily builds. Example: `git tag -a d4.3.0 -m "QGroundControl Daily Android Version Base"`. 64 | 1. Create an annotated tag on the newly created Stable branch named `vX.Y.0` with the correct major/minor version number. Example: `git tag -a v4.2.0 -m "QGroundControl v4.2.0"`. Pushing this tag to the repo will start a build. 65 | 1. Once the build completes verify the builds are pushed up to S3 correctly and sanity check that they at least boot correctly. Location on S3 will be `https://qgroundcontrol.s3.us-west-2.amazonaws.com/latest/...`. 66 | 1. Update the `https://qgroundcontrol.s3.us-west-2.amazonaws.com/builds/latest/QGC.version.txt` text file to the latest Stable version. This will notify uses there is a new Stable available the next time they launch QGC. 67 | 68 | ### Patch Version 69 | 70 | Creating a new Patch Version is the same except you skip steps 1 and 2 and in step 3 you bump the patch version number up as needed. -------------------------------------------------------------------------------- /zh/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # 概要 2 | 3 | * [摘要](README.md) 4 | * [Getting Started with source & builds](getting_started/README.md) 5 | * [Build using Containers](getting_started/container.md) 6 | * [Using QGC on CentOS](getting_started/CentOS.md) 7 | * [QGC Release/Branching Process](ReleaseBranchingProcess.md) 8 | * [Communication Flow](communication_flow.md) 9 | * [Plugin Architecture](firmware_plugin.md) 10 | * [Class Hierarchy](classes/README.md) 11 | * [User Interface Design](ui_design/README.md) 12 | * [Multi-Device Design Pattern](ui_design/multi_device_pattern.md) 13 | * [Font and Colour Palette](ui_design/font_palette.md) 14 | * [UI Controls](ui_design/controls.md) 15 | * [Fact System](fact_system.md) 16 | * [Top Level Views](views/README.md) 17 | * [Settings View](views/settings.md) 18 | * [Setup View](views/setup.md) 19 | * [Plan View](views/plan.md) 20 | * [Dynamic UI for mission item editing](plan/MissionCommandTree.md) 21 | * [Fly View](views/fly.md) 22 | * [File Formats](file_formats/README.md) * [Parameters](file_formats/parameters.md) * [Plan](file_formats/plan.md) * [MAVLink Logs](file_formats/mavlink.md) 23 | * [Developer Tools](tools/README.md) 24 | * [Mock Link](tools/mock_link.md) 25 | * [Command Line Options](command_line_options.md) 26 | * [Custom Builds](custom_build/custom_build.md) 27 | * [Initial Repository Setup For Custom Build](custom_build/CreateRepos.md) 28 | * [Custom Build Plugins](custom_build/Plugins.md) 29 | * [Resources Overrides](custom_build/ResourceOverride.md) 30 | * [Customization](custom_build/customization.md) 31 | * [First Run Prompts](custom_build/FirstRunPrompts.md) 32 | * [Toolbar customization](custom_build/Toolbar.md) 33 | * [Fly View Customization](custom_build/FlyView.md) 34 | * [Release/Branching Process For Custom Builds](custom_build/ReleaseBranchingProcess.md) 35 | * [MAVLink](custom_build/mavlink.md) 36 | * [Code Submission](contribute/README.md) 37 | * [Developer Call](contribute/dev_call.md) 38 | * [Coding Style](contribute/coding_style.md) 39 | * [Unit Tests](contribute/unit_tests.md) 40 | * [Pull Requests](contribute/pull_requests.md) 41 | * [Licenses](contribute/licences.md) 42 | 43 | ## Dronecode快捷方式 44 | 45 | * [QGroundControl用户指南](https://docs.qgroundcontrol.com/en/) 46 | * [PX4用户指南](https://docs.px4.io/en/) 47 | * [PX4开发人员指南](https://dev.px4.io/en/) 48 | * [MAVLink指南](https://mavlink.io/en/) 49 | * [MAVSDK](https://mavsdk.mavlink.io/) 50 | * [Dronecode相机管理器](https://camera-manager.dronecode.org/en/) -------------------------------------------------------------------------------- /zh/classes/README.md: -------------------------------------------------------------------------------- 1 | # 类层次结构（上层） 2 | 3 | ## (LinkManager)链接管理器类，(LinkInterface)链接接口类 4 | 5 | QGC中的“链接”是QGC与载具间的一种特定类型的通信管道，例如串行端口或基于WiFi的UDP端口。 LinkInterface为所有链接的基类。 每个链接都在它自己的线程上运行，并将字节发送到MAVLinkProtocol。 6 | 7 | LinkManager类所生成对象管理系统中的所有打开链接。 `LinkManager`还通过串行和UDP链接管理自动连接 8 | 9 | ## MAVLink协议类 10 | 11 | 系统中有一个MAVLink协议对象。 它的功能是从链接获取传入的字节并将它们转换为MAVLink消息。 MAVLink HEARTBEAT消息被分发到Multi Vehicle Manager(多机管理类)。 所有MAVLink消息都将分发到与链接相对应的载具。 12 | 13 | ## (MultiVehicleManager)多机管理类 14 | 15 | 系统中有一个MultiVehicleManager多机管理类生成的对象, 当它接收到一个新的心跳包(通过心跳包里面的系统ID识别)，它会自动生成一个载具对象，来表示一个新的载具加入到系统。 'MultiVehicleManager'还可以保持对系统中所有载具的跟踪，对于激活状态的载具可以自由切换，而对于正在被移除的也能够正确处理。 16 | 17 | ## (Vehicle)载具类 18 | 19 | Vehicle类所生成的对象是QGC代码与物理载具通信的主要接口。 20 | 21 | 注意：还有一个与每个Vehicle相关联的UAS对象，这是一个已弃用的类，并且正逐渐被逐步淘汰，所有功能都转移到Vehicle类。 这里不应该添加新代码。 22 | 23 | ## (FirmwarePlugin)固件插件类，( FirmwarePluginManager)固件插件管理器类 24 | 25 | FirmwarePlugin类为固件插件的基类。 固件插件包含固件特定代码，因此Vehicle对象相对于它是识别的，支持UI的单个标准接口。 26 | 27 | FirmwarePluginManager是一个工厂类，它根据Vehicle类的成员MAV_AUTOPILOT / MAV_TYPE组合创建FirmwarePlugin类的实例。 -------------------------------------------------------------------------------- /zh/command_line_options.md: -------------------------------------------------------------------------------- 1 | # 命令行选项 2 | 3 | 您可以使用命令行选项启动QGroundControl。 这些用于启用日志记录，运行单元测试以及模拟不同的主机环境以进行测试。 4 | 5 | ## 使用选项启动QGroundControl 6 | 7 | 您需要打开命令提示符或终端，将目录更改为存储qgroundcontrol.exe的位置，然后运行它。 每个平台如下所示（使用--logging：full选项）： 8 | 9 | Windows命令提示符： 10 | 11 | ```bash 12 | cd "\Program Files (x86)\qgroundcontrol" 13 | qgroundcontrol --logging:full 14 | ``` 15 | 16 | OSX终端应用程序（应用程序/实用程序）： 17 | 18 | ```bash 19 | cd /Applications/qgroundcontrol.app/Contents/MacOS/ 20 | ./qgroundcontrol --logging:full 21 | ``` 22 | 23 | Linux终端： 24 | 25 | ```bash 26 | ./qgroundcontrol-start.sh --logging:full 27 | ``` 28 | 29 | ## 选项 30 | 31 | 选项/命令行参数列在下表中。 32 | 33 | | 选项 | 描述 | 34 | | ------------------------------------------------------- | ------------------------------------- | 35 | | ` 36 | clear-settings` | 清除应用程序设置（将QGroundControl恢复为默认设置）。 | 37 | | `logging:full` | 打开完整日志记录。 请参阅控制台日志记录 | 38 | | `logging:full,LinkManagerVerboseLog,ParameterLoaderLog` | 打开完整日志记录并关闭以下列出的以逗号分隔的日志记录选项。 | 39 | | `--llogging:LinkManagerLog,ParameterLoaderLog` | 打开指定的逗号分隔日志记录选项 | 40 | | `--unittest:name` | （仅限Debug构建）运行指定单元测试。 离开：运行所有测试的名称。 | 41 | | `--unittest-stress:name` | （仅限调试版本）连续运行指定的单元测试20次。 离开：运行所有测试的名称。 | 42 | | `-fake-mobile` | 模拟在移动设备上运行。 | 43 | | `--test-high-dpi` | 模拟在高DPI设备上运行QGroundControl。 | 44 | 45 | 笔记： 46 | 47 | * 单元测试自动包含在调试版本中（作为QGroundControl的一部分）。 QGroundControl在单元测试的控制下运行（它不能正常启动）。 -------------------------------------------------------------------------------- /zh/communication_flow.md: -------------------------------------------------------------------------------- 1 | # 通信流程 2 | 3 | 描述载具在自动连接期间进行的高级通信流程。 4 | 5 | * LinkManager always has a UDP port open waiting for a vehicle heartbeat 6 | * LinkManager detects a new known device type (Pixhawk, SiK Radio, PX4 Flow) that makes a UDP connection to the computer 7 | * LinkManager creates a new SerialLink between the computer and the device 8 | * Incoming bytes from the Link are sent to MAVLinkProtocol 9 | * MAVLinkProtocol将字节转换为MAVLink消息 10 | * 如果消息是HEARTBEAT，则通知MultiVehicleManager(多机管理类) 11 | * MultiVehicleManager is notified of the `HEARTBEAT` and creates a new vehicle object based on the information in the `HEARTBEAT` message 12 | * The vehicle object instantiates the plugins that matches the vehicle 13 | * The ParameterLoader associated with the vehicle object sends a `PARAM_REQUEST_LIST` to the connected device to load parameters using the parameter protocol 14 | * Once the parameter load is complete, the MissionManager associated with the vehicle object requests the mission items from the connected device using the mission protocol 15 | * 当参数加载完成后，VehicleComponents对象将在Setup视图中显示其UI -------------------------------------------------------------------------------- /zh/contribute/README.md: -------------------------------------------------------------------------------- 1 | # 代码提交 2 | 3 | 本节包含有关贡献代码的主题，包括编码风格，测试和拉取请求的格式。 4 | 5 | > 注意: QGroundControl（QGC）作为Apache 2.0和GPLv3双重许可。 所有代码贡献都必须在两个许可证下进行。 -------------------------------------------------------------------------------- /zh/contribute/coding_style.md: -------------------------------------------------------------------------------- 1 | # 编码风格 2 | 3 | 高级样式信息： 4 | 5 | * 标签扩展到4个空格 6 | * Pascal / CamelCase命名约定 7 | 8 | 样式本身是以下示例文件中的文档： 9 | 10 | * [CodingStyle.cc](https://github.com/mavlink/qgroundcontrol/blob/master/CodingStyle.cc) 11 | * [CodingStyle.h](https://github.com/mavlink/qgroundcontrol/blob/master/CodingStyle.h) 12 | * [CodingStyle.qml](https://github.com/mavlink/qgroundcontrol/blob/master/CodingStyle.qml) -------------------------------------------------------------------------------- /zh/contribute/dev_call.md: -------------------------------------------------------------------------------- 1 | # Bi-Weekly Dev Call 2 | 3 | The QGroundControl developer team syncs up on technical details and in-depth analysis. There is also a space in the agenda to discuss pull requests, major impacting issues and Q&A. 4 | 5 | ## Who Should attend: 6 | * Community members 7 | * Core project maintiners 8 | * Component maintainers 9 | * Dronecode members 10 | 11 | 12 | > **Note** The calls are open for anyone interested to attend, it's a great opportunity to meet the team and contribute to the ongoing development of the project. 13 | 14 | ## What gets discussed? 15 | The main agenda for the call is very simple, and usually remains the same with a few exceptions which are made aware to the community in advance. The calls typically last up to 60 minutes. 16 | 17 | The developer team goes through the issue tracker, including the current queue of Pull Requests, 18 | 19 | ## Agenda 20 | While the agenda below is the norm, we might 21 | * Community Q&A (Open mic, you can bring your own topics, we can discuss your PRs/Issues/Questions) 22 | * Update on the project [High Priority Issues](https://github.com/mavlink/qgroundcontrol/projects/2) tracker 23 | * Developer team coordination 24 | 25 | > **Note** If you want to guarantee your Pull Request get's discussed on the next developer call, make sure you add the "dev-call" label on GitHub. We expect the author and the assigned reviewer to be on the call. 26 | 27 | ## Schedule 28 | * Time: Bi-Weekly on Tuesdays at 17h00 CET, 12h00 EST, 08h00 PST ([subscribe to the calendar](https://www.dronecode.org/calendar/)) 29 | * The call is hosted on Jitsi the open platform ([QGC Bi-Weekly](https://meet.jit.si/GCS-bi-weekly)) 30 | * the Agenda is published on the [PX4 Discuss - weekly-dev-call](https://discuss.px4.io/c/weekly-dev-call/qgc-developer-call/48) 31 | -------------------------------------------------------------------------------- /zh/contribute/licences.md: -------------------------------------------------------------------------------- 1 | # 许可证 2 | 3 | ## QGroundControl许可证 4 | 5 | QGroundControl（QGC）作为Apache 2.0和GPLv3双重许可。 所有捐款都必须在两个许可证下进行。 用户可以在任一许可下免费使用它。 6 | 7 | > 警告QGroundControl许可证排除重用任何Copyleft（例如GPL）许可代码。 所有贡献必须是原始的或来自兼容的许可（BSD 2/3条款，麻省理工学院，Apache 2.0）。 8 | 9 | 双重方法是必要的，以便能够通过iOS和Android应用程序商店提供QGroundControl，并提供开源社区用户选择 10 | 11 | ### Apache 2.0许可证 12 | 13 | Apache 2.0许可证是一种权限许可证，允许在任何环境（包括专有应用程序）中构建和使用QGC。 它允许为移动应用程序商店构建QGC。 使用Apache 2.0构建时，需要商业Qt许可证。 14 | 15 | ### GPL v3许可证 16 | 17 | GPL v3许可证是强大的著作权许可证。 在此许可下构建QGC时，可以使用Qt的开源版本。 我们的许可授予使用更高版本许可的许可，但是，必须在3.0下做出贡献。 18 | 19 | ## 文档，图稿，图像 20 | 21 | QGroundControl文档，图稿和图像根据CC BY 4.0获得许可。 22 | 23 | ## 也可以看看 24 | 25 | * [qgroundcontrol/COPYING.md](https://github.com/mavlink/qgroundcontrol/blob/master/COPYING.md) 26 | * [qgroundcontrol/CONTRIBUTING.md](https://github.com/mavlink/qgroundcontrol/blob/master/CONTRIBUTING.md) 27 | * [qgc-user-guide/LICENSE](https://github.com/mavlink/qgc-user-guide/blob/master/LICENSE) 28 | * [qgc-dev-guide/LICENSE](https://github.com/mavlink/qgc-dev-guide/blob/master/LICENSE) -------------------------------------------------------------------------------- /zh/contribute/pull_requests.md: -------------------------------------------------------------------------------- 1 | # Pull Requests 2 | 3 | 所有拉取请求都通过QGC CI构建系统，该系统构建版本和调试版本。 如果存在编译器警告，则构建将失败。 还针对支持的OS调试版本运行单元测试。 -------------------------------------------------------------------------------- /zh/contribute/unit_tests.md: -------------------------------------------------------------------------------- 1 | # 单元测试 2 | 3 | *QGroundControl* (QGC) contains a set of unit tests that must pass before a pull request will be accepted. 向QGC添加新的复杂子系统应该有相应的新单元测试来测试它。 4 | 5 | 单元测试的完整列表可以在UnitTestList.cc中找到。 6 | 7 | 要运行单元测试： 8 | 9 | 1. 使用UNITTEST_BUILD定义在调试模式下构建。 10 | 2. 复制debug目录中的deploy / qgroundcontrol-start.sh脚本 11 | 3. 使用--unittest命令行选项从命令行运行所有单元测试。 对于Linux，这是完成如下所示： ```qgroundcontrol-start.sh --unittest``` 12 | 4. 通过指定测试名称来运行单个单元测试： - unittest：RadioConfigTest。 对于Linux，这是完成如下所示： ```qgroundcontrol-start.sh --unittest:RadioConfigTest``` -------------------------------------------------------------------------------- /zh/custom_build/CreateRepos.md: -------------------------------------------------------------------------------- 1 | # Initial Repository Setup For Custom Build 2 | 3 | The suggested mechanism for working on QGC and a custom build version of QGC is to have two separate repositories. The first repo is your main QGC fork. The second repo is your custom build repo. 4 | 5 | ## Main QGC Respository 6 | 7 | This repo is used to work on changes to mainline QGC. When creating your own custom build it is not uncommon to discover that you may need a tweak/addition to the custom build to achieve what you want. By discussing those needed changes firsthand with QGC devs and submitting pulls to make the custom build architecture better you make QGC more powerful for everyone and give back to the community. 8 | 9 | The best way to create this repo is to fork the regular QGC repo to your own GitHub account. 10 | 11 | ## Custom Build Repository 12 | 13 | This is where you will do your main custom build development. All changes here should be within the custom directory as opposed to bleeding out into the regular QGC codebase. 14 | 15 | Since you can only fork a repo once, the way to create this repo is to "Create a new repository" in your GitHub account. Do not add any additional files to it like gitignore, readme's and so forth. Once it is created you will be given the option to setup up the Repo. Now you can select to "import code from another repository". Just import the regular QGC repo using the "Import Code" button. 16 | -------------------------------------------------------------------------------- /zh/custom_build/FirstRunPrompts.md: -------------------------------------------------------------------------------- 1 | # First Run Prompts 2 | 3 | When QGC is started for the first time it prompts the user to specify some initial settings. At the time of writing this documentation those are: 4 | 5 | * Unit Settings - What units does the user want to use for display. 6 | * Offline Vehicle Settings - Vehicle information for creating Plans while not connected to a vehicle. 7 | 8 | The custom build architecure includes mechanisms for a custom build to both override the display of these prompts and/or create your own first run prompts. 9 | 10 | ## First Run Prompt Dialog 11 | Each first run prompt is a simple dialog which can display ui to the user. Whether the specific dialog has already been show to the user or not is stored in a setting. Here is the code for the upstream first run prompt dialogs: 12 | 13 | * [Units Settings](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirstRunPromptDialogs/UnitsFirstRunPrompt.qml) 14 | * [Offline Vehicle Settings](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirstRunPromptDialogs/OfflineVehicleFirstRunPrompt.qml) 15 | 16 | ## Standard First Run Prompt Dialogs 17 | Each dialog has a unique ID associated with it. When that dialog is shown to the user that ID is registered as having already been displayed so it only happens once (unless you clear settings). The set of first run prompt which are included with upstream QGC are considered the "Standard" set. QGC gets the list of standard prompts to display from the `QGCCorePlugin::firstRunPromptStdIds` call. 18 | 19 | ``` 20 | /// Returns the standard list of first run prompt ids for possible display. Actual display is based on the 21 | /// current AppSettings::firstRunPromptIds value. The order of this list also determines the order the prompts 22 | /// will be displayed in. 23 | virtual QList firstRunPromptStdIds(void); 24 | ``` 25 | 26 | You can override this method in your custom build if you want to hide some of those. 27 | 28 | ## Custom First Run Prompt Dialogs 29 | Custom builds have the ability to create their own set of additional first run prompts as needed through the use of the following QGCCorePlugin method overrides: 30 | 31 | ``` 32 | /// Returns the custom build list of first run prompt ids for possible display. Actual display is based on the 33 | /// current AppSettings::firstRunPromptIds value. The order of this list also determines the order the prompts 34 | /// will be displayed in. 35 | virtual QList firstRunPromptCustomIds(void); 36 | ``` 37 | ``` 38 | /// Returns the resource which contains the specified first run prompt for display 39 | Q_INVOKABLE virtual QString firstRunPromptResource(int id); 40 | ``` 41 | 42 | Your QGCCorePlugin should override these two methods as well as provide static consts for the ids of your new first run prompts. Look at how the standard set is implemented for how to do this and take the same approach. 43 | 44 | ## Order Of Display 45 | The set of first run prompts shown to the user are in the order returned by the `QGCCorePlugin::firstRunPromptStdIds` and `QGCCorePlugin::firstRunPromptCustomIds` with standard prompts shown before the custom prompts. Only the prompts which have not been previously shown to the user are shown. 46 | 47 | ## Always On Prompts 48 | By setting the `markAsShownOnClose: false` property in your prompt ui implementation you can create a prompt which will show up each time QGC starts. This can be used for things like showing usage tips to your users. If you do this it is best to make sure that this is displayed last. -------------------------------------------------------------------------------- /zh/custom_build/FlyView.md: -------------------------------------------------------------------------------- 1 | # Fly View Customization 2 | 3 | The Fly View is designed in such a way that it can be cusomtized in multiple ways from simple to more complex. It is designed in three separate layers each of which are customizable providing different levels of change. 4 | 5 | 6 | ## Layers 7 | 8 | * There are three layers to the fly view from top to bottom visually: 9 | * [`FlyView.qml`](https://github.com/mavlink/qgroundcontrol/blob/master/src/FlightDisplay/FlyView.qml) This is the base layer of ui and business logic to control map and video switching. 10 | * [`FlyViewWidgetsOverlay.qml`](https://github.com/mavlink/qgroundcontrol/blob/master/src/FlightDisplay/FlyViewWidgetLayer.qml) This layer includes all the remaining widgets for the fly view. 11 | * [`FlyViewCustomLayer.qml`](https://github.com/mavlink/qgroundcontrol/blob/master/src/FlightDisplay/FlyViewCustomLayer.qml) This is a layer you override using resource override to add your own custom layer. 12 | 13 | ### Inset Negotiation using `QGCToolInsets` 14 | An important aspect of the Fly View is that it needs to understand how much central space it has in the middle of it's map window which is not obstructed by ui widgets which are at the edges of the window. It uses this information to pan the map when the vehicle goes out of view. This need to be done not only for the window edges but also for the widgets themselve such that the map pans before it goes under a widget. 15 | 16 | This is done through the use of the [`QGCToolInsets`](https://github.com/mavlink/qgroundcontrol/blob/master/src/QmlControls/QGCToolInsets.qml) object included in each layer. This objects provides inset information for each window edge informing the system as to how much real estate is taken up by edge based ui. Each layer is given the insets of the layer below it through `parentToolInsets` and then reports back the new insets taking into account the layer below and it's own additions through `toolInsets`. The final results total inset is then given to the map so it can do the right thing. The best way to understand this is to look at both the upstream and custom example code. 17 | 18 | ### `FlyView.qml` 19 | The base layer for the view is also the most complex from ui interactions and business logic. It includes the main display elements of map and video as well as the guided controls. Although you can resource override this layer it is not recommended. And if you do you better really (really) know what you are doing. The reason it is a separate layer is to make the layer above much simpler and easier to customize. 20 | 21 | ### `FlyViewWidgetsOverlay.qml` 22 | This layer contains all the remaining controls of the fly view. You have the ability to hide the controls through use of [`QGCFlyViewOptions`](https://github.com/mavlink/qgroundcontrol/blob/master/src/api/QGCOptions.h). But in order to change the layout of the upstream controls you must use a resource override. If you look at the source you'll see that the controls themselves are well encapsulated such that it should not be that difficult to create your own override which repositions them and/or adds your own ui. While maintaining a connection to the upstream implementaions of the controls. 23 | 24 | ### `FlyViewCustomLayer.qml` 25 | This provides the simplest customization ability to the Fly View. Allowing you the add ui elements which are additive to the existing upstream controls. The upstream code adds no ui elements and is meant to be the basis for your own custom code used as a resource override for this qml. The custom example code provides you with an example of how to do it. 26 | 27 | ## Recommendations 28 | 29 | ### Simple customization 30 | The best place to start is using a custom layer override plus turning off ui elements from the widgets layer (if needed). I would recommend trying to stick with only this if at all possible. It provides the greatest abilty to not get screwed by upstream changes in the layers below. 31 | 32 | ### Moderate complexity customization 33 | If you really need to reposition upstream ui elements then your only choice is overriding `FlyViewWidgetsOverlay.qml`. By doing this you are distancing yourself a bit from upstream changes. Although you will still get changes in the upstream controls for free. If there is a whole new control added to the fly view upstream you won't get it until you add it to your own override. 34 | 35 | ### Highly complex customization 36 | The last and least recommended customization mechanism is overriding `FlyView.qml`. By doing this you are distancing yourself even further from getting upstream changes for free. -------------------------------------------------------------------------------- /zh/custom_build/GitBranching.md: -------------------------------------------------------------------------------- 1 | # Git Branching Strategy for Custom Builds 2 | 3 | You are welcome to use whatever branching and release strategy you want for your custom builds! However we strongly recommend that you layer on top of the standard QGC git/release strategy, as this will almost certainly reduce your effort and keep quality high. 4 | 5 | ## Simplest Strategy 6 | 7 | The simplest approach is to mirror the [QGC Git Branching process](GitBranching.md), timing your releases to fall after QGC releases. This means you release your custom builds only after upstream QGC releases it's own builds. 8 | 9 | The next part of the document outlines how you do this. Out-of-band releases are discussed [near the end](#out_of_band). 10 | 11 | ## Daily Builds 12 | 13 | ### Development Stage 14 | 15 | Your custom daily builds are built from master and this is where all new major feature development happens. 16 | 17 | You must keep custom master up to date with QGC master! It is important to not lag behind, because new upstream features may require some effort to integrate with your build, or may even require changes to "core" QGC in order to work with your code. If you don't let QGC development team know soon enough, it may end up being too late to get things changed. 18 | 19 | 20 | ## Stable Builds 21 | 22 | ### Release Stage 23 | 24 | You can do a patch release following QGC patch releases. 25 | 26 | The process of stablization, branching and tagging should match the upstream process. Your release branch should be created from the upstream stable branch and only be synced with the upstream stable branch to bring across patches. You can apply your own patches to your code in that branch as well as needed. 27 | 28 | ### Patch Releases 29 | 30 | Your custom patch releases should be built from your own stable branches. Make sure again to keep your stable branch in sync with upstream stable (or you will miss fixes). 31 | 32 | Since upstream stable is always at high quality you can release your own patches based on upstream stable HEAD at any time you want (there is no need to wait on QGC to release it's next patch release). 33 | 34 | ### Out Of Band Release {#out_of_band} 35 | 36 | An "Out of band" release is one where you want to release some of your next features prior to upstream QGC doing a patch release. In this case you create the branch for your own patch release off of your latest stable branch prior to doing any development. You then do your new feature development in that branch. 37 | 38 | You should continue to keep this branch in sync with the associated upstream stable branch. When you are ready to release you just go through the normal tagging release process. 39 | 40 | ## Never Release Custom Stable Builds off QGC Master 41 | 42 | You should never release any of your custom stable builds based on upstream QGC master. 43 | 44 | If you do you will have no idea of the quality of that release since, although upstream daily build quality is fairly high, it is not as good as the upstream stable quality. 45 | -------------------------------------------------------------------------------- /zh/custom_build/Plugins.md: -------------------------------------------------------------------------------- 1 | # Custom Build Plugins 2 | 3 | The mechanisms for customizing QGC for a custom build is through the existing `FirmwarePlugin`, `AutoPilotPlugin` and `QGCCorePlugin` architectures. By creating subclasses of these plugins in your custom build you can change the behavior of QGC to suit your needs without needed to modify the upstream code. 4 | 5 | 6 | ## QGCCorePlugin 7 | 8 | This allows you to modify the parts of QGC which are not directly related to vehicle but are related to the QGC application itself. This includes things like application settings, color palettes, branding and so forth. -------------------------------------------------------------------------------- /zh/custom_build/ReleaseBranchingProcess.md: -------------------------------------------------------------------------------- 1 | # Release Process for Custom Builds [WIP Docs] 2 | 3 | One of the trickier aspects of creating your own custom build is the process to keep it up to date with regular QGC. This document describes a suggested process to follow. But in reality you are welcome to use whatever branching and release strategy you want for your custom builds. 4 | 5 | ## Upstream QGC release/branching strategy 6 | The best place to start is understanding the mechanism QGC uses to do it's own releases. We will layer a custom build release process on top of that. You can find standard QGC [release process here](../ReleaseBranchingProcess.md). 7 | 8 | ## Custom build/release types 9 | Regular QGC has two main build types: Stable and Daily. The build type for a custom build is more complex. Throughout this discussion we will use the term "upstream" to refer to the main QGC repo (https://github.com/mavlink/qgroundcontrol). Also when we talk about a "new" upstream stable release, this means a major/minor release, not a patch release. 10 | 11 | ### Synchronized Stable 12 | This type of release is synchronized with the release of an upstream stable. Once QGC releases stable you then release a version of your custom build which is based on this stable. This build will include all the new features from upstream including the new feature in your own custom code. 13 | 14 | ### Out-Of-Band Stable 15 | This a subsequent release of your custom build after you have released a synchronized stable but prior to upstream releasing a new stable. It only includes new features from your own custom build and include no new features from upstream. Work on this type of release would occur on a branch which is either based on your latest synchronized stable or your last out of band release if it exists. You can release out of band stable releases at any time past your first synchronized stable release. 16 | 17 | ### Daily 18 | Your custom daily builds are built from your `master` branch. It is important to keep your custom master up to date with QGC master. If you lag behind you may be surprised by upstream features which require some effort to integrate with your build. Or you may even require changes to "core" QGC in order to work with your code. If you don't let QGC development team know soon enough, it may end up being too late to get things changed. 19 | 20 | ## Options for your first build 21 | ### Starting with a Synchronized Stable release 22 | It is suggested that you start with releasing a Synchronized Stable. This isn't necessary but it is the simplest way to get started. To set your self up for a synchronized stable you create your own branch for development which is based on the upstream current stable. 23 | 24 | ### Starting with Daily builds 25 | The reason why you may consider this as your starting point is because you need features which are only in upstream master for your own custom builds. In this case you will have to live with releasing custom Daily builds until the next upstream stable. At which point you would release you first Synchronized Stable. For this setup you use your master branch and keep it in sync with upstream master as you develop. 26 | 27 | ## After you release your first Synchronized Stable 28 | 29 | ### Patch Releases 30 | As upstream QGC does patch releases on Stable you should also release your own patch releases based on upstream to keep your stable up to date with latest criticial bug fixes. 31 | 32 | ### Out-Of-Band, Daily: One or the other or both? 33 | At this point you can decide which type of releases you want to follow. You can also decide to possibly do both. You can do smaller new features which don't require new upstream features using out of band releases. And you can do major new feature work as daily/master until the point you can do a new synchronized stable. -------------------------------------------------------------------------------- /zh/custom_build/ResourceOverride.md: -------------------------------------------------------------------------------- 1 | # Resource Overrides 2 | 3 | A "resource" in QGC source code terminology is anything found in the [qgroundcontrol.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/qgroundcontrol.qrc) and [qgcresources.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/qgcresources.qrc) file. By overriding a resource you can replace it with your own version of it. This could be as simple as a single icon, or as complex as replacing an entire Vehicle Setup page of qml ui code. 4 | 5 | Be aware that using resource overrides does not isolate you from upstream QGC changes like the plugin architecture does. In a sense you are directly modify the upstream QGC resources used by the main code. 6 | 7 | ## Exclusion Files 8 | 9 | The first step to overriding a resource is to "exclude" it from the standard portion of the upstream build. This means that you are going to provide that resource in your own custom build resource file(s). There are two files which achieve this: [qgroundcontrol.exclusion]() and [qgcresources.exclusion](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/qgcresources.exclusion). They correspond directly with the *.qrc counterparts. In order to exclude a resource, copy the resource line from the .qrc file into the appropriate .exclusion file. 10 | 11 | ## Custom version of excluded resources 12 | 13 | You must include the custom version of the overriden resouce in you custom build resource file. The resource alias must exactly match the upstream alias. The name and actual location of the resource can be anywhere within your custom directory structure. 14 | 15 | ## Generating the new modified versions of standard QGC resource file 16 | 17 | This is done using the `updateqrc.py` python script. It will read the upstream `qgroundcontrol.qrc` and `qgcresources.qrc` file and the corresponding exclusion files and output new versions of these files in your custom directory. These new versions will not have the resources you specified to exclude in them. The build system for custom builds uses these generated files (if they exist) to build with instead of the upstream versions. The generated version of these file should be added to your repo. Also whenever you update the upstream portion of QGC in your custom repo you must re-run `python updateqrc.py` to generate new version of the files since the upstream resources may have changed. 18 | 19 | ## Custom Build Example 20 | 21 | You can see an examples of custom build qgcresource overrides in the repo custom build example: 22 | 23 | * [qgcresources.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/qgcresources.exclusion) 24 | * [custom.qrc](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/custom.qrc) 25 | -------------------------------------------------------------------------------- /zh/custom_build/Toolbar.md: -------------------------------------------------------------------------------- 1 | # Toolbar Customization 2 | The toolbar can be customized in a number of ways to fit your custom build needs. The toolbar internally is made up of a number of sections from left to right: 3 | 4 | * View Switching 5 | * Indicators 6 | * App Indicators 7 | * Vehicle Indicators 8 | * Vehicle Mode Indicators 9 | * Connection Management 10 | * Branding 11 | 12 | The Indicator section varies based on the view currently displayed: 13 | 14 | * Fly View - Shows all indicators 15 | * Plan View - Show no indicators and has its own custom indicator section for Plan status values 16 | * Other Views - Do not show Vehicle Mode Indicators 17 | 18 | ## Customization Possibilities 19 | 20 | ### Indicators 21 | 22 | You can add your own indicators for display or remove any of the upstream indicators. The mechanism you use depends on the indicator type. 23 | 24 | #### App Indicators 25 | These provide information to the user which is not associated with a vehicle. For example RTK status. To manipulate the list of app indicators you use `QGCPlugin::toolbarIndicators`. 26 | 27 | #### Vehicle Indicators 28 | These are indicators which are associated with information about the vehicle. They are only available when a vehicle is connected. To manipulate the list of vehicle indicators you override `FirmwarePlugin::toolIndicators`. 29 | 30 | #### Vehicle Mode Indicators 31 | These are indicators which are associated with information about the vehicle. They require additional UI provided by the Fly View to complete their actions. An example is Arming and Disarming. They are only available when a vehicle is connected. To manipulate the list of vehicle mode indicators you override `FirmwarePlugin::modeIndicators`. 32 | 33 | ### Modifying the toolbar UI itself 34 | This is accomplished by using resource overrides on the qml files associated with the toolbar. This provides a high level of customization but also a higher level of complexity. The primary ui for the toolbar is in `MainToolBar.qml`. The main window code in `MainRootWindow.qml` interacts with the toolbar to show different indicator sections based on current view as well as whether the mode indicators show or not also based on current view. 35 | 36 | If you want full control over the toolbar then you can override `MainToolBar.qml` and make your own completely different version. You will need to pay special attention to the interactions of the main toolbar with `MainRootWindow.qml` since you are going to need to replicated those interactions in your own custom version. 37 | 38 | There are two standard indicator ui sections of the toolbar: 39 | 40 | #### `MainToolBarIndicators.qml` 41 | This is used for all views except Plan. It display all the indicators in a row. Although you can override this file, in reality it doesn't do much other than layout for indicators. 42 | 43 | #### `PlanToolBarIndicators.qml` 44 | This is used by the Plan view to show the status values. If you want to change that ui you can override this file and provide your own custom version. -------------------------------------------------------------------------------- /zh/custom_build/custom_build.md: -------------------------------------------------------------------------------- 1 | # 自定义构建 2 | 3 | 自定义构建允许第三方创建自己的QGC版本，使其能够轻松跟上常规QGC中所做的更改。 QGC has an architecture built into it which allows custom builds to modify and add to the feature set of regular QGC. 4 | 5 | Some possibilities with a custom build 6 | 7 | * Fully brand your build 8 | * Define a single flight stack to avoid carrying over unnecessary code 9 | * Implement your own, autopilot and firmware plugin overrides 10 | * Implement your own camera manager and plugin overrides 11 | * Implement your own QtQuick interface module 12 | * Implement your own toolbar, toolbar indicators and UI navigation 13 | * Implement your own Fly View overlay (and how to hide elements from QGC such as the flight widget) 14 | * Implement your own, custom QtQuick camera control 15 | * Implement your own, custom Pre-flight Checklist 16 | * Define your own resources for all of the above 17 | 18 | One of the downsides of QGC providing both generic support for any vehicle which supports mavlink as well as providing firmware specific support for both PX4 Pro and ArduPilot is complexity of the user interface. Since QGC doesn't know any information about your vehicle ahead of time it requires UI bits which can get in the way if the vehicle you fly only uses PX4 Pro firmware and is a multi-rotor vehicle. If that is a known thing then the UI can be simplified in various places. Also QGC targets both DIY users who are building their own vehicles from scratch as well as commercial users of off the shelf vehicles. Setting up a DIY drone from scratch requires all sort of functionality which is not needed for users of off the shelf vehicles. So for off the shelf vehicle users all the DIY specific stuff is just extra noise they need to look past. Creating a custom build allows you to specify exact details for your vehicle and hide things which are irrelevant thus creating an even simple user experience for your users than regular generic QGC. 19 | 20 | There is a plugin architecture in QGC which allows for this custom build creation. They can be found in QGCCorePlugin.h, FirmwarePlugin.h and AutoPilotPlugin.h associated classes. To create a custom build you create subclasses of the standard plugins overriding the set of methods which are appropriate for you usage. 21 | 22 | There is also a mechanism which allows you to override resources so you can change the smaller visual elements in QGC. 23 | 24 | Also internal to QGC is the concept of an "Advanced Mode". Whereas a standard QGC builds always runs in advanced mode. A custom build always starts out in regular/not advanced mode. There is an easier mechanism in the build to turn on advanced mode which is to click the fly view button 5 times in a row fairly quickly. If you do this in a custom build you will be warned about entering advanced mode. The concept here is to hide things which normal users should not have access to behind advanced mode. For example a commercial vehicle will not need access to most setup pages which are oriented to DIY setup. So a custom build can hide this. The custom example code shows how to do this. 25 | 26 | If you want to understand the possibilities, the first step is to read through those files which document what is possible. Next look through the [ 27 | 28 | custom-example](https://github.com/mavlink/qgroundcontrol/tree/master/custom-example) source code including the 29 | 30 | [README](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/README.md). -------------------------------------------------------------------------------- /zh/custom_build/customization.md: -------------------------------------------------------------------------------- 1 | # Customization 2 | 3 | The following topics explain how to customise various views and other parts of the UI. 4 | 5 | * [First Run Prompts](../custom_build/FirstRunPrompts.md) 6 | * [Toolbar customization](../custom_build/Toolbar.md) 7 | * [Fly View Customization](../custom_build/FlyView.md) -------------------------------------------------------------------------------- /zh/custom_build/mavlink.md: -------------------------------------------------------------------------------- 1 | # MAVLink Customisation 2 | 3 | QGC communicates with flight stacks using [MAVLink](https://mavlink.io/en/), a very lightweight messaging protocol that has been designed for the drone ecosystem. 4 | 5 | QGC includes the [all.xml](https://mavlink.io/en/messages/all.html) dialect by default. The `all.xml` includes all other dialects in the [mavlink/mavlink](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0) repository, and allows it to communicate with both PX4 and Ardupilot. Previous versions of QGC (v4.2.8 and earlier), used the `ArduPilotMega.xml` dialect. 6 | 7 | In order to add support for a new set of messages you should add them to [development.xml](https://mavlink.io/en/messages/development.html), [ArduPilotMega.xml](https://mavlink.io/en/messages/ardupilotmega.html), or [common.xml](https://mavlink.io/en/messages/common.html) (for PX4), or fork *QGroundControl* and include your own dialect. 8 | 9 | To modify the version of MAVLink used by QGC: 10 | 11 | - Replace the pre-build C library at [/qgroundcontrol/libs/mavlink/include/mavlink](https://github.com/mavlink/qgroundcontrol/tree/master/libs/mavlink/include/mavlink). 12 | - By default this is a submodule importing https://github.com/mavlink/c_library_v2 13 | - You can change the submodule, or [build your own libraries](https://mavlink.io/en/getting_started/generate_libraries.html) using the MAVLink toolchain. 14 | - You can change the whole dialect used by setting it in [`MAVLINK_CONF`](https://github.com/mavlink/qgroundcontrol/blob/master/QGCExternalLibs.pri#L52) when running *qmake*. 15 | 16 | -------------------------------------------------------------------------------- /zh/custom_build/upstream_merge.md: -------------------------------------------------------------------------------- 1 | # 使您的自定义构建保持最新 2 | 3 | ## 存储库设置 4 | 5 | * 从主QGC仓库创建一个新的存储库。 不要克隆，创建新的仓库，从主QGC仓库初始化它。 6 | * 您现在可以克隆上面的仓库来完成您的工作并从中创建pull请求。 7 | * 在你的克隆中创建一个叫做“mavlink”的远程，指向主QGC 仓库. 8 | * git remote add mavlink https://github.com/mavlink/qgroundcontrol.git 9 | 10 | ## 上游合并 11 | 12 | 我们将更新您的自定义构建的过程称为最新的QGC位和“上游合并”。 以下是如何执行此操作的示例： 13 | 14 | * 首先确保您的本地主人与您自己的回购主人是最新的。 15 | * 创建一个分支以进行所有更改： 16 | * git checkout -b UpstreamMerge 17 | 18 | * 从QGC中提取最新的位： 19 | * git pull mavlink master 20 | 21 | * 您将获得一个编辑器来更新合并更新。 他们很好，只是 ```:q``` 为了退出 22 | * 现在，您需要更新自定义构建中的资源： 23 | * cd custom 24 | 25 | * python updateqrc.py 26 | 27 | * 全部构建以确保没有问题。 28 | * 你现在完成了。 您可以将其作为针对您的仓库的拉动提交，或者您希望将更改提交到主仓库中。 29 | 30 | 注意：这假设您的自定义构建基于QGC master。 如果它基于Stable分支，则使用稳定分支名称替换master。 -------------------------------------------------------------------------------- /zh/fact_system.md: -------------------------------------------------------------------------------- 1 | # Fact System(事实系统) 2 | 3 | Fact System(事实系统)提供一组标准化和简化QGC用户界面创建的功能。 4 | 5 | ## Fact {#fact} 6 | 7 | 事实代表系统中的单个值。 8 | 9 | ## FactMetaData 10 | 11 | 与每个事实有FactMetaData相关联 它提供有关事实的详细信息，以便驱动自动用户界面生成和验证。 12 | 13 | ## 事实控制 14 | 15 | 事实控件是一个QML用户界面控件，它连接到Fact和它的FactMetaData，为用户提供控件以修改/显示与Fact相关的值。 16 | 17 | ## FactGroup（事实小组） 18 | 19 | A *Fact Group* is a group of [Facts](#fact). It is used to organise facts and manage user defined facts. 20 | 21 | ## Custom Build Support 22 | 23 | User defined facts can be added by overriding `factGroups` function of `FirmwarePlugin` in a custom firmware plugin class. These functions return a name to fact group map that is used to identify added fact groups. A custom fact group can be added by extending `FactGroup` class. FactMetaDatas could be defined using the appopriate `FactGroup` constructor by providing a json file containing necessery information. 24 | 25 | Changing the metadata of existing facts is also possible by overriding `adjustMetaData` of `FirmwarePlugin` class. 26 | 27 | A fact associated with a vehicle (including facts belonging to fact groups returned in `factGroups` function of the vehicles Firmware plugin) can be reached using `getFact("factName")` or `getFact("factGroupName.factName")` 28 | 29 | For additional information please refer to comments in [FirmwarePlugin.h](https://github.com/mavlink/qgroundcontrol/blob/v4.0.8/src/FirmwarePlugin/FirmwarePlugin.h). -------------------------------------------------------------------------------- /zh/file_formats/README.md: -------------------------------------------------------------------------------- 1 | # 文件格式 2 | 3 | 本节包含有关QGroundControl使用/支持的文件格式的主题。 -------------------------------------------------------------------------------- /zh/file_formats/mavlink.md: -------------------------------------------------------------------------------- 1 | # MAVLink 日志格式 2 | 3 | *QGC 地面站* 能生成纯 MAVLink 数据包日志，并支持日志回放，以便飞行任务结束后查看任务执行状态来进行数据分析。 4 | 5 | 日志采用二进制格式，字节定义如下： 6 | 7 | * 字节 1-8：64位无符号整数，表示时间戳，单位为微秒，起始时间为Unix纪元（UTM时间1970年1月1日0时0分0秒） 8 | * 字节 9-271：MAVLink 数据包（数据包的最大长度为263字节，包括数据包起始标识。一般来说，数据包中的可用字节不会被实际数据全部填充，因此，数据包的实际长度会小于 263 字节 。 9 | 10 | ## 调试 11 | 12 | 若要检查数据, 请在以十六进制方式查看日志文件。 文件打开后，可在第九个字节的位置，找到 **0x55**。 前 8 个字节应转换为有效的时间戳，数值接近零或 **1294571828792000**（表示当前的 Unix 纪元时间戳（以微秒为单位）。 13 | 14 | ## 用于记录 MAVLink 的 C++ 例程 15 | 16 | 下面的代码段演示，如何使用 C++ 标准库中的 [C++ streams](http://www.cplusplus.com/reference/iostream/istream/) 实现日志记录。 17 | 18 | ```cpp 19 | //write into mavlink logfile 20 | const int len = MAVLINK_MAX_PACKET_LEN+sizeof(uint64_t); 21 | uint8_t buf[len]; 22 | uint64_t time = getSystemTimeUsecs(); 23 | memcpy(buf, (void*)&time, sizeof(uint64_t)); 24 | mavlink_msg_to_send_buffer(buf+sizeof(uint64_t), msg); 25 | mavlinkFile << buf << flush; 26 | ``` -------------------------------------------------------------------------------- /zh/file_formats/parameters.md: -------------------------------------------------------------------------------- 1 | # 参数文件格式 2 | 3 | # Onboard parameters for Vehicle 1 4 | # 5 | # # Vehicle-Id Component-Id Name Value Type 6 | 1 1 ACRO_LOCKING 0 2 7 | 1 1 ACRO_PITCH_RATE 180 4 8 | 1 1 ACRO_ROLL_RATE 180 4 9 | 1 1 ADSB_ENABLE 0 2 10 | 11 | 12 | 以上是具有四个参数的参数文件的示例。 该文件可以包含所需数量的参数。 13 | 14 | 评论之前是＃。 15 | 16 | 此标头：#MAV ID COMPONENT ID PARAM NAME VALUE描述每行的格式： 17 | 18 | * Vehicle-Id Vehicle id(载具编号） 19 | * Component-Id（参数的组件编号） 20 | * Name参数名称 21 | * Value参数值 22 | * 使用MAVLink MAV_PARAM_TYPE_ *枚举值键入参数类型 23 | 24 | 参数文件包含单个Vehicle的参数。 它可以包含该Vehicle中多个组件的参数。 -------------------------------------------------------------------------------- /zh/firmware_plugin.md: -------------------------------------------------------------------------------- 1 | # Plugin Architecture 2 | 3 | 虽然MAVLink规范定义了与载具通信的标准通信协议。 There are many aspects of that spec that are up for interpretation by the firmware developers. Because of this there are many cases where communication with a vehicle running one firmware is be slightly different than communication with a vehicle running a different firmware in order to accomplish the same task. Also each firmware may implement a different subset of the MAVLink command set. 4 | 5 | 另一个主要问题是MAVLink规范不包括载具配置或通用参数集。 Due to this all code which relates to vehicle setup ends up being firmware specific. 此外，任何必须引用特定参数的代码也是特定于固件的。 6 | 7 | 鉴于固件实现之间的所有这些差异，创建单个地面站应用程序可能非常棘手，可以支持每个应用程序而不会使代码库降级为基于车辆使用的固件在任何地方遍布的大量if / then / else语句。 8 | 9 | QGC uses a plugin architecture to isolate the firmware specific code from the code which is generic to all firmwares. There are two main plugins which accomplish this ```FirmwarePlugin``` and ```AutoPilotPlugin```. 10 | 11 | This plugin architecture is also used by custom builds to allow ever further customization beyond when standard QGC can provide. 12 | 13 | ## FirmwarePlugin 14 | 15 | This is used to create a standard interface to parts of Mavlink which are generally not standardized. 16 | 17 | ## AutoPilotPlugin 18 | 19 | This is used to provide the user interface for Vehicle Setup. 20 | 21 | ## QGCCorePlugin 22 | 23 | This is used to expose features of the QGC application itself which are not related to a Vehicle through a standard interface. This is then used by custom builds to adjust the QGC feature set to their needs. -------------------------------------------------------------------------------- /zh/getting_started/CentOS.md: -------------------------------------------------------------------------------- 1 | # 在 CentOS 7 上使用 QGC 2 | 3 | ## 安装操作系统 4 | 5 | 安装CentOS 7 6 | 7 | 1. 从这里获取最新[CentOS 7 ISO ](http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1810.iso) 8 | 2. 通过[following this guide](https://linuxize.com/post/how-to-create-a-bootable-centos-7-usb-stick/)制作一个 USB 启动盘。 9 | 3. 从USB启动盘中启动目标设备。 10 | 11 | 下面的示例将说明如何从USB启动盘启动目标设备。 12 | 13 | **Example：** *Panasonic Toughpad FZ-M1* （为方便遵循本指南操作，建议在设备上附上一个键盘和鼠标）。 14 | 15 | 1. 在附加的 USB 键盘上按住 **Delete** 键，或者在启动时按下电源按钮周围的所有按钮，便可进入BIOS 菜单。 16 | 2. 在 BIOS 菜单界面使用箭头键或触摸屏切换到 *Exit* 选项卡。 17 | 3. 从启动设备列表中，选择已插入的USB启动盘。 18 | 19 | **Example** [UAV 组件微导航](https://www.uavcomp.com/command-control/micronav/) 设备： 20 | 21 | 1. CentOS 不会以默认配置安装。 为解决这个问题，可进行如下操作： 22 | 1. 如上述的示例中所述，转到BIOS菜单。 23 | 2. 在“Advanced”选项卡下禁用“Extension Port”设备。 24 | 3. 在BIOS菜单的退出页面上选择“Exit and save”，然后从USB启动盘启动目标设备。 25 | 4. 在 CentOS 安装成功后，可再次恢复更改，以便微硬网络正常工作。 26 | 2. 如果想要重新进入Linux操作系统，请先关闭设备，而不是热重启。 否则微硬网络适配器将无法正常工作并怠速整个系统。 27 | 28 | ### CentOS 软件选择安装选项 29 | 30 | 这些都是用于安装CentOS开发系统的选项。 使用它作为指南。 31 | 32 | ![安装操作系统../Qt/5.12.4](../../assets/getting_started/centos/centos_installation.png) 33 | 34 | ![CentOS 软件选项](../../assets/getting_started/centos/centos_sw_selection.png) 35 | 36 | ### 更新 GStreamer 37 | 38 | CentOS 安装并启动后，我们需要为QGC 搭建环境。 首先，我们需要将GStreamer更新为最新版本。 本指南遵循Alice Wonder的提示：https://media.librelamp.com。 39 | 40 | sudo yum install epel-release -y 41 | wget http://awel.domblogger.net/7/media/x86_64/awel-media-release-7-6.noarch.rpm 42 | sudo yum localinstall awel-media-release-7-6.noarch.rpm -y 43 | sudo yum clean all 44 | sudo yum update 45 | sudo yum install gstreamer1* --skip-broken -y 46 | 47 | 48 | **Note:**确保如下组件已安装 (Intel GPUs的 vaapi) 49 | 50 | sudo yum install gstreamer1-vaapi 51 | sudo yum install gstreamer1-libav 52 | 53 | 54 | **Note:** Install these to enable hardware accelerated video decoding 55 | 56 | sudo yum install libva 57 | sudo yum install libva-utils 58 | sudo yum install libva-intel-driver 59 | 60 | 61 | If libva-intel-driver is not found you can download it and install it manually 62 | 63 | wget http://download1.rpmfusion.org/free/el/updates/7/x86_64/l/libva-intel-driver-1.8.3-4.el7.x86_64.rpm 64 | sudo yum localinstall libva-intel-driver-1.8.3-4.el7.x86_64.rpm -y 65 | 66 | 67 | ### 安装SDL2 68 | 69 | SDL2 is used for joystick support. 70 | 71 | sudo yum install SDL2 SDL2-devel -y 72 | 73 | 74 | ### 更新内核(可选) 75 | 76 | > **Tip**当运行命令`/dev/input/*` 时， 如果游戏杆被成功识别并显示为`/dev/input/js0` ，则可以跳过这一步。 77 | 78 | We recommend updating the kernel for: 79 | 80 | - 更好地触摸屏幕响应性能。 81 | - 正确识别某些USB设备 - 特别是游戏杆。 82 | 83 | The following joysticks are known not do work out of the box with the default CentOS 7 kernel (3.10.0): 84 | 85 | - Logitech F310 86 | - Microsoft Xbox 360 controller (USB) 87 | 88 | To fix the joystick not being recognized (even if the same unit is working under Windows or Ubuntu) please [follow this guide to update the kernel](https://www.howtoforge.com/tutorial/how-to-upgrade-kernel-in-centos-7-server/). 89 | 90 | Here's a short summary of the commands that you need to execute to update the kernel: 91 | 92 | sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org 93 | sudo rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm 94 | sudo yum --enablerepo=elrepo-kernel install kernel-ml -y 95 | 96 | 97 | Reboot your device afterwards and make sure the new kernel version shows up as the default start option in the GRUB menu on boot. 98 | 99 | > **Note** 您可能需要在 BIOS 中禁用安全启动才能启动新内核。 100 | 101 | ## 在 CentOS 上运行 QGC 102 | 103 | Before launching QGC, you need to make sure the current user has access to the dialout group (serial port access permission): 104 | 105 | sudo usermod -a -G dialout $USER 106 | 107 | 108 | ### 防火墙 109 | 110 | The default firewall security level of Red Hat distributions like CentOS block MAVLink communication and also the camera video stream. So you need to create rules to open the incoming ports for MAVLink and camera stream. For non-production local environment testing purposes ONLY you can temporarily disable the firewall using the following commands ([from here](https://www.liquidweb.com/kb/how-to-stop-and-disable-firewalld-on-centos-7/)): 111 | 112 | Temporary: 113 | 114 | systemctl stop firewalld 115 | 116 | 117 | Permanent (at your own risk): 118 | 119 | systemctl disable firewalld 120 | 121 | 122 | Undo permanent change: 123 | 124 | systemctl enable firewalld 125 | 126 | 127 | ### 与多网络的连接问题 128 | 129 | In our test with CentOS we had problems when connecting to multiple networks through multiple network devices even with appropriate IP address and subnet assignment. 130 | 131 | Issues consisted of: 132 | 133 | - 连接到第二个网络时失去互联网连接 134 | - 与载具的连接质量不佳，存在有大量不确定非再现问题和包丢失（例如，在常规模式中， 30秒完美连接，4秒丢失数据包) 135 | 136 | If you face any of these problems avoid them by only connecting one network at a time e.g. switching between WiFi and Microhard. 137 | 138 | ### 执行预构建的 QGC 二进制文件 139 | 140 | - 为CentOS保留包含预构建的QGC二进制文件的归档。 目前，这个构建没有自动部署，如果您迫切需要，请与开发者取得联系，。 141 | - [解压归档](https://www.hostdime.com/kb/hd/command-line/how-to-tar-untar-and-zip-files) 142 | - 从解压文件里找到脚本文件`qgroundcontrol-run.sh` 143 | - 输入如下命令，运行该脚本 144 | 145 | ./qgroundcontrol-run.sh 146 | ``` 147 | 148 | ## Building QGC on CentOS 149 | 150 | ### Installing Qt 151 | 152 | 153 | mkdir ~/devel cd ~/devel 154 | 155 |
Install Qt 5.12.4 from the Qt installation script that can be downloaded [here](https://www.qt.io/download-thank-you?os=linux&hsLang=en). 156 | Once downloaded, make it executable and run it: 157 | 158 | 159 | chmod +x qt-unified-linux-x64-3.1.1-online.run ./qt-unified-linux-x64-3.1.1-online.run 160 | 161 |
Select the following options and install it under `~/devel/Qt`: 162 | 163 | ![Qt Software Selection](../../assets/getting_started/centos/qt_setup.png) 164 | 165 | ### Clone and Build QGC 166 | 167 | 168 | 169 | git clone --recursive https://github.com/mavlink/qgroundcontrol.git mkdir build cd build 170 | 171 | For a debug/test build: 172 | 173 | 174 | ../Qt/5.12.4/gcc_64/bin/qmake ../qgroundcontrol/qgroundcontrol.pro -spec linux-g++ CONFIG+=debug 175 | 176 | For a release build: 177 | 178 | 179 | ../Qt/5.12.4/gcc_64/bin/qmake ../qgroundcontrol/qgroundcontrol.pro -spec linux-g++ CONFIG+=qtquickcompiler 180 | 181 | Build it: 182 | 183 | 184 | make -j4 ``` 185 | 186 | You can alternatively launch *QtCreator* (found under `~/devel/Qt/Tools/QtCreator/bin/qtcreator`), load the `qgroundcontro.pro` project and build/debug from within its IDE. 187 | 188 | By default, this will build the regular QGC. To build the sample, customized UI version, follow [these instructions](https://github.com/mavlink/qgroundcontrol/blob/master/custom-example/README.md). -------------------------------------------------------------------------------- /zh/getting_started/README.md: -------------------------------------------------------------------------------- 1 | # 入门指南 2 | 3 | 本主题说明如何获取QGroundControl源代码并在本机或在Vagrant(虚拟机)环境中构建它。 本主题还提供其他可选功能信息及特定于操作系统的功能信息。 4 | 5 | ## 每日构建 6 | 7 | 如果您只是想测试 (而不是调试) 最近生成的 *QGroundControl* ，那么请使用[Daily build](https://docs.qgroundcontrol.com/en/releases/daily_builds.html)。 官方提供了适用于所有平台的版本。 8 | 9 | ## 源代码 10 | 11 | *QGroundControl* 的源代码保存在 github 上，下载地址为: https://github.com/mavlink/qgroundcontrol。 QGroundControl源代码在Apache 2.0和GPLv3下是双许可的。 有关更多信息，请参阅：许可证。 12 | 13 | 要获取源文件, 请执行以下操作: 14 | 15 | 1. 克隆存储库 (或您的分叉), 包括子模块: ```git clone --recursive -j8 https://github.com/mavlink/qgroundcontrol.git``` 16 | 2. 2.更新子模块（每次拉新源代码时都这样做）： ```git submodule update --recursive``` 17 | 18 | > 提示：不能使用Github以zip形式下载源文件，因为zip压缩包中不包含相应的子模块源代码。 你必须使用git工具！ 19 | 20 | ## 构建QGroundControl开发环境 21 | 22 | ### Using Containers 23 | 24 | We support Linux builds using a container found on the source tree of the repository, which can help you develop and deploy the QGC apps without having to install any of the requirements on your local environment. 25 | 26 | [Container Guide](../getting_started/container.md) 27 | 28 | ### Native Builds 29 | 30 | *QGroundControl* builds are supported for macOS, Linux, Windows, iOS and Android. *QGroundControl* uses [Qt](http://www.qt.io) as its cross-platform support library and uses [QtCreator](http://doc.qt.io/qtcreator/index.html) as its default build environment. 31 | 32 | - macOS：v10.11或更高版本 33 | - Ubuntu：64位，gcc编译器 34 | - **Windows:** Vista or higher, [Visual Studio 2019 compiler](#vs) (64 bit) 35 | - iOS：10.0及更高版本 36 | - **Android:** Android 5.0 and later. 37 | - Standard QGC is built against ndk version 19. 38 | - Java JDK 11 is required. 39 | - **Qt version:** {{ book.qt_version }} **(only)** > 40 | 41 | **Warning** **Do not use any other version of Qt!** QGC has been thoroughly tested with the specified version of Qt ({{ book.qt_version }}). There is a significant risk that other Qt versions will inject bugs that affect stability and safety (even if QGC compiles). 42 | 43 | For more information see: [Qt 5 supported platform list](http://doc.qt.io/qt-5/supported-platforms.html). 44 | 45 | 46 | 47 | > **Note** Native [CentOS Builds](../getting_started/CentOS.md) are also supported, but are documented separately (as the tested environment is different). 48 | 49 | #### Install Visual Studio 2019 (Windows Only) {#vs} 50 | 51 | The Windows compiler can be found here: [Visual Studio 2019 compiler](https://visualstudio.microsoft.com/vs/older-downloads/) (64 bit) 52 | 53 | When installing, select *Desktop development with C++* as shown: 54 | 55 | ![Visual Studio 2019 - Select Desktop Environment with C++](../../assets/getting_started/visual_studio_select_features.png) 56 | 57 | > **Note** Visual Studio is ONLY used to get the compiler. Actually building *QGroundControl* should be done using [Qt Creator](#qt-creator) or [qmake](#qmake) as outlined below. 58 | 59 | 60 | #### 安装Qt 61 | 62 | You **need to install Qt as described below** instead of using pre-built packages from say, a Linux distribution, because *QGroundControl* needs access to private Qt headers. 63 | 64 | To install Qt: 65 | 66 | 1. 下载并运行[Qt Online Installer](http://www.qt.io/download-open-source) 67 | - **Ubuntu:** 68 | - 使用以下命令将下载的文件设置为可执行文件：`chmod + x` 69 | - 请安装到默认位置, 以便与 **./qgroundcontrol-start.sh** 一起使用。如果将 Qt 安装到非默认位置, 则需要修改 **qgroundcontrol-start.sh** ，才能运行下载的组件。 70 | 71 | 2. 在安装程序 的*Select 组件 对话框中, 选择 {{ book.qt_version }}。

72 | 73 | > **Note** If the version needed is not displayed, check the archive (show archive and refresh). 74 | 75 | 然后，按如下向导，安装组件: 76 | 77 | - **Windows**: *MSVC 2019 64 bit* 78 | - **MacOS**: *macOS* 79 | - **Linux**: *Desktop gcc 64-bit* 80 | - All: 81 | 82 | - *Qt Charts* 83 | 84 | - *Android ARMv7* (optional, used to build Android) 85 | 86 | ![QtCreator Select Components (Windows)](../../assets/getting_started/qt_creator_select_components.jpg) 87 | 88 | - Install Additional Packages (Platform Specific) 89 | 90 | - **Ubuntu:** `sudo apt-get install speech-dispatcher libudev-dev libsdl2-dev patchelf build-essential curl` 91 | - **Fedora:** `sudo dnf install speech-dispatcher SDL2-devel SDL2 systemd-devel patchelf` 92 | - **Arch Linux:** `pacman -Sy speech-dispatcher patchelf` 93 | - **Android:** [Qt Android Setup](http://doc.qt.io/qt-5/androidgs.html) > **Note** JDK11 is required (install if needed)! 94 | 95 | - Install Optional/OS-Specific Functionality 96 | 97 | > **Note** Optional features that are dependent on the operating system and user-installed libraries are linked/described below. These features can be forcibly enabled/disabled by specifying additional values to qmake. 98 | 99 | - **Video Streaming/Gstreamer:** - see [Video Streaming](https://github.com/mavlink/qgroundcontrol/blob/master/src/VideoReceiver/README.md). 100 | - **Airmap SDK:** - TBD. 101 | 102 | - Disable platform-specific optional features that are enabled (but not installed), by default. 103 | 104 | > **Note** This currently applies to Airmap on Linux, which is optional but enabled by default. 105 | 106 | - **Ubuntu:** 107 | - Airmap: Create a file named **user_config.pri** (in the repo root directory) containing the text `DEFINES += DISABLE_AIRMAP`. This can be done in a bash terminal using the command: ```echo -e "DEFINES += DISABLE_AIRMAP\r\n" | tee user_config.pri``` 108 | 109 | #### Building using Qt Creator {#qt-creator} 110 | 111 | 1. Launch *Qt Creator* and open the **qgroundcontrol.pro** project. 112 | 2. In the **Projects** section, select the appropriate kit for your needs: 113 | - **OSX:** Desktop Qt {{ book.qt_version }} clang 64 bit > **Note** iOS builds must be built using [XCode](http://doc.qt.io/qt-5/ios-support.html). 114 | - **Ubuntu:** Desktop Qt {{ book.qt_version }} GCC 64bit 115 | - **Windows:** Desktop Qt {{ book.qt_version }} MSVC2019 **64bit** 116 | - **Android:** Android for armeabi-v7a (GCC 4.9, Qt {{ book.qt_version }}) 117 | - JDK11 is required. You can confirm it is being used by reviewing the project setting: **Projects > Manage Kits > Devices > Android (tab) > Android Settings > *JDK location***. 118 | 119 | 3. Build using the "hammer" (or "play") icons: 120 | 121 | ![QtCreator Build Button](../../assets/getting_started/qt_creator_build_qgc.png) 122 | 123 | #### Build using qmake on CLI {#qmake} 124 | 125 | Example commands to build a default QGC and run it afterwards: 126 | 127 | 1. Make sure you cloned the repository and updated the submodules before, see chapter *Source Code* above and switch into the repository folder: ```cd qgroundcontrol``` 128 | 2. Create and enter a shadow build directory: 129 | mkdir build 130 | cd build 131 | 132 | 3. Configure the build using the qmake script in the root of the repository: ```qmake ../``` 133 | 4. Run make to compile and link. To accelerate the process things you can use the `-j{number of threads}` parameter. ```make -j12``` 134 | 135 | > **Note** You can also specify build time flags here. For example, you could disable airmap inclusion using the command: 136 | > 137 | > DEFINES+=DISABLE_AIRMAP make build 138 | > 139 | 140 | 5. Run the QGroundcontrol binary that was just built: ```./staging/QGroundControl``` 141 | 142 | ### Vagrant 143 | 144 | [Vagrant](https://www.vagrantup.com/) can be used to build and run *QGroundControl* within a Linux virtual machine (the build can also be run on the host machine if it is compatible). 145 | 146 | 1. [Download](https://www.vagrantup.com/downloads.html) and [Install](https://www.vagrantup.com/docs/getting-started/) Vagrant 147 | 2. From the root directory of the *QGroundControl* repository run `vagrant up` 148 | 3. To use the graphical environment run `vagrant reload` 149 | 150 | ### Additional Build Notes for all Supported OS 151 | 152 | - **Parallel builds:** For non Windows builds, you can use the `-j#` option to run parellel builds. 153 | - **Location of built files:** Individual build file results can be found in the `build_debug` or `build_release` directories. The built executable can be found in the `debug` or `release` directory. 154 | - **If you get this error when running *QGroundControl***: `/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found.`, you need to either update to the latest *gcc*, or install the latest *libstdc++.6* using: `sudo apt-get install libstdc++6`. 155 | - **Unit tests:** To run the [unit tests](../contribute/unit_tests.md), build in `debug` mode with `UNITTEST_BUILD` definition, and then copy `deploy/qgroundcontrol-start.sh` script into the `debug` directory before running the tests. 156 | 157 | ## Building QGC Installation Files 158 | 159 | You can additionally create installation file(s) for *QGroundControl* as part of the normal build process. 160 | 161 | > **Note** On Windows you will need to first install [NSIS](https://sourceforge.net/projects/nsis/). 162 | 163 | To add support for installation file creation you need to add `CONFIG+=installer` to your project file, or when you call *qmake*. 164 | 165 | To do this in *Qt Creator*: 166 | 167 | - Open **Projects > Build > Build Steps > qmake > Additional arguments**. 168 | - Enter `CONFIG+=installer` as shown: ![Installer](../../assets/getting_started/qt_project_installer.png) -------------------------------------------------------------------------------- /zh/getting_started/container.md: -------------------------------------------------------------------------------- 1 | # Building using Containers 2 | 3 | The community created a docker image that makes it much easier to build a Linux-based QGC application. This can give you a massive boost in productivity and help with testing. 4 | 5 | ## About the Container 6 | 7 | The Container is located in the `./deploy/docker` directory. It's based on ubuntu 20.04. It pre-installs all the dependencies at build time, including Qt, thanks to a script located in the same directory, `install-qt-linux.sh`. The main advantage of using the container is the usage of the `CMake` build system and its many improvements over `qmake` 8 | 9 | ## Building the Container 10 | 11 | Before using the container, you have to build the image. You can accomplish this using docker, running the following script from the root of the QGC source code directory. 12 | 13 | ``` 14 | docker build --file ./deploy/docker/Dockerfile-build-linux -t qgc-linux-docker . 15 | ``` 16 | 17 | > **Note** The `-t` flag is essential. Keep in mind this is tagging the image for later reference since you can have multiple builds of the same container 18 | 19 | 20 | > **Note** If building on a Mac computer with an M1 chip you must also specify the build option `--platform linux/x86_64` as shown: 21 | > 22 | > ``` 23 | > docker build --platform linux/x86_64 --file ./deploy/docker/Dockerfile-build-linux -t qgc-linux-docker . 24 | > ``` 25 | > 26 | > Otherwise you will get a build error like: 27 | > 28 | > ``` 29 | > qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory 30 | > ``` 31 | 32 | 33 | ## Building QGC using the Container 34 | 35 | To use the container to build QGC, you first need to define a directory to save the artifacts. We recommend you create a `build` directory on the source tree and then run the docker image using the tag provided above as follows, from the root directory: 36 | 37 | ``` 38 | mkdir build 39 | docker run --rm -v ${PWD}:/project/source -v ${PWD}/build:/project/build qgc-linux-docker 40 | ``` 41 | 42 | > **Note** If using the script to build the Linux image on a Windows host, you would need to reference the PWD differently. On Windows the docker command is: 43 | > 44 | > ``` 45 | > docker run --rm -v %cd%:/project/source -v %cd%/build:/project/build qgc-linux-docker 46 | > ``` 47 | 48 | Depending on your system resources, or the resources assigned to your Docker Daemon, the build step can take some time. 49 | 50 | 51 | ## Troubleshooting 52 | 53 | ### Windows: 'bash\r': No such file or directory 54 | 55 | This error indicates that a Linux script is being run with Windows line endings, which might occur if `git` was configured to use Windows line endings: 56 | ``` 57 | > [4/7] RUN /tmp/qt/install-qt-linux.sh: 58 | #9 0.445 /usr/bin/env: 'bash\r': No such file or directory 59 | ``` 60 | 61 | One fix is to force Linux line endings using the command: 62 | ``` 63 | git config --global core.autocrlf false 64 | ``` 65 | Then update/recreate your local repository. 66 | -------------------------------------------------------------------------------- /zh/plan/MissionCommandTree.md: -------------------------------------------------------------------------------- 1 | # 任务指令树 2 | 3 | QGC 创建用户界面，用于从 json 元数据的层次结构中动态编辑特定任务项命令。 此层次结构称为任务命令树。 这样，在添加新命令时，只能创建 json 元数据。 4 | 5 | ## 为什么是一颗树？ 6 | 7 | 需要该树以不同的方式处理不同固件和／或不同的车辆类型，以支持不同的命令。 最简单的例子是 mavlink 规范可能包含了并非所有固件都支持的命令参数。 或着命令参数仅对某些车辆类型有效。 此外，在某些情况下，GCS 可能会决定将某些命令参数在视图中对最终用户进行隐藏，因为它们过于复杂或导致可用性问题。 8 | 9 | 该树是MissionCommandTree类： [MissionCommandTree.cc](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandTree.cc), [MissionCommandTree.h](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandTree.h) 10 | 11 | ### 树根目录 12 | 13 | 树的根目录是与 mavlink 规范完全匹配的json元数据。 14 | 15 | 您可以在这里看到`MAV_CMD_NAV_WAYPOINT`根目录[json](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoCommon.json#L27)的示例： 16 | 17 | ``` 18 | { 19 | "id": 16, 20 | "rawName": "MAV_CMD_NAV_WAYPOINT", 21 | "friendlyName": "Waypoint", 22 | "description": "Travel to a position in 3D space.", 23 | "specifiesCoordinate": true, 24 | "friendlyEdit": true, 25 | "category": "Basic", 26 | "param1": { 27 | "label": "Hold", 28 | "units": "secs", 29 | "default": 0, 30 | "decimalPlaces": 0 31 | }, 32 | "param2": { 33 | "label": "Acceptance", 34 | "units": "m", 35 | "default": 3, 36 | "decimalPlaces": 2 37 | }, 38 | "param3": { 39 | "label": "PassThru", 40 | "units": "m", 41 | "default": 0, 42 | "decimalPlaces": 2 43 | }, 44 | "param4": { 45 | "label": "Yaw", 46 | "units": "deg", 47 | "nanUnchanged": true, 48 | "default": null, 49 | "decimalPlaces": 2 50 | } 51 | }, 52 | ``` 53 | 54 | 注意：在现实中，基于此的信息应由 mavlink 本身提供，而不需要成为 GCS 的一部分。 55 | 56 | ### 叶节点 57 | 58 | 然后，叶节点提供元数据，这些元数据可以覆盖命令的值和/或从显示给用户的参数中删除参数。 完整的树层次结构是这样的： 59 | 60 | - 根－通用Mavlink 61 | - 特定的车辆类型－特定于车辆的通用规范 62 | - 特定的硬件类型－每个固件类型有一个可选的叶节点（PX4/ArduPilot） 63 | - 特定的车辆类型－每个车辆类型有一个可选的叶节点（FW/MR/VTOL/Rover/Sub） 64 | 65 | 注意：实际上，此替代功能应该是mavlink规格的一部分，并且应该可以从车辆中查询。 66 | 67 | ### 从完整树中构建实例树 68 | 69 | 由于 json 元数据提供了所有固件／车辆类型组合的信息，因此必须根据用于创建计划的固件和车辆类型来构建要使用的实际树。 这是通过一个进程调用“collapsing”的完整树到一个固件／车辆的特定树来完成的 ([code](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandTree.cc#L119))。 70 | 71 | 步骤如下： 72 | * 在实例树种添加根 73 | * 将特定的车辆类型重写实例树 74 | * Apply the firmware type specific overrides to the instance tree 75 | * 将特定的硬件／车辆类型重写实例树 76 | 77 | 然后，生成的任务命令树将为平面项目编辑器构建UI。 实际上，它不仅用于此，还有许多其他地方可以帮助您了解有关特定命令 id 的更多信息。 78 | 79 | ## 层次结构示例 `MAV_CMD_NAV_WAYPOINT` 80 | 81 | 让我们来看看`MAV_CMD_NAV_WAYPOINT`的示例层次结构。 根信息如上图所示。 82 | 83 | ### 根－车辆类型的特定叶节点 84 | 层次结构的下一个层级是通用的 mavlink，但只针对特定的车辆。 这里的Json文件：[MR](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoMultiRotor.json), [FW](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoFixedWing.json), [ROVER](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoRover.json), [Sub](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoSub.json), [VTOL](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MavCmdInfoVTOL.json)。 这个是重写（固定翼）　 85 | 86 | ``` 87 | { 88 | "id": 16, 89 | "comment": "MAV_CMD_NAV_WAYPOINT", 90 | "paramRemove": "4" 91 | }, 92 | ``` 93 | 94 | 这样做是删除参数4的编辑 UI，固定翼没有使用航向（Yaw）参数。 由于这是根的叶节点，因此无论固件类型如何，这都适用于所有固定翼车辆。 95 | 96 | ### 根－硬件类型的特定叶节点 97 | 层次结构的下一层级是特定于固件类型但适用于所有车辆类型的替代。 再次让我们看看航点（Waypoint）覆盖： 98 | 99 | [ArduPilot](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/APM/MavCmdInfoCommon.json#L6)： 100 | 101 | ``` 102 | { 103 | "id": 16, 104 | "comment": "MAV_CMD_NAV_WAYPOINT", 105 | "paramRemove": "2" 106 | }, 107 | ``` 108 | 109 | [PX4](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/PX4/MavCmdInfoCommon.json#L7)： 110 | 111 | ``` 112 | { 113 | "id": 16, 114 | "comment": "MAV_CMD_NAV_WAYPOINT", 115 | "paramRemove": "2,3" 116 | }, 117 | ``` 118 | 119 | 您可以看到，对于两个固件参数参数2，即接受半径，从编辑 ui 中删除。 这是QGC的特性决定。 与指定值相比，使用固件通用接受半径会更加安全和容易。 因此，我们决定对用户隐藏它。 120 | 121 | 您还可以看到，对于 PX4 param3/PassThru，由于 PX 不支持它，因此已被删除。 122 | 123 | ### 根－特定于固件的类型－特定于车辆类型的叶子节点 124 | 层次结构的最后一个级别既针对固件又针对车辆类型。 125 | 126 | [ArduPilot/MR](https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/APM/MavCmdInfoMultiRotor.json#L7): 127 | 128 | ``` 129 | { 130 | "id": 16, 131 | "comment": "MAV_CMD_NAV_WAYPOINT", 132 | "paramRemove": "2,3,4" 133 | }, 134 | ``` 135 | 136 | 在这里你可以看到，ArduPilot的多电机车辆参数2/3/4 Acceptance/PassThru/Yaw 已被移除。 例如，航向（Yaw）是因为不支持所以被移除。 由于此代码的工作原理的怪癖，您需要从较低级别重复重写。 137 | 138 | ## 任务命令 UI 信息 139 | 两个类定义与命令相关联的元数据： 140 | 141 | * MissionCommandUIInfo－整个命令的元数据 142 | * MissionCmdParamInfo－命令中参数的元数据 143 | 144 | 源中注释了支持 json 键的完整详细信息。 145 | 146 | [MissionCommandUIInfo](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandUIInfo.h#L82)： 147 | 148 | ``` 149 | /// 与任务命令关联的 UI 信息 （MAV_CMD） 150 | /// 151 | ///MissionCommandUIInfo用于自动为MAV_CMD生成编辑ui。 此对象还支持仅具有一组命 152 | /// 令的部分信息的概念。 这用于创建基本命令信息的替代。 对于覆盖，只需从基本命 153 | /// 令 ui 信息中指定要修改的键即可。 若要重写 ui 参数信息，必须指定整个MissionParamInfo对象。 154 | /// 155 | /// MissionCommandUIInfo对象的json格式为： 156 | /// 157 | /// 键值 　类型 默认值 描述 158 | /// id int reauired MAV_CMD id 159 | /// comment string 用于添加评论 160 | /// rawName string required MAV_CMD 枚举名称，仅应设置基础树信息 161 | /// friendlyName string rawName 命令的简单描述 162 | /// description string 命令的详细描述 163 | /// specifiesCoordinate bool false true: 命令指定一个纬／经／高坐标 164 | /// specifiesAltitudeOnly bool false true: 命令仅指定高度（非坐标） 165 | /// standaloneCoordinate bool false true: 车辆无法通过与命令关联的坐标（例如：ROI） 166 | /// isLandCommand bool false true: 命令指定着陆指令 (LAND, VTOL_LAND, ...) 167 | /// friendlyEdit bool false true: 命令支持友好的编辑对话框，false：Command仅支持“显示所有值”样式的编辑 168 | /// category string Advanced 该命令所属的类别 169 | /// paramRemove string 由替代使用以删除参数，例如：“ 1,3”将删除替代上的参数1和3 170 | /// param[1-7] object MissionCommandParamInfo 对象 171 | /// 172 | 173 | ``` 174 | 175 | [MissionCmdParamInfo](https://github.com/mavlink/qgroundcontrol/blob/master/src/MissionManager/MissionCommandUIInfo.h#L25)： 176 | 177 | ``` 178 | /// 与任务命令 （MAV_CMD） 参数关联的 UI 信息 179 | /// 180 | /// MissionCommandParamInfo 用于自动为与 MAV_CMD 关联的参数生成编辑ui。 181 | /// 182 | /// MissionCmdParamInfo 对象的 Json 文件格式为： 183 | ///　 184 | /// 键值 类型 默认值 描述 185 | /// label string required 文本字段标签 186 | /// units string 值的单位，应使用 FactMetaData Units 字符串以获得自动转换 187 | /// default double 0.0/NaN 默认参数值。 如果未指定默认值且 nanunchange==true，默认值为NaN。 188 | /// decimalPlaces int 7 显示值得小数位数 189 | /// enumStrings string 要在组合框中显示以供选择的字符串 190 | /// enumValues string 与每个枚举字符串关联的值 191 | /// nanUnchanged bool false True: 值可以设置为NaN表示信号不变 192 | ``` 193 | -------------------------------------------------------------------------------- /zh/tools/README.md: -------------------------------------------------------------------------------- 1 | # 开发者工具 2 | 3 | QGroundControl主要为自动驾驶开发人员提供了许多工具。 这些简化了常见的开发人员任务，包括设置模拟连接以进行测试，以及通过MAVLink访问系统Shell。 4 | 5 | > 注意:在调试模式下构建源以启用这些工具。 6 | 7 | 工具包括： 8 | 9 | - 模拟链接（仅限每日构建） - 创建和停止多个模拟载具链接。 10 | - 重播飞行数据 - 重播遥测日志（用户指南）。 11 | - MAVLink Inspector - 显示收到的MAVLink消息/值。 12 | - MAVLink分析器 - 绘制MAVLink消息/值的趋势图。 13 | - 自定义命令小组件 - 在运行时加载自定义/测试QML UI。 14 | - 板载文件 - 导航车辆文件系统和上载/下载文件。 15 | - HIL Config Widget - HIL模拟器的设置. 16 | - MAVLink控制台（仅限PX4） - 连接到PX4 nsh shell并发送命令。 -------------------------------------------------------------------------------- /zh/tools/mock_link.md: -------------------------------------------------------------------------------- 1 | # 模拟链接 2 | 3 | Mock Link允许您在QGroundControl调试版本中创建和停止指向多个模拟（模拟）载具的链接。 4 | 5 | 模拟不支持飞行，但允许轻松测试： 6 | 7 | * 任务上传/下载 8 | * 查看和更改参数 9 | * 测试大多数设置页面 10 | * 多个载具用户界面 11 | 12 | 对于任务上载/下载的单元测试错误情况尤其有用。 13 | 14 | ## 使用Mock Link 15 | 16 | 为了使用Mock Link： 17 | 18 | 1. 1.通过构建源来创建调试版本。 19 | 2. 通过选择顶部工具栏中的“应用程序设置”图标，然后选择侧栏中的“模拟链接”来访问“模拟链接”： 20 | 21 | ![](../../assets/tools/mocklink_waiting_for_connection.jpg) 22 | 23 | 3. 3. 可以单击面板中的按钮以创建相关类型的车辆链接。 24 | 25 | * 每次单击按钮时，都会创建一个新连接。 26 | * 当存在多个连接时，将显示多车辆UI。 27 | 28 | ![](../../assets/tools/mocklink_connected.jpg) 29 | 30 | 1. 1. 单击停止一个模拟链接以停止当前活动的车辆。 31 | 32 | 然后使用模拟链接或多或少与使用任何其他载具相同，只是模拟不允许飞行。 -------------------------------------------------------------------------------- /zh/ui_design/README.md: -------------------------------------------------------------------------------- 1 | # 用户界面设计 2 | 3 | QGC中UI设计的主要模式是用QML编写的UI页面，多次与用C ++编写的自定义“Controller”进行通信。 这种设计模式有点沿用MVC设计模式，但也有显著不同之处。 4 | 5 | QML代码通过以下机制绑定到与系统关联的信息： 6 | 7 | * 自定义控制器 8 | * 全局QGroundControl对象，提供对活动Vehicle等内容的访问 9 | * FactSystem提供对参数的访问，在某些情况下提供自定义事实。 10 | 11 | 注意：由于QGC中使用的QML的复杂性以及它依赖于与C ++对象的通信来驱动ui，因此无法使用Qt提供的QML Designer来编辑QML。 -------------------------------------------------------------------------------- /zh/ui_design/controls.md: -------------------------------------------------------------------------------- 1 | # 用户界面控件 2 | 3 | QGC提供了一组用于构建用户界面的基本控件。 一般来说，它们往往是Qt支持的基本QML控件上方的薄层，Qt控件支持QGC调色板。 4 | 5 | import QGroundControl.Controls 1.0 6 | 7 | 8 | ## Qt控件 9 | 10 | 以下控件是标准Qt QML控件的QGC变体。 除了使用QGC调色板绘制。它还们提供与相应Qt控件相同的功能， 11 | 12 | * QGCButton 13 | * QGCCheckBox 14 | * QGCColoredImage 15 | * QGCComboBox 16 | * QGCFlickable 17 | * QGCLabel 18 | * QGCMovableItem 19 | * QGCRadioButton 20 | * QGCSlider 21 | * QGCTextField 22 | 23 | ## QGC 控件 24 | 25 | 这些自定义控件是QGC独有的，用于创建标准UI元素。 26 | 27 | * DropButton - RoundButton，单击时会删除一组选项。 示例是平面视图中的同步按钮。 28 | * ExclusiveGroupItem - 用于支持QML ExclusiveGroup 概念的自定义控制的基础项目。 29 | * QGCView - 系统中所有顶级视图的基本控件。 提供对FactPanels的支持并显示QGCViewDialogs和QGCViewMessages。 30 | * QGC View对话框 - 从QGC视图右侧弹出的对话框。 您可以指定对话框的接受/拒绝按钮以及对话框内容。 使用示例是当您单击某个参数并显示值编辑器对话框时。 31 | * QGCViewMessage - QGCViewDialog的简化版本，允许您指定按钮和简单的文本消息。 32 | * QGCViewPanel - QGCView内部的主要视图内容。 33 | * RoundButton - 一个圆形按钮控件，它使用图像作为其内部内容。 34 | * SetupPage - 所有安装载具组件页面的基本控件。 提供标题，说明和组件页面内容区域。 -------------------------------------------------------------------------------- /zh/ui_design/font_palette.md: -------------------------------------------------------------------------------- 1 | # 字体和调色板 2 | 3 | QGC有一套标准的字体和调色板，应该由所有用户界面使用。 4 | 5 | import QGroundControl.Palette 1.0 6 | import QGroundControl.ScreenTools 1.0 7 | 8 | 9 | ## QGCPalette(QGC调色板) 10 | 11 | 此项目显示QGC调色板。 这个调色板有两种变体：浅色和深色。 较浅的调色板适合户外使用，黑色调色板适用于室内。 通常，您不应该直接为UI指定颜色，您应该使用调色板中的颜色。 如果不遵循此规则，则您创建的用户界面将无法通过浅色/深色样式更改。 12 | 13 | ## QGCMapPalette(QGC地图调色板) 14 | 15 | 地图调色板用于绘制地图的颜色。 由于不同的地图样式，特别是卫星和街道，您需要有不同的颜色来清晰地绘制它们。 卫星地图需要更浅的颜色，而街道地图需要更深的颜色。 QGCMapPalette项目为此提供了一组颜色，以及在地图上切换浅色和深色的功能。 16 | 17 | ## ScreenTools (屏幕工具) 18 | 19 | ScreenTools项提供可用于指定字体大小的值。 它还提供有关屏幕大小以及QGC是否在移动设备上运行的信息。 -------------------------------------------------------------------------------- /zh/ui_design/multi_device_pattern.md: -------------------------------------------------------------------------------- 1 | # 多设备设计模式 2 | 3 | QGroundControl设计用于从桌面到笔记本电脑，平板电脑和使用鼠标和触摸的小型手机屏幕等多种设备类型。 以下是QGC如何做到以及背后原理的描述。 4 | 5 | ## 高效的一个人开发团队 6 | 7 | QGC开发用于解决此问题的设计模式基于快速开发新功能并允许代码库由一个非常小的团队测试和维护（假设1个开发人员作为默认的开发团队规模）。 实现这一目标的模式非常严格，因为不遵循它将导致更慢的开发时间和更低的质量。 8 | 9 | 支持这个1人开发团队概念导致一些艰难的决定，并不是每个人都可能感到高兴。 但它确实导致QGC使用单个代码库在许多操作系统和硬件平台上发布。 This is something most other ground stations out there are not capable of achieving. 10 | 11 | 你可能会问，贡献者呢？ QGC拥有相当数量的贡献者。 Can't they help move things past this 1 person dev team concept? 是的QGC有几个贡献者。 但是，他们随着时间的推移加入而来。 当它们离开时，它们贡献的代码仍然必须保持 因此，你回到了过去三年发展中的平均1人开发团队的概念 12 | 13 | ## 目标设备 14 | 15 | 从触摸的角度和屏幕尺寸的角度来看，QGC UI设计的优先目标是平板电脑（比如三星Galaxy）。 由于此决定，其他设备类型和大小可能会看到一些视觉和/或可用性的错误。 基于优先级的决策时的当前顺序是平板电脑，笔记本电脑，台式机，电话（任何小屏幕）。 16 | 17 | ### 手机大小的屏幕支持 18 | 19 | As specified above, at this point smaller phone sized screens are the lowest level priority for QGC. More focus is put onto making active flight level displays, such as the Fly view, more usable. 较少关注设置相关视图，例如“设置”和“计划”。 Those specific views are tested to be functionally usable on small screens but they may be painful to use. 20 | 21 | ## 使用的开发工具 22 | 23 | ### Qt布局控件 24 | 25 | QGC没有针对不同屏幕尺寸和/或形状因子的不同编码的UI。 通常，它使用QML Layout功能来重排一组QML UI代码以适应不同的外形。 在某些情况下，它提供了较小的屏幕尺寸细节，使事情适合。 但这是一个简单的可见性模式。 26 | 27 | ### FactSystem（事实系统） 28 | 29 | QGC内部是一个系统，用于管理系统中的所有单个数据。 这个数据模型是连接到控件的。 30 | 31 | ### 严重依赖可重用控件 32 | 33 | QGC UI是从一组可重用的控件和UI元素开发而来的。 这样，现在可以在整个UI中使用添加到可重用控件的任何新功能。 这些可重用的控件还连接到FactSystem Facts，然后FactSystem Facts自动提供适当的UI。 34 | 35 | ## 这种设计模式的缺点 36 | 37 | * QGC用户界面最终成为台式机/笔记本电脑/平板电脑/手机的混合风格。 因此，不一定看起来或感觉它被优化为任何这些。 38 | * 给定目标设备优先级列表以及QGC倾向于重新布局相同UI元素以适应不同形状因子的事实, 当你离优先目标越来越远时，你会发现这种混合方法会变得更糟。 因此，小型手机大小的屏幕在可用性方面受到的打击最大。 39 | * 在某些情况下，QGC可重用控件集可能无法提供绝对最佳的UI。 但它仍然用于防止创建额外的维护表面区域。 40 | * 由于QGC UI对所有操作系统使用相同的UI代码，因此QGC不遵循操作系统本身指定的UI设计准则。 它有自己的视觉风格，有点混合了从每个操作系统中挑选出来的东西。 因此，UI在所有操作系统上的外观和工作方式大致相同。 再次, 这意味着, 例如, QGC 运行在 android 并不一定看起来像一个 android 应用程序。或者, 在 iphone 上运行的 QGC 不会像其他大多数 iphone 应用程序那样看起来或工作。 也就是说，QGC视觉/功能样式对于这些OS用户来说应该是可以理解的。 41 | 42 | ## 这种设计模式的优点 43 | 44 | * 由于使用此混合模型和控制集进行一次UI编码，因此设计新功能所需的时间更短。 布局重排在Qt QML中非常强大，一旦你习惯它就成为第二天性。 45 | * UI可以仅在一个平台上进行功能测试，因为代码是平台无关的。 只有布局流必须在多个设备上进行可视化检查, 但这很容易使用移动模拟器完成。 在大多数情况下，这是需要的： 46 | * 使用桌面构建，调整窗口大小以测试重排。 通常也会覆盖平板电脑大小的屏幕。 47 | * 使用移动模拟器直观地验证手机大小的屏幕。 在OSX XCode iPhone模拟器上工作得非常好。 48 | * 上述机制对于确保单人团队的效率和高质量是至关重要。 49 | 50 | ## 未来发展方向 51 | 52 | * 将手机（小屏幕）级别优先级提升为更接近平板电脑。 目前的想法是，这将不会发生在3.3发布时间框架（在当前工作之后发布）。 -------------------------------------------------------------------------------- /zh/views/README.md: -------------------------------------------------------------------------------- 1 | # 顶级视图 2 | 3 | 本节包含有关顶级视图代码的主题：设置，设置，计划和飞行。 -------------------------------------------------------------------------------- /zh/views/fly.md: -------------------------------------------------------------------------------- 1 | # 飞视图 2 | 3 | * 顶级QML代码在FlightDisplayView.qml中 4 | * QML代码与MissionController（C ++）通信以进行任务显示 5 | * 仪器小部件与活动的Vehicle对象通信 6 | * 两个主要的内部view是： 7 | * `FlightDisplayViewMap` 8 | * `FlightDisplayViewVideo` -------------------------------------------------------------------------------- /zh/views/plan.md: -------------------------------------------------------------------------------- 1 | # 规划视图 2 | 3 | * 最高级别的 QML 代码是 [PlanView.qml](https://github.com/mavlink/qgroundcontrol/blob/master/src/PlanView/PlanView.qml) 4 | * 主视图UI是FlightMap控件 5 | * QML与MissionController（C ++）通信，后者为视图提供任务项数据和方法 -------------------------------------------------------------------------------- /zh/views/settings.md: -------------------------------------------------------------------------------- 1 | # 设置视图 2 | 3 | * 顶级QML代码是AppSettings.qml 4 | * 每个按钮都会加载一个单独的QML页面 -------------------------------------------------------------------------------- /zh/views/setup.md: -------------------------------------------------------------------------------- 1 | # 设置视图 2 | 3 | * 在SetupView.qml中实现的顶级QML代码 4 | * 固定的按钮/页面集：摘要，固件 5 | * 按钮/页面的剩余部分来自AutoPilot Plugin Vehicle Component列表 --------------------------------------------------------------------------------