pre 2.4 version r1729

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
henfri
Posts: 17
Joined: Wed Aug 27, 2014 10:12 pm

Re: pre 2.4 version r1729

Post by henfri »

Hello Alex,

I' exited to see the progress. Thanks, I appreciate your work on MultiWii!
There is some code for FrSky Telemetry. Is there a chance that it can find its way into 2.4?

Here's the code for 2.3:
viewtopic.php?f=7&t=1929&start=150#p43296

Here's the documentation on Baseflight:
https://github.com/multiwii/baseflight/wiki/Telemetry

Let me know if I can support.

Greetings,
Hendrik

ldonnay
Posts: 10
Joined: Wed Dec 24, 2014 12:00 pm

pre 2.4 version r1729

Post by ldonnay »

Any News on auto tune or PID tuning with a POT?

ldonnay
Posts: 10
Joined: Wed Dec 24, 2014 12:00 pm

pre 2.4 version r1729

Post by ldonnay »

Any news on auto tune or PID tuning through POT?

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

Alexinparis wrote:
PatrikE wrote:I always calibrate Gyros before takeoff.
This also reset Baro Altitude.

Code: Select all

       if (rcSticks == THR_LO + YAW_LO + PIT_LO + ROL_CE) {    // GYRO calibration
          calibratingG=512;
          #if GPS
            GPS_reset_home_position();
          #endif
          #if BARO
            calibratingB=10;  // calibrate baro to new ground level (10 * 25 ms = ~250 ms non blocking)
          #endif
        }

Just do the stick commands for Gyro calib...
THR_LO + YAW_LO + PITCH_LO + ROLL_CENTER

And it's been in the code for ages..


Yes, this is exactly what i was going to respond.
I've just added a small note in the wiki: http://www.multiwii.com/wiki/index.php? ... figuration



Thank you. I was unaware of that.

However, I have to say IMHO it is far from optimal. When I calibrate my Gyros I make sure the Quad is absolutely level. I use a water gauge for this procedure. This is always done in the house, never on the field. To reset the altitude I would have to go through that procedure every time. IMO calibrating ACC and setting baro alt to zero are two different categories.

I think the baro reset should always be done when the multicopter is powered up and one should have the option of resetting baro alt at any time when the multicopter is disarmed e.g. through alt hold switch. I have a little bit of experience with baro chips especially the MS5611. Here is an example of my project that requires reliability and precision: http://www.altduino.de/
My problem is that MultiWii is very complex but I will try to help if I can.

Leo

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

For the release notes:
which version of arduino and processing are used for the baseline?

carlonb
Posts: 210
Joined: Sun Apr 03, 2011 6:29 pm

Re: pre 2.4 version r1729

Post by carlonb »

Leo wrote:
Alexinparis wrote:
PatrikE wrote:I always calibrate Gyros before takeoff.
This also reset Baro Altitude.
....
Just do the stick commands for Gyro calib...
THR_LO + YAW_LO + PITCH_LO + ROLL_CENTER

And it's been in the code for ages..


Yes, this is exactly what i was going to respond.
I've just added a small note in the wiki: http://www.multiwii.com/wiki/index.php? ... figuration


Thank you. I was unaware of that.

However, I have to say IMHO it is far from optimal. When I calibrate my Gyros I make sure the Quad is absolutely level. I use a water gauge for this procedure. This is always done in the house, never on the field. To reset the altitude I would have to go through that procedure every time. IMO calibrating ACC and setting baro alt to zero are two different categories.

I think the baro reset should always be done when the multicopter is powered up and one should have the option of resetting baro alt at any time when the multicopter is disarmed e.g. through alt hold switch. I have a little bit of experience with baro chips especially the MS5611. Here is an example of my project that requires reliability and precision: http://www.altduino.de/
My problem is that MultiWii is very complex but I will try to help if I can.
Leo

Happy New Year to all and MWii developers, I wish you the best new feature in 2015.

@ Leo,
There aren't issues calibrating the gyro (and the baro) in field as no need for a very leveled surface, this is mandatory for Acc.

