MethodicConfigurator

Development guide

The goal ArduPilot methodic Configurator software is to automate some of the tasks involved in configuring and tuning ArduPilot-based vehicles. To develop the software the standard V-Model software development method was first used. It was augmented with DevOps and CI/CD automation practices at a later stage.

V-model

The Software architecture

We decided to use python as programming language, and the following libraries and frameworks:

• pymavlink for the flight controller communication
• tkinter for the graphical user interface
• GNU gettext po files to translate the software to other languages

The (main) application itself does the command line parsing and starts the sub-applications defined below in sequence

• __main__.py

To satisfy the system design requirements the following user interface sub-applications were developed:

Sub-Application Architecture Documentation

Each sub-application has detailed architecture documentation covering requirements, implementation status, data flow, components, testing, and recommendations:

1. Software Update Check - Checks for and downloads software updates
   • frontend_tkinter_software_update.py
   • data_model_software_updates.py
2. Flight Controller Communication - Establishes FC connection, downloads parameters and metadata
   • frontend_tkinter_connection_selection.py
     • frontend_tkinter_flightcontroller_info.py
     • backend_flightcontroller.py
     • backend_mavftp.py
3. Directory and Project Selection - Creates new projects or opens existing ones
   • frontend_tkinter_directory_selection.py
     • frontend_tkinter_template_overview.py
4. Vehicle Component Editor - Defines vehicle components and their FC connections
   • frontend_tkinter_component_editor.py
     • frontend_tkinter_component_editor_base.py
     • frontend_tkinter_component_template_manager.py
5. Parameter Editor and Uploader - Views documentation, edits parameters, uploads to FC
   • sequentially for each configuration step:
     • view documentation relevant for the current configuration step,
     • edit parameters relevant for the current configuration step,
     • upload them to the flight controller,
     • save them to file
   • frontend_tkinter_parameter_editor.py
     • frontend_tkinter_parameter_editor_documentation_frame.py
     • frontend_tkinter_parameter_editor_table.py
     • frontend_tkinter_stage_progress.py
6. Motor Test - Provides motor testing functionality with visual diagram display
   • frontend_tkinter_motor_test.py
   • data_model_motor_test.py

Each sub-application can be run in isolation, so it is easier to test and develop them.

Data Models and Architecture

Each application separates the business logic (data_model_*.py) from the user interface logic (frontend_tkinter_*.py). This improves testability and maintainability of the code.

1. Check for software updates:
   1. data_model_software_updates.py
2. FC connection:
   1. data_model_fc_ids.py <- autogenerated by update_flight_controller_ids.py
3. Create or open project:
   1. data_model_vehicle_project.py
   2. data_model_vehicle_project_creator.py
   3. data_model_vehicle_project_opener.py
   4. data_model_template_overview.py
4. Component editor:
   1. battery_cell_voltages.py
   2. data_model_vehicle_components_base.py
   3. data_model_vehicle_components_display.py
   4. data_model_vehicle_components_import.py
   5. data_model_vehicle_components_json_schema.py
   6. data_model_vehicle_components_templates.py
   7. data_model_vehicle_components_validation.py
   8. data_model_vehicle_components.py
5. Parameter editor:
   1. data_model_configuration_step.py
   2. data_model_par_dict.py
   3. data_model_ardupilot_parameter.py

The detailed data models, components, and dependencies for each sub-application are documented in their respective architecture files linked above.

Common Libraries and Shared Components

All applications use one or more of the following shared libraries:

1. internationalization
   1. __init__.py
   2. internationalization.py
   3. configuration_steps_strings.py <- autogenerated by update_configuration_steps_translation.py
   4. vehicle_components.py <- autogenerated by update_vehicle_components_translation.py
2. command line parsing
   1. common_arguments.py
   2. argparse_check_range.py
3. the local filesystem backend does file I/O on the local file system. Operates mostly on parameter files and metadata/documentation files
   1. backend_filesystem.py
   2. backend_filesystem_vehicle_components.py
   3. backend_filesystem_configuration_steps.py
   4. backend_filesystem_program_settings.py
4. the internet backend communicates with the internet
   1. backend_internet.py
5. the flight controller backend communicates with the flight controller
   1. backend_flightcontroller.py
   2. backend_mavftp.py
