individual replacement of defaults in code

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

individual replacement of defaults in code

Postby Hamburger » Fri Aug 30, 2013 2:46 pm

With some of my copters, the provided universal defaults do not come even close to what is required to get the thing to fly without crashing - this is especially true for helicopters. So pressing the reset-button in the gui will yield a copter config which is non-flyable. That has lead me to replace the provided code section where defaults are set (in eeprom.cpp) with my own. This is especially handy if you do not have a gui to load the specific (saved earlier) defaults.mwi file at the field.

How to use:
To get an individual set of defaults I save a working set of values via gui into a copter.mwi file.
Then use a converter to turn this into some c-code.
If needed, manually edit that c-code to suit your taste.
compile and upload
every reset only resets to a known good starting point for this copter

advantage:
have proven copter specific good starting point of defaults for this copter in the firmware, available at touch of 'reset'.
If tuning pids goes wrong, simply press reset and start all over with a proven set of good defaults for your copter.


The modified code to easily use that snippet from config.h without editing eeprom.cpp will follow soon.
Some code to invoke reset via the lcd.config menu will follow soon.
Here is the converter script;
Code: Select all
#!/usr/bin/perl -w
#
# mwii2c_defaults_converter
# converts a single .mwi file (as generated by doing a save in the MWii Config GUI) to the corresponding c code fragment.
# Purpose is to replace the hard coded defaults in eeprom.cpp with a tailored set of defaults that have somehow proven to
# be a better starting point for future tuning than the universally supplied ones.
#
# Usage:
# mwii2c_defaults_converter < your.mwi > your.c
# this will read your.mwi file andwrite the c-code section to your.c file
#
# v0.1
# - initial version
#