@ Alex, Thanks for the explanation and I agree with you, about the Gyro (and baro) calibration I forgot it :D
Anyway I'm agree with Leo, I think that a "simple" #define ALTITUDE_RESET_ON_ARM is the best and "transparent" way to reset it for user where do not need to keep the take-off field altitude.
Carlo

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

carlonb wrote:@ Leo,
There aren't issues calibrating the gyro (and the baro) in field as no need for a very leveled surface, this is mandatory for Acc.


Carlo,

you are of course correct. I am going to blame my error on the excitement I'm having playing around with MultiWii and my Quadcopter :)

Leo

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

henfri wrote:Hello Alex,

I' exited to see the progress. Thanks, I appreciate your work on MultiWii!
There is some code for FrSky Telemetry. Is there a chance that it can find its way into 2.4?

Here's the code for 2.3:
viewtopic.php?f=7&t=1929&start=150#p43296

Here's the documentation on Baseflight:
https://github.com/multiwii/baseflight/wiki/Telemetry

Let me know if I can support.

Greetings,
Hendrik


Hi,
It won't be integrated for 2.4 , but probably after.
I expect it to be merged in Protocol.cpp by someone who use it. ie not me ;)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

ldonnay wrote:Any News on auto tune or PID tuning with a POT?

No plan for the moment to integrate both of this.
auto tune seems to be too much experimental currently.
It apparently works well for some, and not at all for others.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

Hamburger wrote:For the release notes:
which version of arduino and processing are used for the baseline?


The current stable release of Arduino IDE 1.0.6 is still the reference to valid dev in multiwii.
(even if in windows version, gcc is old, I know...)

For processing, I still use 1.5.1 to generate binaries. mainly because they are smaller.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

carlonb wrote:@ Alex, Thanks for the explanation and I agree with you, about the Gyro (and baro) calibration I forgot it :D
Anyway I'm agree with Leo, I think that a "simple" #define ALTITUDE_RESET_ON_ARM is the best and "transparent" way to reset it for user where do not need to keep the take-off field altitude.
Carlo


I think calibratingB=10;
inserted somewhere in the go_arm() function should do the work.
I won't change this for 2.4.
but noted after

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

I have made the following changes concerning resetting baro altitude on arm:

in config.h add in section 6:

Code: Select all

/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  6 - OPTIONAL FEATURES                                          *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /************************        Reset Baro altitude on arm         ********************/
  /* When unchecked a calibration of the baro altitude is preformed every time arming is activated */
  //#define ALTITUDE_RESET_ON_ARM

.........


in the MultiWii.ccp code section

Code: Select all

void go_arm() {
  if(calibratingG == 0
  #if defined(ONLYARMWHENFLAT)
    && f.ACC_CALIBRATED
  #endif
  #if defined(FAILSAFE)
    && failsafeCnt < 2
  #endif
  #if GPS && defined(ONLY_ALLOW_ARM_WITH_GPS_3DFIX)
    && (f.GPS_FIX && GPS_numSat >= 5)
  #endif
    ) {
    if(!f.ARMED && !f.BARO_MODE) { // arm now!
      f.ARMED = 1;
      #if defined(HEADFREE)
        headFreeModeHold = att.heading;
      #endif
      magHold = att.heading;
      #if defined(VBAT)
        if (analog.vbat > NO_VBAT) vbatMin = analog.vbat;
      #endif


      #ifdef ALTITUDE_RESET_ON_ARM
        #if BARO
          calibratingB = 10; // calibrate baro to new ground level (10 * 25 ms = ~250 ms non blocking)
        #endif
      #endif


      #ifdef LCD_TELEMETRY // reset some values when arming
        #if BARO
          BAROaltMax = alt.EstAlt;
        #endif
        #if GPS
          GPS_speedMax = 0;
        #endif
        #ifdef POWERMETER_HARD
          powerValueMaxMAH = 0;
        #endif
        #ifdef WATTS
          wattsMax = 0;
        #endif
      #endif
      #ifdef LOG_PERMANENT
        plog.arm++;           // #arm events
        plog.running = 1;       // toggle on arm & disarm to monitor for clean shutdown vs. powercut
        // write now.
        writePLog();
      #endif
    }
  } else if(!f.ARMED) {
    blinkLED(2,255,1);
    SET_ALARM(ALRM_FAC_ACC, ALRM_LVL_ON);
  }
}


