Changing parameters in APM_Config.h and uploading requires CLI reset to take effect

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Change a gain in APM_Config.h
2.  Upload
3.  CLI show

What is the expected output? What do you see instead?
A simple gain change in APM_Config.h requires a lot more steps to take effect 
than before the CLI. The user must upload, then startup in CLI and do a reset 
and then setup the radio. etc.  

What version of the product are you using? On what operating system?
Beta of 10/17/10

Please provide any additional information below.

Original issue reported on code.google.com by whit...@gmail.com on 19 Oct 2010 at 4:49

[GoogleCodeExporter]

  What I have a problem with is all the extra work (CLI reset and radio) required now to make simple gain changes and that if you forget to run CLI and you don't have your laptop with you when you go to fly, you can't get the latest parameter values. I personally would prefer that a "reset" be done on startup except that the "radio" parameters be left alone. Some concept of having an optional startup sequence(maybe just in FBW-A mode or something) to disable the reset could be valuable to those who want to update the code but not the EEPROM parameters. Many of us are trying to tune our gains and don't want to do the reset/radio every upload.

Original comment by whit...@gmail.com on 19 Oct 2010 at 7:02

[GoogleCodeExporter]

Have a look at the APM planner, on the SVN. This has the ability to change the 
pid gains. (0.4.8)

Original comment by Meee...@gmail.com on 19 Oct 2010 at 11:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This behavior is "correct" and intentional.  We do not want it to reset every 
time it performs a ground start.  This is because there are more ways to change 
parameters like PID gains than just using reset, and users may have changed a 
value by another method and not want it changed back to the value in the config 
file.

I'll leave the issue open and look at implementing a flag in the config file 
that would cause a "reset" to occur with each ground start, as time allows.

Original comment by dewei...@gmail.com on 20 Oct 2010 at 1:22

• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Also, take a look at maybe using GCS_DebugTerminal; I added it recently and 
haven't had time to write the documentation, but just connect your telemetry 
port to a dumb terminal and send a carriage return to get started (it will 
suggest commands for you to use).  For the gains commands, type set k -?

Original comment by bjpcalt...@gmail.com on 20 Oct 2010 at 6:44

[GoogleCodeExporter]

OK you all!
   Maybe what I am saying is that not everybody knew that you have to do a CLI reset/radio everytime (not just the first time)unless you are using a new tool like ArduMegaPlanner. I wasted some flights thinking I was testing new gains. One thing we are really missing is an APM forum with sticky threads about new features. Things get changed and few of us know about them - I try to constantly review the ArduPilotMega forum page (page 44, 45, ...), home page, and the issues page - maybe there could be a NOTES tab in the wiki?. I realize that we are only in BETA but still. I really appreciate the developers' efforts and massive time expended but us flight testers need a little respect as well.

Original comment by whit...@gmail.com on 20 Oct 2010 at 10:09

[GoogleCodeExporter]

You can sort of see a list of changes/enhancements by looking at the SVN log 
for the code base (anyone know how to access that without a SVN client on 
Google Code?).  But agreed, especially changes that break or fundamentally 
change the behavior of the APM would be nice to have flagged.  I'd really like 
to start something like the Issues list to document test flights.  That way, 
people could quickly see that no one can get r52389 to work while almost 
everyone has success with r52386.  If at least a few people confirm that they 
would provide information and reports to something like this, I would be 
interested in coding and hosting the web interface.  Let me know if you think 
this would be interesting :)

Original comment by bjpcalt...@gmail.com on 21 Oct 2010 at 11:07

[GoogleCodeExporter]

I have just had my first outing with the APM in my twinstar, which went very 
well. You guys have done a really good job!

@bjpcaltech, I'd be interested in helping out with testing reports if you 
decide to create a section for it. I have already started my own log book to 
keep track of things.

If you did make this new section, it could also be useful to get an idea of 
what airframes users are flying and what gain settings work well.

Original comment by cgw...@gmail.com on 22 Oct 2010 at 4:35

[GoogleCodeExporter]

Original comment by dewei...@gmail.com on 25 Oct 2010 at 5:30

• Added labels: Milestone-Later