$\ = "\n";
$t = localtime(time());
print "/* autogenerated $t */";
while (<>) {
   if (m#<entry +key=\"(.*)\">(.*)</entry>#) {
      $k = $1;
      $v = $2;
      #print "$k = $v";
      print "conf.pid[ROLL].P8 = ", 10*$v,';'    if ($k eq "pid.0.p");
      print "conf.pid[ROLL].I8 = ", 1000*$v,';'    if ($k eq "pid.0.i");
      print "conf.pid[ROLL].D8 = ", 1*$v,';'       if ($k eq "pid.0.d");
      print "conf.pid[PITCH].P8 = ", 10*$v,';'    if ($k eq "pid.1.p");
      print "conf.pid[PITCH].I8 = ", 1000*$v,';'    if ($k eq "pid.1.i");
      print "conf.pid[PITCH].D8 = ", 1*$v,';'    if ($k eq "pid.1.d");
      print "conf.pid[YAW].P8 = ", 10*$v,';'       if ($k eq "pid.2.p");
      print "conf.pid[YAW].I8 = ", 1000*$v,';'    if ($k eq "pid.2.i");
      print "conf.pid[YAW].D8 = ", 1*$v,';'       if ($k eq "pid.2.d");
      print "conf.pid[PIDALT].P8 = ", 10*$v,';'    if ($k eq "pid.3.p");
      print "conf.pid[PIDALT].I8 = ", 1000*$v,';'    if ($k eq "pid.3.i");
      print "conf.pid[PIDALT].D8 = ", 1*$v,';'    if ($k eq "pid.3.d");
      print "conf.pid[PIDPOS].P8 = ", 100*$v,';'    if ($k eq "pid.4.p");
      print "conf.pid[PIDPOS].I8 = ", 1000*$v,';'    if ($k eq "pid.4.i");
      print "conf.pid[PIDPOS].D8 = ", 1*$v,';'    if ($k eq "pid.4.d");
      print "conf.pid[PIDPOSR].P8 = ", 10*$v,';'    if ($k eq "pid.5.p");
      print "conf.pid[PIDPOSR].I8 = ", 1000*$v,';'    if ($k eq "pid.5.i");
      print "conf.pid[PIDPOSR].D8 = ", 1000*$v,';'    if ($k eq "pid.5.d");
      print "conf.pid[PIDNAVR].P8 = ", 10*$v,';'    if ($k eq "pid.6.p");
      print "conf.pid[PIDNAVR].I8 = ", 1000*$v,';'    if ($k eq "pid.6.i");
      print "conf.pid[PIDNAVR].D8 = ", 100*$v,';'    if ($k eq "pid.6.d");
      print "conf.pid[PIDLEVEL].P8 = ", 10*$v,';'    if ($k eq "pid.7.p");
      print "conf.pid[PIDLEVEL].I8 = ", 1000*$v,';'    if ($k eq "pid.7.i");
      print "conf.pid[PIDLEVEL].D8 = ", 1*$v,';'    if ($k eq "pid.7.d");
      print "conf.pid[PIDMAG].P8 = ", 10*$v,';'    if ($k eq "pid.8.p");
      #print "conf.pid[PIDMAG].I8 = ", 1000*$v,';'    if ($k eq "pid.8.i");
      #print "conf.pid[PIDMAG].D8 = ", 1*$v,';'    if ($k eq "pid.8.d");
      print "conf.pid[PIDVEL].P8 = ", 10*$v,';'    if ($k eq "pid.9.p");
      print "conf.pid[PIDVEL].I8 = ", 1000*$v,';'    if ($k eq "pid.9.i");
      print "conf.pid[PIDVEL].D8 = ", 1*$v,';'    if ($k eq "pid.9.d");

      print "conf.powerTrigger1 = ",    1*$v,';'    if ($k eq "power.trigger");
      print "conf.rcExpo8 = "   ,   100*$v,';'    if ($k eq "rc.expo");
      print "conf.rcRate8 = ",    100*$v,';'    if ($k eq "rc.rate");
      print "conf.rollPitchRate = ",    100*$v,';'    if ($k eq "rc.rollpitch.rate");
      print "conf.thrExpo8 = ",    100*$v,';'    if ($k eq "rc.throttle.expo");
      print "conf.thrMid8 = ",    100*$v,';'    if ($k eq "rc.throttle.mid");
      print "conf.dynThrPID = ",    100*$v,';'    if ($k eq "rc.throttle.rate");
      print "conf.yawRate = ",    100*$v,';'    if ($k eq "rc.yaw.rate");

   }
}
print "\n";
print "
    for(i=0;i<CHECKBOXITEMS;i++) {conf.activate[i] = 0;}
    conf.angleTrim[0] = 0; conf.angleTrim[1] = 0;
";
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: individual replacement of defaults in code

Postby Nickman1200 » Fri Aug 30, 2013 7:17 pm

This is relay handy. Will use on my copter when i find the time.
Thanks Hamburger.
Nickman1200
 
Posts: 36
Joined: Sat Jul 06, 2013 10:31 am

Re: individual replacement of defaults in code

Postby Hamburger » Sat Aug 31, 2013 2:36 pm

The modified code to easily use that snippet from config.h without editing eeprom.cpp will follow soon.
Some code to invoke reset via the lcd.config menu will follow soon.

done in r1559
Here is the converter script

mwii2c_defaults_converter_v02.zip
(1.51 KiB) Downloaded 216 times

Now you can manually add code for other config values like
Code: Select all
    conf.armedtimewarning = 540;
    conf.activate[BOXHORIZON] = 6;
    conf.activate[BOXGOV] = 7;
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: individual replacement of defaults in code

Postby Hamburger » Sat Aug 31, 2013 6:30 pm

from now on, latest converter script can be found in my branch here
http://code.google.com/p/multiwii/sourc ... sConverter
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: individual replacement of defaults in code

Postby Nickman1200 » Sat Aug 31, 2013 6:32 pm

In the voice of Mr. Burns: "Eeeeexellent!"
Nickman1200
 