My tests have shown it to work correctly. Somebody please verify...

This option is important for me. I almost crashed my Quadcopter in small trees while doing my mission plan tests :shock:

carlonb
Posts: 210
Joined: Sun Apr 03, 2011 6:29 pm

Re: pre 2.4 version r1729

Post by carlonb »

Leo wrote:I have made the following changes concerning resetting baro altitude on arm:
in config.h add in section 6:

Code: Select all

.........

in the MultiWii.ccp code section

Code: Select all

..........

My tests have shown it to work correctly. Somebody please verify...
This option is important for me. I almost crashed my Quadcopter in small trees while doing my mission plan tests :shock:

Thanks Alex and Leo for the tip, I will test it ASAP and give a feedback.
Carlo

carlonb
Posts: 210
Joined: Sun Apr 03, 2011 6:29 pm

Re: pre 2.4 version r1729

Post by carlonb »

Fly tested the new option "ALTITUDE_RESET_ON_ARM" as suggested by Leo few posts above, all run well.
I've done Horizon, Alt-Hold, RTH and a 4 point missions with a Auto-Landing.

Carlo

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: pre 2.4 version r1729

Post by shikra »

Thanks for testing

+1 for this feature to be added.

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

Alex, please consider putting it in rel. 2.4.
It's no risk and needs to be activated in order to take affect.

I have been using it for several days now.... I like it :)

User avatar
Rudi48
Posts: 32
Joined: Mon Sep 19, 2011 10:44 am
Location: Wiesbaden, Germany
Contact:

Re: pre 2.4 version r1729

Post by Rudi48 »

Hello Alex and Leo,

I have tested today the ALTITUDE_RESET_ON_ARM modification, and it works.
Thank you very much.

I find it very useful, and would appreciate to have it in the coming MultiWii 2.4 version. :)

Regards, Rudolf

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

ok, I've just added ALTITUDE_RESET_ON_ARM ;)

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

I found two bugs

- attached (nmea) gps can induce data chars which may get interpreted via evaluateOtherData() as serial commands. Bug: this may drop user into configuration.loop or trigger other functionality. - Cannot be avoided with disabling gps in config.h. Reason: in v2.3+ even on gps port, incoming data get scanned for msp and other command data. (as a nicety for promini and prmicro users, I presume; since r1715)
Partial Fix: in evaluateOtherData() do nothing if currentport == gps.serial port.

- MultiWii.cpp: syntax errors in alarm code fragments for INFLIGHT_ACC_CALIBRATION; since r1727.

Will submit patches soon.
Last edited by Hamburger on Thu Jan 08, 2015 1:29 am, edited 1 time in total.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

On my mega board with gyro, acc, baro, mag + lcd.telemetry, the loop time frequently exceeds the 2800 limit. I see value going up to 3200 every other second. The whole idea of enforced constant loop time gets ridiculed if the limit is too low.
Can others please comment on their loop times?
--
EDIT: plus attached serial GPS
Last edited by Hamburger on Thu Jan 08, 2015 9:42 am, edited 2 times in total.

User avatar
Rudi48
Posts: 32
Joined: Mon Sep 19, 2011 10:44 am
Location: Wiesbaden, Germany
Contact:

Re: pre 2.4 version r1729

Post by Rudi48 »

To the cycle maximum topic.
Yesterday I made a flight test for stability.
I got the following EZ-GUI log data, concerning the cycle time:

Code: Select all

Hardware: mega board with gyro, acc, baro, mag, GPS
MultiWii pre2.4r1729 with ALTITUDE_RESET_ON_ARM
Flight time: 14:51:01 - 14:52:32 -> 91 seconds
# separate GPAR dataset
$ grep GPAR MultiWiiLog_2015_01_07_14_51_01.el1 >Log_14-51_GPAR.csv
# count lines
$ wc -l Log_14-51_GPAR.csv
     761 Log_14-51_GPAR.csv
