Misc

ARCHITECTURE.md

@@ -4,16 +4,16 @@ Before we decided on a software architecture or programming language or toolkit
 
 ## Software requirements
 
-The goal of this software is to automate some of the tasks involved in configuring and tuning an ArduPilot based vehicle.
+The goal of this software is to automate some of the tasks involved in configuring and tuning an ArduPilot-based vehicle.
 The method it follows is explained in the [How to methodically tune (almost) any multicopter using ArduCopter forum Blog post](https://discuss.ardupilot.org/t/how-to-methodically-tune-almost-any-multicopter-using-arducopter-4-4-x/110842/1). 
 This list of functionalities provides a comprehensive overview of the software's capabilities and can serve as a starting point for further development and refinement.
 
 ### 1. Parameter Configuration Management
 - The software must allow users to view and manage drone parameters.
 - Users should be able to select an intermediate parameter file from a list of available files.
-- The software must display a table of parameters with columns for parameter name, current value, new value, unit, write to flight controller, and change reason.
+- The software must display a table of parameters with columns for the parameter name, current value, new value, unit, write to flight controller, and change reason.
 - The software must validate the new parameter values and handle out-of-bounds values gracefully, reverting to the old value if the user chooses not to use the new value.
-- The software must save parameter changes to both the flight controller and to the intermediate parameter files
+- The software must save parameter changes to both the flight controller and the intermediate parameter files
 
 ### 2. Communication Protocols
 - The software must support communication with the drone's flight controller using MAVlink and FTP over MAVLink protocols.
@@ -30,7 +30,7 @@ This list of functionalities provides a comprehensive overview of the software's
 - The software must provide feedback to the user, such as success or error messages, when performing actions like writing parameters to the flight controller.
 - Users should be able to skip to the next parameter file without writing changes.
 - The software must ensure that all changes made to entry widgets are processed before proceeding with other actions, such as writing parameters to the flight controller.
-- Read-only parameters are displayed in red, Sensor Calibrations are displayed in yellow, non existing parameters in blue
+- Read-only parameters are displayed in red, Sensor Calibrations are displayed in yellow and non-existing parameters in blue
 - Users should be able to edit the new value for each parameter directly in the table.
 - Users should be able to edit the reason changed for each parameter directly in the table.
 - The software must provide tooltips for each parameter to explain their purpose and usage.
@@ -50,19 +50,19 @@ This list of functionalities provides a comprehensive overview of the software's
 ### 8. Parameter File Management
 - The software must support the loading and parsing of parameter files.
 - Users should be able to navigate through different parameter files and select the one to be used.
-- Comments are first class citizens and are preserved when reading/writing files
-- The software must write in the end of the configuration following summary files:
+- Comments are first-class citizens and are preserved when reading/writing files
+- The software must write at the end of the configuration the following summary files:
   - Complete flight controller "reason changed" annotated parameters in "complete.param" file
-  - Non default, read-only "reason changed" annotated parameters in, "non-default_read-only.param" file
-  - Non default, writable calibrations "reason changed" annotated parameters in "non-default_writable_calibrations.param" file
-  - Non default, writable non-calibrations "reason changed" annotated parameters in "non-default_writable_non-calibrations.param" file
+  - Non-default, read-only "reason changed" annotated parameters in, "non-default_read-only.param" file
+  - Non-default, writable calibrations "reason changed" annotated parameters in "non-default_writable_calibrations.param" file
+  - Non-default, writable non-calibrations "reason changed" annotated parameters in "non-default_writable_non-calibrations.param" file
 
 
 ### 9. Customization and Extensibility
 - The software must be extensible to support new drone models and parameter configurations.
-- Users should be able to customize the software's behavior through configuration files: file_documentation.json and *.param.
-- Development should use industry best-practices:
-  - [Test driven development](https://en.wikipedia.org/wiki/Test-driven_development) (TDD)
+- Users should be able to customize the software's behavior through configuration files: ArduCopter_configuration_steps.json and *.param.
+- Development should use industry best practices:
+  - [Test-driven development](https://en.wikipedia.org/wiki/Test-driven_development) (TDD)
   - [DevOps](https://en.wikipedia.org/wiki/DevOps)
 
 ### 10. Performance and Efficiency
@@ -76,20 +76,21 @@ To satisfy the software requirements described above the following software arch
 
 It consists of four main components:
 
-1. the application itself, does the command line parsing and starts the other processes
-2. the local filesystem backend, does file I/O on the local file system. Operates mostly on parameter files and metadata/documentation files
-3. the flight controller backend, does communication with the flight controller
-4. the tkinter frontend, this is the GUI the user interacts with
+1. the application itself does the command line parsing and starts the other processes
+2. the local filesystem backend does file I/O on the local file system. Operates mostly on parameter files and metadata/documentation files
+3. the flight controller backend communicates with the flight controller
+4. the tkinter frontend, which is the GUI the user interacts with
   1. `frontend_tkinter_base.py`
   2. `frontend_tkinter_connection_selection.py`
   3. `frontend_tkinter_directory_selection.py`
   4. `frontend_tkinter_component_editor.py`
   5. `frontend_tkinter_parameter_editor.py`
+  6. `frontend_tkinter_parameter_editor_table.py`
 
 ![Software Architecture diagram](images/Architecture.drawio.png)
 
 The parts can be individually tested, and do have unit tests.
-They can also be exchanged, for instance tkinter-frontend can be replaced with vxwidgets or pyQt.
+They can also be exchanged, for instance, tkinter-frontend can be replaced with vxwidgets or pyQt.
 
-In the future we might port the entire application into a client-based web-application.
+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.

MethodicConfigurator/ardupilot_methodic_configurator.py

@@ -107,6 +107,7 @@ def main():
 
     if not args.skip_component_editor:
         component_editor_window = ComponentEditorWindow(VERSION, local_filesystem)
+        component_editor_window.set_vehicle_type_and_version(vehicle_type, flight_controller.version)
         component_editor_window.root.mainloop()
 
     # Call the GUI function with the starting intermediate parameter file