Posts: 36
Joined: Sat Jul 06, 2013 10:31 am

Re: individual replacement of defaults in code

Postby picstart » Sat Aug 31, 2013 7:46 pm

Great idea.
Most will agree that the multiwii code has some complexity. Next it supports a variety of flying devices so code is both generic and specific...not much of a problem if using Eclipse for the IDE since it will grey out any blocks not active since a define didn't include them. Nevertheless there is from time to time a need to make a modification that is unique to a user's flying device.
This places this modded code into the general scheme of things so a newer version on Mutiwii can impact the mods ( this is more than just fusing the new Multiwii code with the mods).
It is not that it is impossible it is just that I rather leverage the flight testing others do before a multiwii release. The risk of fusing a large amount of modified code code is that it could do violence to the tested code.

Observation.
I have some hardware specific needs which could mess the timing restraint inherent in the round robin apportioning of time to routines in the main Multiwii loop. To avoid this, I get data out and in with a write and a read to the I2C bus ( a single user specific routine called and run by the 2560) and move the data to a ( just happens to be a PIC 24 processor configured as an I2C slave). The 2560 MCU that runs multiwii isn't overloaded as yet but it is chained to the sensors and the priority of keeping the flying device in the air ( something that must not change).
Anyway , I was saving the parameters to the PIC memory and restoring as necessary to Multiwii. This new feature is a pleasant alternative. Thanks.

Musings.
An advantage of the daughter processor and the I2C link is that unless the Multiwii uses all the 400k band width, the PIC code is out of the way of the Multiwii development plus it is asynchronous with the 2560 so the PIC can run at up to 140 Mz (if needed to support its appoint tasks). An inclusion of a single routine to transfer data to and from a daughter board and some I2C bandwidth is the only impact on Multiwii.

If there's a flaw in this approach please comment.
picstart
 
Posts: 10
Joined: Fri Aug 09, 2013 9:30 pm
Location: Florida USA

Re: individual replacement of defaults in code

Postby Hamburger » Sat Aug 31, 2013 9:19 pm

picstart wrote:Great idea.
Most will agree that the multiwii code has some complexity. Next it supports a variety of flying devices so code is both generic and specific...not much of a problem if using Eclipse for the IDE since it will grey out any blocks not active since a define didn't include them. Nevertheless there is from time to time a need to make a modification that is unique to a user's flying device.
This places this modded code into the general scheme of things so a newer version on Mutiwii can impact the mods ( this is more than just fusing the new Multiwii code with the mods).
It is not that it is impossible it is just that I rather leverage the flight testing others do before a multiwii release. The risk of fusing a large amount of modified code code is that it could do violence to the tested code.

Observation.
I have some hardware specific needs which could mess the timing restraint inherent in the round robin apportioning of time to routines in the main Multiwii loop. To avoid this, I get data out and in with a write and a read to the I2C bus ( a single user specific routine called and run by the 2560) and move the data to a ( just happens to be a PIC 24 processor configured as an I2C slave). The 2560 MCU that runs multiwii isn't overloaded as yet but it is chained to the sensors and the priority of keeping the flying device in the air ( something that must not change).
Anyway , I was saving the parameters to the PIC memory and restoring as necessary to Multiwii. This new feature is a pleasant alternative. Thanks.

Musings.
An advantage of the daughter processor and the I2C link is that unless the Multiwii uses all the 400k band width, the PIC code is out of the way of the Multiwii development plus it is asynchronous with the 2560 so the PIC can run at up to 140 Mz (if needed to support its appoint tasks). An inclusion of a single routine to transfer data to and from a daughter board and some I2C bandwidth is the only impact on Multiwii.

If there's a flaw in this approach please comment.

I am sorry to say I fail to see any relevance or resemblance to the aforementioned feature of using one's own private defaults instead of the universal defaults.
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air


Return to Software development

Who is online

Users browsing this forum: No registered users and 8 guests

cron