# cut out cycle time
$ cut -d , -f 3 Log_14-51_GPAR.csv >Log_14-51_cycle.csv
# find cycle values >= 3000 us
$ grep ^3 Log_14-51_cycle.csv >Log_14-51_cycle3k.csv
# count number of events
$ wc -l Log_14-51_cycle3k.csv
      21 Log_14-51_cycle3k.csv
# show values
$ cat Log_14-51_cycle3k.csv
3152
3208
3232
3204
3168
3212
3252
3228
3220
3076
3048
3084
3048
3056
3072
3080
3064
3040
3080
3020
3188

The log file is attached.

Regards, Rudolf
Attachments
MultiWiiLog_2015_01_07_14_51_01.el1.zip
EZ-GUI Log file
(42.36 KiB) Downloaded 150 times

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

Rudi48 wrote:To the cycle maximum topic.
...

thanks Rudolf. 21/761 ist about 3 percent with cycle times in the 3000 range.
Looks like increasing the constant to 3300 for this hardware might improve on predictability...

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

Hamburger wrote:I found two bugs
...
Will submit patches soon.

in r1737 now

FengShuiDrone
Posts: 234
Joined: Wed Dec 24, 2014 1:20 am
Location: ......

Re: pre 2.4 version r1729

Post by FengShuiDrone »

I believe that the gyro should auto calibrate upon each FC start. Am I correct on this? Should that not also reset baro to zero? Is it really necessary to manually calibrate again right after starting the FC? I have noticed that over time while sitting waiting for a satellite fix sometimes the baro drifts + or - up to 10 feet or more according to my EZ GUI (but not always.) I can see doing the calibration then. It is easy enough to do. Am I correct that the baro should reset to zero upon power up?

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

Hamburger wrote:
Rudi48 wrote:To the cycle maximum topic.
...

thanks Rudolf. 21/761 ist about 3 percent with cycle times in the 3000 range.
Looks like increasing the constant to 3300 for this hardware might improve on predictability...


I've checked my log from the last flight and sorted the first 20 highest values:

cycleTime
5180
5180
5180
5180
5180
5180
5180
4892
4892
4892
4892
4892
3228
3228
3228
3228
3228
3196
3196

Is there any danger with these high values?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

No danger. With original nunchuk sensor it was above 6000 always.
But if cycle time varies very much then it will have influence of flight characteristics because pid algorithm is not time invariant. In effect you tune for one value of cycletime. For a completely different values those pids will have a different effect.
So long as these runoffs happen rarely you will not notice.

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

Thanks. That's comforting to know.

I have set mine to #define LOOP_TIME 3300 now.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

FengShuiDrone wrote:I believe that the gyro should auto calibrate upon each FC start. Am I correct on this? Should that not also reset baro to zero? Is it really necessary to manually calibrate again right after starting the FC? I have noticed that over time while sitting waiting for a satellite fix sometimes the baro drifts + or - up to 10 feet or more according to my EZ GUI (but not always.) I can see doing the calibration then. It is easy enough to do. Am I correct that the baro should reset to zero upon power up?


At each FC start, there is a gyro cal + baro cal.
> I have noticed that over time while sitting waiting for a satellite fix sometimes the baro drifts + or - up to 10 feet
It's normal, because atmospheric pressure is not constant over time.
A baro can't do nothing with this... if used to evaluate an altitude.
It's fairly accurate to measure an altitude difference over short time, but not to report an absolute altitude.
That's why it's possible to reset it after (via a gyro cal stick, or via the new ALTITUDE_RESET_ON_ARM option)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

Hamburger wrote:On my mega board with gyro, acc, baro, mag + lcd.telemetry, the loop time frequently exceeds the 2800 limit. I see value going up to 3200 every other second. The whole idea of enforced constant loop time gets ridiculed if the limit is too low.
Can others please comment on their loop times?
--
EDIT: plus attached serial GPS


I think it's due to GPS computation when a new frame is available.
It only occurs some % of loop and could probably be still optimized.
For other tasks (mag alt, comp, baro, gps frame decoding), I think 2800 is a good default candidate with recent task optimizations.
So let's say 5% of >2800 among 95% of 2800 should not be noticeable.

