Unusable on (Gentoo) Linux with venv installation

[mbuzdalov]

Is there an existing issue for this?

• I have searched the existing issues

Description of the bug

Configurator refers to a non-existent vehicle template "~/.local/ardupilot_methodic_configurator/vehicle_templates/ArduCopter/diatone_taycan_mxc/4.5.x-params". More info:

• "~" is the usual user's home directory.
• The directory "~/.local/ardupilot_methodic_configurator" does not exist at all.
• The directory with templates exists in the root of the venv directory (which was also the current directory).
• The software does not allow to change that directory: instead, the button on the right is about switch between vehicle templates within the (apparently hardcoded) directory with templates.

Chances are, the configurator confuses the ~/.local directory and the current directory in different code locations. I have no idea why.

Steps To Reproduce

• Create a venv environment (in my case, cd into a directory with Ardupilot repos, then python -m venv _venv_)
• Activate the environment (source _venv_/bin/activate)
• Connect the vehicle and wait until it boots
• Go to the virtual environment directory: cd _venv_
• Start the configurator: ardupilot_methodic_configurator
• Attempt to choose source template, observe the empty list of templates.
• Be unable to proceed at all.

Expected behavior

Expected to be able to choose one of the templates.

Screenshots / Logs

No response

Software information

• Operating system: Gentoo Linux, Python 3.12.8
• arduPilot Methodic Configuration version: 1.0.5

Additional context

No response

[amilcarlucas]

This commit will help me diagnose the issue: 042f116
Can you re-test by checking out the code and install locally using:

git clone https://github.com/ArduPilot/MethodicConfigurator.git
cd MethodicConfigurator
python -m venv .ardupilot_methodic_configurator_venv
source .ardupilot_methodic_configurator_venv/bin/activate
pip install -E .

[mbuzdalov]

Assuming it is pip install -e . (a small "e"), this seems to work - at least it moved to the next stage, describing components.

Based on changes in this commit, I see that only debugging output was added. So, either the bug has been fixed before, or version 1.0.5 available via pip was built somewhat differently, or I don't know...

[mbuzdalov]

The debug output apparently is not enabled if one just starts the configurator (logging messages start from INFO), so I did not see the newly introduced message about the command line.

There is plenty of error-level output though, but it is quite clear where it comes from (the ArduPilot version the vehicle runs is a slight modification to master, which identifies as 4.7.0-something, so the configurator tries to look up parameter definitions from 4.7-stable and fails). UPD: it probably tries to fall over to dev version, but it does not look healthy even after this... This is a whole different issue, however.

[amilcarlucas]

My fault. You should start ardupilot_methodic_configurator with --loglevel=DEBUG

and the second issue should be in a separate bug report please.

[mbuzdalov]

Running with --loglevel DEBUG produces the following before offering to choose the template:

2025-01-08 21:27:47,453 - DEBUG - ComPort - /dev/ttyACM0, Description: FlywooF405S-AIO
2025-01-08 21:27:47,453 - INFO - Available connection ports are:
2025-01-08 21:27:47,453 - INFO - /dev/ttyACM0 - FlywooF405S-AIO
2025-01-08 21:27:47,453 - INFO - tcp:127.0.0.1:5760 - tcp:127.0.0.1:5760
2025-01-08 21:27:47,454 - INFO - udp:127.0.0.1:14550 - udp:127.0.0.1:14550
2025-01-08 21:27:47,459 - DEBUG - Auto-detected device /dev/serial/by-id/usb-ArduPilot_FlywooF405S-AIO_460040000151313331373330-if00
2025-01-08 21:27:47,459 - DEBUG - Resolved soft link /dev/serial/by-id/usb-ArduPilot_FlywooF405S-AIO_460040000151313331373330-if00 to /dev/ttyACM0
2025-01-08 21:27:47,459 - INFO - Will connect to /dev/ttyACM0
2025-01-08 21:27:47,461 - DEBUG - Waiting for MAVLink heartbeat
2025-01-08 21:27:47,463 - DEBUG - Connection established with systemID 1, componentID 1.
2025-01-08 21:27:47,463 - INFO - Autopilot type ArduPilot - Plane/Copter/Rover/Sub/Tracker, https://ardupilot.org
2025-01-08 21:27:47,463 - INFO - Vehicle type: Quadrotor running ArduCopter firmware
2025-01-08 21:27:48,476 - INFO - FC banner ArduCopter V4.7.0-dev (2db5505b)
2025-01-08 21:27:48,476 - INFO - FC banner FlywooF405S-AIO 00400046 33315101 30333731
2025-01-08 21:27:48,476 - INFO - FC banner RCOut: DS300:1-4 NeoP:5
2025-01-08 21:27:48,476 - INFO - FC banner IMU0: normal sampling 1.0kHz/1.0kHz
2025-01-08 21:27:48,476 - INFO - FC banner Frame: QUAD/X_REV
2025-01-08 21:27:48,476 - DEBUG - Vehicle type not set explicitly, auto-detected ArduCopter.
2025-01-08 21:27:48,605 - INFO - Firmware Version: 4.7.0 dev
2025-01-08 21:27:48,605 - INFO - Firmware first 8 hex bytes of the FC git hash: 2db5505b
2025-01-08 21:27:48,605 - INFO - Firmware first 8 hex bytes of the ChibiOS git hash: 88b84600
2025-01-08 21:27:48,606 - INFO - Flight Controller firmware type: FlywooF405S-AIO (1099)
2025-01-08 21:27:48,606 - INFO - Flight Controller HW / board version: 0
2025-01-08 21:27:48,606 - INFO - Flight Controller USB vendor ID: ArduPilot
2025-01-08 21:27:48,606 - INFO - Flight Controller USB product ID: ACNS-CM4Pilot
2025-01-08 21:27:48,635 - INFO - MAVFTP is supported by the /dev/ttyACM0 flight controller
2025-01-08 21:27:53,141 - INFO - Outputted 1157 parameters to complete.param
2025-01-08 21:27:53,143 - INFO - Outputted 1157 parameters to 00_default.param
2025-01-08 21:27:56,911 - DEBUG - File 'vehicle_components.json' not found in /home/maxbuzz/repos/github/ArduPilot/MethodicConfigurator.
2025-01-08 21:27:56,956 - DEBUG - current script directory: /home/maxbuzz/repos/github/ArduPilot/MethodicConfigurator/ardupilot_methodic_configurator
2025-01-08 21:27:56,956 - DEBUG - site_directory: /home/maxbuzz/repos/github/ArduPilot/MethodicConfigurator/ardupilot_methodic_configurator

where two last lines are definitely relevant. Template selection currently works. This is not a clean run because now I have existing vehicle configurations (not complete at all, but still), but I think that the issue being discussed does not manifest as of now.

I don't know whether we should close this issue now, or wait for the next release to see whether it gets solved in what pip downloads from the central storage.

[amilcarlucas]

There is a new pip release with that debug output. Please update and re-test.