This post is basically to gain an insight into people’s thoughts and needs.
With the release of AC3.5 (which is awesome - you should all update!!!), a slight negative has been that default param files have been withdrawn from missionplanner and QGC.
This hasn’t impacted me: I’m comfortable tuning a multicopter, all my copters are scratch built except for Solo, and the Solo community has generated 3.5 Params.
But my view is that it is important for ArduPilot to be easy to use for everyone, and that easy-to-upload Params for Iris, Flamewheel, Racers, 3DR frames etc are a fundamental part of this.
So here’s the question: does the ArduPilot community want a database of configurations and param files?
I’ll leave this post open for 2 weeks, and based on feedback will put forward a proposal (or get back in my box…).
You’re talking about the little dropdown where you can select a parameter file to load? This is actually easy!
The parameter files available in that dropdown are located here: https://github.com/ArduPilot/ardupilot/commits/master/Tools/Frame_params.
The old ones were removed because they are no longer compatible with ArduCopter 3.5+. A lot of them were probably long since useless even with 3.4+ too. 3DR doesn’t maintain those files anymore since they’re out of that business. The ones that remain are apparently kept up to date by whoever feels compelled to maintain them. You’ll notice I put the Solo file in there.
New files can be added at any time. You can make a param file and do a PR in github to load it. Once it is in there, it will be available for all through that dropdown in Mission Planner and QGC. The parameter file should only be those that differ from ArduCopter 3.5 defaults. So it shouldn’t be a file with 800 parameters. Usually they’re more like 50 to 150 depending on the vehicle.
If you’re not familiar with doing differentials on parameter files and/or the github PR process, I can take care of that for you. Just save a parameter file off your properly configured Iris and send it to me. I’ll run the diff and get it online. I can do it myself faster than I can explain the process 
Thanks for the offer Matt, and thanks for your work with Solo! My question is more about getting a feel for whether or not there is actually demand for a database of standard params, and if there is, what frame types and configs people want/need.
IMHO the process from there needs to have a bit more rigour than just putting in a PR with a param file/diff: different weights, flight profiles, wind conditions, payloads (and dropping them etc), build quality, prop balance, vibration etc etc all effect how robust a tune is for a given configuration, so having a defined method to generate, validate and document “official” params is important. For non-RTF rigs the build needs to be documented as well (ie flight controller, motors, escs, battery, props).
Basically, there is a bunch of work required to do all that properly - and if there isn’t a demand, or the project doesn’t want to be responsible for them, then it isn’t worth the effort!
It’s not intended to be a repository for personal configurations that may change on a daily basis based on weather and payload. That is the operator’s responsibility. It’s intended to be the basic required parameters for the base vehicle configuration. That may include basic tuning that will get it airborne, and expect the operator fine tune it (or auto-tune). Or it could include a tried and true set of tuning parameters like we did with the Solo.
In the case of an Iris, it is pretty cut and dry. Anyone with a basic well tuned and properly functioning Iris will have a useful parameter set for this task.
Things that are always stripped out of the parameter files here:
- Calibration data (compass, accel, & gyro)
- Use case specific auxiliary functions
- Battery capacity and other user spec stuff
- Parameters that match ArduCopter defaults to begin with.
Matt, I think you’ve missed the point of the original post. Sigh.
I would like to see a standard param file list for the different RC devices. In my case quads and my 8 motor quad. There are times when I have wanted to go back to all “new install” startup params. I recently was trouble shooting a Pixhawk 2.1 and Here GPS issue. To get back to standard settings the dealer suggest I load something like rover so it would over write everything on the Pixhwawk 2.1. Then I could see if something had been changed that was causing the issue.
If this post is asking for a way to get back to factory settings or all settings as the original setup for that device, I’m all for it.
James, I didn’t miss it at all. You asked there should be a database of parameter files for specific vehicles. The answer is yes, and we already have it. It’s the frame params directory that pointed out. Those files are submitted by ArduPilot users. I explained what they need to be, and how to do it. I even offered to put one through for you if you has a specific need. What do you think I missed or can do better??
You can reset to default at any time and you don’t need to load another vehicle type to do it. See here: Parameter Reset — Copter documentation
You can also save your parameters to a file. So when you’re in a known good working state, just save the parameters to file for future use/reference.
There will never be a “standard param file list for the different RC devices” because there is no such thing as standard. The files available from the dropdown in Mission Planner (as described above) are for specific vehicles. There is no such things the standard configuration for a random custom built quad.
I understand where you’re coming from, but this post isn’t a request for help. It’s me offering to help, if the community feels that there is a need!
The git repo only contains param files from a small number of OEM’s and the core dev team (for Solo that includes you), and apart from Convergence and Solo, which are RTF except for switching out flight controllers, they are all RTF. Apart from Solo they are also relatively niche (ie do not ship with ArduPilot as the default firmware, so users have to choose to upgrade etc).
My point is that the current set of “official” params isn’t supporting the bulk of users, leading to my question
I know how to raise a PR to the repo, but there needs to be a validation process around “official” params and a way to document the configuration they apply to, as I mentioned above, which is really only warranted if there is a demand for it. Also, the git repo is only one possible solution: a completely uncontrolled, “use at own risk” community database is another, hosted by ardupilot or elsewhere, or a range of other options. That’s why I said
Maybe I should just get back in my box.