User avatar
Plüschi
Posts: 433
Joined: Thu Feb 21, 2013 6:09 am

Re: pre 2.4 version r1729

Post by Plüschi »

Sorry guys but this is stupid:

Code: Select all

 while(1) {
    currentTime = micros();
    cycleTime = currentTime - previousTime;
    #if defined(LOOP_TIME)
      if (cycleTime >= LOOP_TIME) break;
    #else
      break; 
    #endif
  }
  previousTime = currentTime;


I use this instead:

Code: Select all

 if (cycleTime >= LOOP_TIME) computeIMU();
 else "do the rest" like baro gps etc

Which works pretty well, and if you dont do this:
previousTime = currentTime;
but this:
previousTime += looptime;
the timing may jitter but not lag. I.e. you get a stable number of cycles/second -> PID not affected.

robertha
Posts: 16
Joined: Sun Mar 17, 2013 10:12 pm

Re: pre 2.4 version r1729

Post by robertha »

I believe there is a wrong factor (100000) to convert PSENSOR current value (mA) to used power (mAh) - line 444 in Multiwii.cpp.

As we have also amperage available and when we found correct PINT2mA factor to convert measure value to mA, but in this case the consumed power number is wrong beacuse of above factor.

There is:

powerValue = ( conf.psensornull > p ? conf.psensornull - p : p - conf.psensornull); // do not use abs(), it would induce implicit cast to uint and overrun analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 100; // [100mA] //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA] pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/100000; // [10 mA * msec] lastRead = currentTime;

Should be:

powerValue = ( conf.psensornull > p ? conf.psensornull - p : p - conf.psensornull); // do not use abs(), it would induce implicit cast to uint and overrun analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 100; // [100mA] //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA] pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/360000; // [10 mA * msec] lastRead = currentTime;

As we convert 10mA*ms to 10mA*hour = 1000*3600/10

izeman
Posts: 57
Joined: Tue Sep 16, 2014 10:49 am

Re: pre 2.4 version r1729

Post by izeman »

i guess this has always been the case. mAh shown is to high by a factor 10 afair.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

analog.intPowerMeterSum is where computed mAh get stored. From memory without code.
What do you use to see this value?
I use it all the time together with capacity warning on serial display and it just works as expected.
Dunno for the gui though.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: pre 2.4 version r1729

Post by shikra »

MSP value for current changed by a factor of 10 at some point during 2.4 dev.

not sure if related to point above, but though would mention

QuadBow
Posts: 532
Joined: Fri Jan 04, 2013 10:06 am

Re: pre 2.4 version r1729

Post by QuadBow »

Hamburger wrote:I use it all the time together with capacity warning on serial display and it just works as expected.
Dunno for the gui though.
I do confirm, for me it works as expected, as well.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

thanks for confirming.
I wished for people to read the wiki instructions now and then - at least when they experience problems with stuff that has been around for a long time.
Different configuration instructions for (v2.3 or newer) and (v2.2 or older)

ram435766@gmail.com‬
Posts: 1
Joined: Sun Mar 01, 2015 2:50 pm

Re: pre 2.4 version r1729

Post by ram435766@gmail.com‬ »

it would be great if the support for NRF24L01 , it has already been done , but if it is integrated into the new version that would make it easier and cheaper to build a custom rc

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: pre 2.4 version r1729

Post by haydent »

Hi guys, if its not too late id like to get my frsky s.port code added that takes advantage of the new MSP #130 cells variable. I remember being told not to add any new files to mw, so which area would be best for it ?

One of the newer neat features i added was 'host mode' so you dont even need a frsky rx, and can simply hook one of the frsky oled cell monitors directly to the fc via inverter and collect its cell data.

I will start preparing a patch against shared ?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: pre 2.4 version r1729

Post by Alexinparis »

haydent wrote:Hi guys, if its not too late id like to get my frsky s.port code added that takes advantage of the new MSP #130 cells variable. I remember being told not to add any new files to mw, so which area would be best for it ?

One of the newer neat features i added was 'host mode' so you dont even need a frsky rx, and can simply hook one of the frsky oled cell monitors directly to the fc via inverter and collect its cell data.