6. the tkinter frontend, which is the GUI the user interacts with
   1. frontend_tkinter_autoresize_combobox.py
   2. frontend_tkinter_base_window.py
   3. frontend_tkinter_entry_dynamic.py
   4. frontend_tkinter_pair_tuple_combobox.py
   5. frontend_tkinter_progress_window.py
   6. frontend_tkinter_rich_text.py
   7. frontend_tkinter_scroll_frame.py
   8. frontend_tkinter_show.py
   9. frontend_tkinter_usage_popup_window.py

When all is combined it looks like this:

The parts can be individually tested, and do have unit tests. They can also be exchanged, for instance, tkinter-frontend can be replaced with wxWidgets or pyQt.

In the future, we might port the entire application into a client-based web application. That way the users would not need to install the software and will always use the latest version.

Generated Files

Several files in the project are automatically generated and should not be manually edited:

Core Application Generated Files

1. data_model_fc_ids.py <- autogenerated by update_flight_controller_ids.py
   • Contains flight controller hardware identification mappings
   • Generated from ArduPilot firmware metadata
2. configuration_steps_strings.py <- autogenerated by update_configuration_steps_translation.py
   • Contains translatable strings for configuration step descriptions
   • Generated from configuration JSON files for internationalization
3. vehicle_components.py <- autogenerated by update_vehicle_components_translation.py
   • Contains translatable strings for vehicle component descriptions
   • Generated from vehicle component JSON schemas for internationalization

Development and Analysis Tools

1. generate_codebase_pie_chart.py <- generated by AI assistant for codebase analysis
   • Creates pie chart visualizations of codebase structure
   • Automatically maintains codebase metrics and statistics
   • Part of the development workflow for project health assessment
2. download_motor_diagrams.py <- autogenerated by .github/instructions/update_motor_diagrams.md
   • Downloads motor diagram SVG files from ArduPilot documentation
   • Updates motor diagrams used in the motor test sub-application
   • Periodically updated via GitHub Actions workflow

Note: When calculating code metrics or performing codebase analysis, these generated files should be counted separately from hand-written code to provide accurate development statistics.

Module design

To assure code quality we decided to use Microsoft VS code with a lot of extensions to lint the code as you type. We use git pre-commit hooks to check the code before it is committed to the repository.

Module testing

We tested using automated static tests in both pre-commit hooks and on github CI:

• ruff
• pylint
• mypy
• pyright
• markdown-lint
• markdown-link-check
• codespell, grammarly
• shellcheck

We tested using automated dynamic tests on github CI including automated test coverage reports. We use unittest to write unit tests for the code. The tests are easy to run on the command line or in VS code. When you write new code you must also write tests in the tests/ directory, there is CI test that only passes if test coverage increases monotonically.

To run the tests either use the python tests plugin in visualstudio code, or execute:

pytest

Integration testing

The different sub-applications are first tested independently. Each has detailed testing strategies documented in their respective architecture files:

• Software Update - python .\ardupilot_methodic_configurator\data_model_software_updates.py
• Flight Controller Communication - python .\ardupilot_methodic_configurator\frontend_tkinter_connection_selection.py
• Directory Selection
  • python .\ardupilot_methodic_configurator\frontend_tkinter_directory_selection.py
  • python .\ardupilot_methodic_configurator\frontend_tkinter_template_overview.py
• Component Editor - python .\ardupilot_methodic_configurator\frontend_tkinter_component_editor.py
• Parameter Editor - python .\ardupilot_methodic_configurator\frontend_tkinter_parameter_editor.py
• Motor Test - python .\ardupilot_methodic_configurator\frontend_tkinter_motor_test.py

Only after each one performs 100% as expected, they are integrated and tested together. This speeds up the development process.

System testing

Here the integrated application was tested against the system requirements defined above. The tests were conducted on windows and Linux machines using multiple different flight controllers and firmware versions. The software is automatically build and distributed using the github CD pipeline.

Acceptance testing

The software was tested by multiple users with different skill levels, languages, flight controller and backgrounds. The feedback was used to improve the user interface and user experience. The software is ready for production use since November 2024.

DevOps

The software is feature complete and stable with a user base of hundreds of users, we switched from the V-Model to DevOps development process on November 2024. This provides faster response to requirements changes and additions.

Do a release

The release process is automated. To do a release navigate to the bump_version_and_tag workflow and select Run Workflow enter the version and the description and press the green Run Workflow button.

This site is open source. Improve this page.