I’m working on a new tool to make Ardupilot easy, especially for those using INAV (it can import the INAV configuration directly into Ardupilot, except for things that don’t map directly, like navigational parameters and PIDs). It is still very much an alpha, and I have limited time and resources for testing. If you are interested, here’s the GitHub link.
The idea is not to replace Mission Planner but to lower the barrier for those who are starting with an easy-to-use interface and a wizard with the philosophy “from zero to first flight in minutes”.
Please don’t—INAV is a completely different system. There is no simple way to import an INAV configuration into an ArduPilot system. It only causes half-baked configurations, confusion, and unnecessary issues.
There is a detailed, step-by-step ArduPilot configuration system called the Methodic Configurator, which provides documentation, reasoning, and examples for each configuration step in the correct order.
@Eosbandi Hi Andreas. I would appreciate it if you could take a look at the project and test it. Just saying “please don’t” isn’t very productive, right? Maybe I’m being naïve, but it seems to be working with my limited testing, and that’s why I reached this community, to gather tests and feedback. Also, importing from INAV is just one way to do it; you can use the wizard by itself or just configure it in your own terms.
You know what? Maybe I am spending my time and effort in the wrong place because to come here to offer something and the first thing I read is “please don’t” is not very reasuring. The project will continue and feel free to use it or not. I’m done here.
The main issue is that Ardupilot has much more params for things - more imus, more sensors, more calibrations and what not. Inav has far more less stuff.
As @Eosbandi said, users might see that imu parameters are updated - but only first imu and others aren’t calibrated and they might skip those steps.
Haven’t tested ardudeck, but it seems to have similar features. Correct me if I am wrong @codeforges.
Not discouraging you, but this inav → Ardupilot thing is slightly dangerous.
You do seem to have listed these risks in the readme file on GitHub, but I would atleast suggest making them slightly more prominent about what it doesn’t migrate
I did some check on your inav import code, and honestly it a big mess, to name some problems :
Using parameter name that does not exists since decades (MOT_YAW_SV_REV)
Missing out important params that could be set from the available data (MOT_BAT_VOLT_MIN/MAX)
Wrong GNSS field conversion
Setting Gyro filter, but not set params that are derived from that
Wrong param name for GNSS_MODE
etc, etc…
I still believe that converting parameters from INAV to AP is a very bad idea.
Also believe that " philosophy “from zero to first flight in minutes” is even more dangerous.
Strongly suspect this, among several other pretty glaring indicators, to be AI hallucination/slop. We are seeing these projects at an increasing rate, and I think it’s ok to give blunt/harsh feedback when warranted. Yes, we want to be welcoming, but also, it does not serve the community to let these kinds of things go unchecked.
Yes i was thinking about conversion but it was in fact not reasonable , MSP is actually well designed architecture , it deserves its own credits and its easier to work with that rather than converting things.
Its little bit neache in compariso to ardupilot but still , i wanted to support it.
And with cli you can do also many things , for example legacy boards can completly be supported with cli.