I will start preparing a patch against shared ?


Hi,
I'm afraid it's too late for 2.4 ;)
I think it seems currently stable enough to be released this week.
I think the best place to integrate this sort of feature is in Protocol.cpp, like other telemetry stuff.

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: pre 2.4 version r1729

Post by haydent »

ok thanks for the reply, i had the feeling it would be too late, but will be just happy to get it in there.

Solarwater
Posts: 9
Joined: Wed Mar 04, 2015 2:40 am
Location: Detroit metro

Re: pre 2.4 version r1729

Post by Solarwater »

I believe I found a bug in the Nav code. I was flying my quad, and had gps hold and baro enabled. I wanted to bring it down, so I flipped off baro mode. Problem was it was not coming down. It was descending slowly as if baro was still enabled. Turning off gps hold allowed me to control throttle again as normal.

To test, I made another flight with ez-gui. In fact, the baro mode was not disabling when I switched baro off. It would only turn off if I also turned off all gps modes.

I took a look at the code, and found the f.GPS_BARO_MODE is being set true when using mission, land, or rth. The only time the baro takeover is disabled is when gps mode is fully off or when disarmed. I had inadvertently crossed through RTH mode due to my switch layout, but it looks like this would occur anytime you use mission/land/rth, and then go back to gps hold with baro mode off.

All I did was add the line "f.GPS_BARO_MODE = false;" to the gps hold section to correct the issue.

Code: Select all

else if (rcOptions[BOXGPSHOLD]) {                             //Position hold has priority over mission execution  //But has less priority than RTH
              if (f.GPS_mode == GPS_MODE_NAV)
                NAV_paused_at = mission_step.number;
              f.GPS_mode = GPS_MODE_HOLD;
             f.GPS_BARO_MODE = false;
              GPS_set_next_wp(&GPS_coord[LAT], &GPS_coord[LON],&GPS_coord[LAT], & GPS_coord[LON]); //hold at the current position
              set_new_altitude(alt.EstAlt);                                //and current altitude
              NAV_state = NAV_STATE_HOLD_INFINIT;
            }


I have been flying with this change for a while now, and everything seems OK. Is there anything I missed, that might be affected by this change?

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

Do you think it is a good idea to have GPS hold active when landing the quadcopter?

Case in point: Your quad is just about to touch the ground and GPS PH makes a correction and the landing skids get caught. Worse case is the quad could flip over :(

Solarwater
Posts: 9
Joined: Wed Mar 04, 2015 2:40 am
Location: Detroit metro

Re: pre 2.4 version r1729

Post by Solarwater »

Leo wrote:Do you think it is a good idea to have GPS hold active when landing the quadcopter?

Case in point: Your quad is just about to touch the ground and GPS PH makes a correction and the landing skids get caught. Worse case is the quad could flip over :(



I don't typically land with GPS hold enabled, and that wasn't what I was doing when I discovered this bug (I know I wasn't clear).

When I found the issue, I flew the quad over a patch of land with no trees, enabled position hold, and then ascended to a height (100m for example), then engaged baro hold. I do some filming of the area at that height, then I want to come down. I flip off baro, leaving gps hold on to maintain 2d position, and it is coming down so slowly, that I cant even see it changing height, to the point I don't think it is responding at all. If I toggle gpshold off and then back on, baro mode "unlocks".

When I turn off baro (or any mode really), I want it off.

User avatar
Leon11t
Posts: 38
Joined: Thu Sep 27, 2012 12:24 pm

Re: pre 2.4 version r1729

Post by Leon11t »

Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

TheBum
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: pre 2.4 version r1729

Post by TheBum »

Leon11t wrote:Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

You have to get an understanding of Arduino programming to really understand how the routines in MultiWii get run. Once you understand that, then the code is much more straightforward.

The two main items are the setup() and loop() functions. setup() is called by the Arduino runtime at initialization time. loop() is called periodically by the Arduino runtime after initialization.

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: pre 2.4 version r1729

Post by Leo »

Solarwater wrote:I don't typically land with GPS hold enabled, and that wasn't what I was doing when I discovered this bug (I know I wasn't clear).

When I found the issue, I flew the quad over a patch of land with no trees, enabled position hold, and then ascended to a height (100m for example), then engaged baro hold. I do some filming of the area at that height, then I want to come down. I flip off baro, leaving gps hold on to maintain 2d position, and it is coming down so slowly, that I cant even see it changing height, to the point I don't think it is responding at all. If I toggle gpshold off and then back on, baro mode "unlocks".

When I turn off baro (or any mode really), I want it off.


That is a valid situation. I also agree that is how it should happen. I'm sure Alex will take a look at it and make the necessary changes in the latest build.

User avatar
Leon11t
Posts: 38
Joined: Thu Sep 27, 2012 12:24 pm

Re: pre 2.4 version r1729

Post by Leon11t »

TheBum wrote:
Leon11t wrote:Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

You have to get an understanding of Arduino programming to really understand how the routines in MultiWii get run. Once you understand that, then the code is much more straightforward.

The two main items are the setup() and loop() functions. setup() is called by the Arduino runtime at initialization time. loop() is called periodically by the Arduino runtime after initialization.


For example, I need write variable to EEPROM - where do I need to create this variable?
After plugging a power, I need to reed this variable (this variable its something like a flag)
How can I do this?

TheBum
Posts: 35
Joined: Wed Dec 03, 2014 9:53 pm

Re: pre 2.4 version r1729

Post by TheBum »

Leon11t wrote:
TheBum wrote:
Leon11t wrote:Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

You have to get an understanding of Arduino programming to really understand how the routines in MultiWii get run. Once you understand that, then the code is much more straightforward.

The two main items are the setup() and loop() functions. setup() is called by the Arduino runtime at initialization time. loop() is called periodically by the Arduino runtime after initialization.


For example, I need write variable to EEPROM - where do I need to create this variable?
After plugging a power, I need to reed this variable (this variable its something like a flag)
How can I do this?


If you want it to be able to have a different value for each configuration profile, you'd add it to the conf_t struct. If you want the same value across all configuration profiles, you'd add it to the global_conf_t struct. You can probably take it from there to figure out what code needs to be added.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

we got a problem - please hold v2.4

Post by Hamburger »

wrong - old - thread ; moved to r1739 thread viewtopic.php?f=8&t=6061&p=62034#p62034
- - - -
I think we got a problem with VBAT code.
analogRead() maps the range of [0 ; 5] Volts input to values of [0 ; 1023].
But with our current code (simplified) :

Code: Select all

      uint16_t v = analogRead(V_BATPIN);
        analog.vbat = (v*16) / conf.vbatscale; // result is Vbatt in 0.1V steps

the scaling divisor conf.vbatscale is an uint8_t, so in the range of [0 ; 255].

In effect, for a single cell we want to measure up to 4.2V, which becomes v=860 with analogRead() - at least in theory for a perfect 5V driven board.
We want analog.vbat to be 42 ( <=> 4.2Volts), so which value of conf.vbatscale could do that?
Simple math yields conf.vbatscale = v*16/analog.vbat or in our case conf.vbatscale = 860 * 16 / 42 = 327.
But 327 is beyond what uint8_t can represent!

This has not shown up in the past because single cell systems are not widespread and for batteries with more cells the divisors were chosen to reach the working range. To make it worse, in my tests with various boards driven from ESC-BECs I have seen variations of the theoretical 5V supply which result in another distortion of the analogRead() range which in some cases makes things even worse.

I see the following options:
a) lower the multiplier from 16 to 8 - this will force everyone to retune conf.vbatscale to about half of original value - also loose one bit of precision for tuning
b) make the multiplier a tunable define with preset 16 - no change for most users; the unlucky users can alter the preset to 8 and be happy
c) rewrite the VBAT code, possibly turn vbatscale into a linear factor instead of a divisor (this has irritated some users in the past);
d) make vbatscale 16 bit [0 ; 64k]

With being so close to release I vote for option b)
Opinions, comments?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: pre 2.4 version r1729

Post by Hamburger »

please consider this thrread closed - do not post here

Post Reply