Altitude Hold/Advanced Failsafe solutions by NHA

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Odp: Altitude Hold/Advanced Failsafe solutions by NHA

Post by ezio »

Eric wrote:Ok, I added setting home/hold from serial support for I2C gps.

https://github.com/Smartype/MultiWii/co ... 85497f22f6

Great !
Maybe this can be added to shared? (If it works)
I assume that you can't use WP16 to set position hold position?
So maybe will be better to use WP15 instead of WP1 to avoid problems in the future?

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Odp: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

ezio wrote:Great !
Maybe this can be added to shared? (If it works)
I assume that you can't use WP16 to set position hold position?
So maybe will be better to use WP15 instead of WP1 to avoid problems in the future?


Hi, I'll add to my code soon.
BTW, using WP16 is still not logical for me!!! It limitates the WP numbers...
If you check my latest code you can see I'm using a struct to store WPs:

Code: Select all

  static struct {
      int32_t Lat;               // Lat for WP
      int32_t Lon;               // Lon for WP
      int32_t Alt;               // alt at WP (cm)
      int16_t Heading;           // heading at WP (deg)
      uint8_t Vario;             // vario for alt changing (cm/s)   - maximum 250
      uint8_t Time;              // time to stay in WP (s)   - maximum 250
      uint8_t Updated;           // WP is updated or not or not?
              // 0 - current WP is not yet updated
              // 1 - current WP is already updated
  } WP[WP_NUMBER];


So now I'm only using 2 WPs. But can be extended to any numbers in the future!!!
In this way, even if you send WP16 by MSP, I write the values to WP1. (WP0 is the home position)

Code: Select all

  /*** GPS WP datas***/
  // suggested naw flags:
  #define HOME 0
  #define HOLD 1
       // 2-WP_NUMBER - generic WP navigation  */


Code: Select all

case MSP_SET_WP:
     {
       int32_t lat = 0,lon = 0,alt = 0;
       uint8_t wp_no = read8();        //get the wp number
       lat = read32();
       lon = read32();
       alt = read32();                 // to set altitude (cm)
       read16();                       // future: to set heading (deg)
       read16();                       // future: to set time to stay (ms)
       read8();                        // future: to set nav flag
       if (wp_no == 0) {
         WP[HOME].Lat = lat;
         WP[HOME].Lon = lon;
         f.GPS_HOME_MODE = 0;          // with this flag, GPS_set_next_wp will be called in the next loop -- OK with SERIAL GPS / OK with I2C GPS
         f.GPS_FIX_HOME  = 1;
         if (alt != 0)
             WP[HOME].Alt = alt;           // temporary implementation to test feature with apps
             WP[HOME].Vario = RTH_VARIO;   // vario can be inserted here instead of predefined
             WP[HOME].Updated = 1;         // HOME WP is updated
       } else if (wp_no == 16) {       // OK with SERIAL GPS  --  NOK for I2C GPS / needs more code dev in order to inject GPS coord inside I2C GPS
         WP[HOLD].Lat = lat;
         WP[HOLD].Lon = lon;
         if (alt != 0)
             WP[HOLD].Alt   = alt;         // temporary implementation to test feature with apps
             WP[HOLD].Vario = WP_VARIO;    // vario can be inserted here instead of predefined
             WP[HOLD].Updated = 1;         // HOLD WP is updated
         #if !defined(I2C_GPS)
           nav_mode      = NAV_MODE_WP;
           GPS_set_next_wp(&WP[HOLD].Lat,&WP[HOLD].Lon);
         #endif
       }
     }
     headSerialReply(0);
     break;


I suggest strongly to use WP1 instead of WP16 in the MSP in the future...

BR
Adrian

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

I do not know why we use a wp 16 here.
In the i2c gps nav code, set next wp to 16 means hold the current position.
In you code about serial gps msp_set_wp, it means go to lat/lon and hold there.
I do not know what is the standard/expected behavior. In my opinion, wp from 0 - 15 are all generic wp, we can set any of them via serial msp.
Can anybody explain?

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Multiwii r1371 NHA r21

Post by nhadrian »

Hi,

I attached my r21 code based on official r1371 Multiwii release.

Changes:
- optflow function prepared
- struct for failsafe variables
- stored WP number can be defined to any value
- I2C HOME/HOLD upload via MSP (not flight tested!)
- minor BUGfix in MSP caused WP16 not always set
- minor cleaning in code

I included the solution to I2C_GPS by Eric. Please NOTE that this function is not flight-tested because I don't have I2C_GPS.
So if anybody tries with I2C_GPS, please be really careful, and also please share the experiences!!! (Many thanks in behalf of Eric too)

And, as always, TRY IT ON YOUR OWN RISK!!! ;)

BR
Adrian
Attachments
Multiwii_r1371_NHA_r21.zip
(167.08 KiB) Downloaded 307 times

scanman
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by scanman »

thanks this code is fantastic .
please can you move
#define FAILSAFE_DETECT_TRESHOLD

into config.h in your codebase instead of in RX because i change this for my frysky every time

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

scanman wrote:thanks this code is fantastic .
please can you move
#define FAILSAFE_DETECT_TRESHOLD

into config.h in your codebase instead of in RX because i change this for my frysky every time


Hi, I moved into config.h, good catch!
I'll include in my next release.

BR
Adrian

scanman
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by scanman »

im getting compile errors when including any of the #FAILSAFE includes, or the lcd includes.
i fixed the failsafe one by uncomenting:


//#ifdef LOG_VALUES
&lcd_param_text39, &failsafeEvents, &__L,
&lcd_param_text40, &i2c_errors_count, &__L,
&lcd_param_text41, &annex650_overrun_count, &__L
//#endif
};


with the lcd im getting this error:
LCD:1188: error: 'failsafeEvents' was not declared in this scope

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Multiwii r1371 NHA r22

Post by nhadrian »

scanman wrote:im getting compile errors when including any of the #FAILSAFE includes, or the lcd includes.
i fixed the failsafe one by uncomenting:


//#ifdef LOG_VALUES
&lcd_param_text39, &failsafeEvents, &__L,
&lcd_param_text40, &i2c_errors_count, &__L,
&lcd_param_text41, &annex650_overrun_count, &__L
//#endif
};


with the lcd im getting this error:
LCD:1188: error: 'failsafeEvents' was not declared in this scope


Hi,

there was a bug related to LCD and LOG VALUES. (I don't use either of them so there was no reference)
I attached the r22, fixed the BUG.

BR
Adrian

ps: As always, TRY IT ON YOUR OWN RISK!!! ;)
Attachments
Multiwii_r1371_NHA_r22.zip
(167.08 KiB) Downloaded 408 times

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi All,

from now on, the latest revision will be linked into the first comment to see clear what is the last.

BR
Adrian

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

nhadrian wrote:Hi All,

from now on, the latest revision will be linked into the first comment to see clear what is the last.

BR
Adrian


Hi Adrian,

I have a suggestion, we the quad lost rc signal, can we make it to poshold for a fews seconds, and then start rth?
In my case, iPhone is used as the transmitter, when I switch to map view to send way point, the rc signal thread will be suspended for one or two seconds. as the UI thread on iPhone has the highest priority. when the loading animation is finished, the rc thread resumed. So when the iphone is running the map loading animation, I hope the quad is able to poshold itself and wait for the rc signal to be back.

yes, I can change the failsafe_delay to 2/3 seconds to achieve this, but it is dangerous when I lost my rc signal when the quad is moving with a high speed.

by the way, this is the default failsafe behaviour of DJI naza.

Code: Select all

static struct
{
    int16_t events;
    uint8_t active;   // Failsafe mode status - replace (failsafeCnt > (5*FAILSAFE_DELAY))
#if BARO && defined(FAILSAFE) && (defined(FAILSAFE_ALT_MODE) || defined(FAILSAFE_RTH_MODE))
    uint8_t  altSet;
#if defined(FAILSAFE_RTH_MODE)
    uint8_t  confSet;
    uint8_t  atHome;
    uint32_t atHomeDelay;
#if defined(FAILSAFE_RTH_START_DELAY)
    uint32_t startDelay;
#endif
#endif
#endif
} failsafe;


Code: Select all

/*
    When FAILSAFE_RTH_START_DELAY defined: 0 -> 2 -> 3 -> 1
    Else: 0 -> 1
*/
#if defined(FAILSAFE) && defined(FAILSAFE_RTH_MODE) && BARO     // set the proper f.modes for RTH function
        if (failsafe.active)                              // after specified guard time after RC signal is lost (in 0.1sec)
        {
            if (f.ARMED)
            {
                if (f.GPS_FIX && GPS_numSat >= 5)                                //check if GPS is ready for RTH
                {
                    switch (failsafe.confSet)                                        //first save the states and prepare to give control to RTH!
                    {
// poshold
#if defined(FAILSAFE_RTH_START_DELAY)
                    case 0:
                        failsafe.confSet = 2;
                        if (f.GPS_HOME_MODE || !f.GPS_HOLD_MODE)                                      //check if already in RTH or HOLD?
                        {
                            f.GPS_HOME_MODE = 0;
                            f.GPS_HOLD_MODE = 1;
#if defined(AUTOLAND) && defined(RTH_ALT_MODE)
                            f.AUTOLAND_MODE = 0;
#endif
                            GPSNavReset = 0;
#if defined(I2C_GPS)
                            GPS_I2C_command(I2C_GPS_COMMAND_POSHOLD, 0);       //waypoint zero
                            nav_mode = NAV_MODE_POSHOLD;
#else // SERIAL
                            WP[HOLD].Lat = GPS_coord[LAT];
                            WP[HOLD].Lon = GPS_coord[LON];
                            GPS_set_next_wp(&WP[HOLD].Lat, &WP[HOLD].Lon);
                            nav_mode = NAV_MODE_POSHOLD;
#endif
                        }

#if defined(FAILSAFE_RTH_DELAY)
                        failsafe.atHome = 0;
#endif
                        resetAltHold();           //to be sure that parameters are set to default even if already was in BARO_MODE
                        break;
#endif // defined(FAILSAFE_RTH_START_DELAY)

// go to home
#if defined(FAILSAFE_RTH_START_DELAY)
                    case 3:
#else
                    case 0:
#endif // defined(FAILSAFE_RTH_START_DELAY)
                        failsafe.confSet = 1;
                        if (!f.GPS_HOME_MODE || f.GPS_HOLD_MODE)                                      //check if already in RTH or HOLD?
                        {
                            f.GPS_HOME_MODE = 1;
                            f.GPS_HOLD_MODE = 0;
#if defined(AUTOLAND) && defined(RTH_ALT_MODE)
                            f.AUTOLAND_MODE = 0;
#endif
                            GPSNavReset = 0;
#if defined(I2C_GPS)
                            GPS_I2C_command(I2C_GPS_COMMAND_START_NAV, 0);       //waypoint zero
                            nav_mode    = NAV_MODE_WP;
#else // SERIAL
                            GPS_set_next_wp(&WP[HOME].Lat, &WP[HOME].Lon);
                            nav_mode    = NAV_MODE_WP;
#endif
                        }

#if defined(FAILSAFE_RTH_DELAY)
                        failsafe.atHome = 0;
#endif
                        resetAltHold();           //to be sure that parameters are set to default even if already was in BARO_MODE
                        break;

                    case 1:
                        f.GPS_HOME_MODE   = 1;
                        f.GPS_HOLD_MODE   = 0;
#if defined(AUTOLAND) && defined(RTH_ALT_MODE)
                        f.AUTOLAND_MODE = 0;
#endif
                        break;

#if defined(FAILSAFE_RTH_START_DELAY)
                    case 2:
                        f.GPS_HOME_MODE   = 0;
                        f.GPS_HOLD_MODE   = 1;
#if defined(AUTOLAND) && defined(RTH_ALT_MODE)
                        f.AUTOLAND_MODE = 0;
#endif
                        /*
                            1. this will not be executed when no gps fix
                            2. remove it to save power, let's update it when AltVarioChanged changed
                        */
                        /*
                        if (failsafe.startDelay > FAILSAFE_RTH_START_DELAY * 1000000)
                            failsafe.confSet = 3;
                        */
                        break;
#endif // defined(FAILSAFE_RTH_START_DELAY)
                    }
                }
            }
        }
#endif


Code: Select all

#if defined(FAILSAFE_RTH_MODE) && defined(FAILSAFE) && defined(FAILSAFE_RTH_DELAY)
    if (failsafe.atHome)
    {
        failsafe.atHomeDelay += cycleTime;
    }
#if defined(FAILSAFE_RTH_START_DELAY)
    if (failsafe.confSet == 2) {
        failsafe.startDelay += cycleTime;
    }
#endif
#endif


Code: Select all

#if defined(FAILSAFE) && (defined(FAILSAFE_ALT_MODE) || defined(FAILSAFE_RTH_MODE))             //failsafe altitude handling codes 
    if (failsafe.active)
    {
        if (!AltVarioChanged)               //Allcalculations runs on 25 Hz
        {
#if defined(FAILSAFE_RTH_MODE)
            if (f.GPS_HOME_MODE
#if defined(FAILSAFE_RTH_DELAY)
                    && (failsafe.atHomeDelay < (FAILSAFE_RTH_DELAY * 1000000))           //check if hovering at home position for less time than FAILSAFE_RTH_DELAY - if more, will land in failsafe alt mode
#endif
               )          //check if GPS is ready for RTH
            {
                switch (nav_mode)
                {
                case NAV_MODE_POSHOLD:
                    altToTarget(FAILSAFE_RTH_HOME, FAILSAFE_RTH_VARIO, alt_target_mode_failsafe_home_altitude);
                    break;
                case NAV_MODE_WP:
                    altToTarget(FAILSAFE_RTH_ALT, FAILSAFE_RTH_VARIO, alt_target_mode_failsafe_rth_altitude);
                    break;
                }
            }
            else
            {
                #if defined(FAILSAFE_RTH_START_DELAY)
                if (failsafe.confSet == 2)
                {
                    altHoldCode();

                    if (failsafe.startDelay > FAILSAFE_RTH_START_DELAY * 1000000)
                        failsafe.confSet = 3;
                }
                else
                    altToFailsafe();
                #else // defined(FAILSAFE_RTH_START_DELAY)
                altToFailsafe();
                #endif // defined(FAILSAFE_RTH_START_DELAY)
            }
#else
            altToFailsafe();
#endif
        }

        // calc'd based on rcData
        rcCommand[THROTTLE] += BaroPID;
    }
#endif
#endif

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

Reset when failsafe is inactive.

Code: Select all


#if (defined(FAILSAFE_RTH_MODE) || defined(FAILSAFE_ALT_MODE)) && BARO
        else if (failsafe.altSet
#if defined(FAILSAFE_RTH_MODE)
                 || failsafe.confSet
#endif //defined(FAILSAFE_RTH_MODE)
                )
        {
            failsafe.altSet = 0;
#if defined(FAILSAFE_RTH_MODE)
            failsafe.confSet = 0;
            failsafe.atHomeDelay = 0;
#if defined(FAILSAFE_RTH_START_DELAY)
            failsafe.startDelay = 0;
#endif
            failsafe.atHome      = 0;
#endif //defined(FAILSAFE_RTH_MODE)
            resetAltHold();
            failsafe_rcdata_throttle  = 0;
        }
#endif //(defined(FAILSAFE_RTH_MODE) || defined(FAILSAFE_ALT_MODE)) && BARO


felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Hi,

I did some tests on Sunday and liked the features! Nice work! One thing that bugs me though is the time limit before engine cut. This is something we can calculate instead of having a fixed time. If we take the distance to home position and approximate altitude as well as nav rate and descent rate, we should be able to work out the time taken to reach home and then time to descend with a fair level of accuracy. I'm new to Arduino so won't be submitting any code snippets yet, but would like to see a calculated time to RTH and time to auto-land + detection that descent has ceased and automatically cut the motors - as a more elegant solution to FAILSAFE_OFF_DELAY.

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi,

I'll think on both ideas, thanks!

BR
Adrian

Goetz
Posts: 82
Joined: Sun Mar 04, 2012 3:40 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Goetz »

good idea to have an link to latest code in first post. would be nice to link to latest Gui (WIN/Linux) too.

Thank you very mutch

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Multiwii r1379 NHA r22

Post by nhadrian »

Hi,

I merged my code with the latest r1379.
Nothing new functions but contains the improvements of Hamburger in analog readings.

So now vbat, psensor and rssi can be used at the same time without jittering or other inaccuracy mesurements.

BR
Adrian
Attachments
Multiwii_r1379_NHA_r22.zip
(167.75 KiB) Downloaded 334 times

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Thanks! Loading it up now to test it out.. r22 worked great, RTH, AutoLand, etc all tested out fine under dev1371, no changes expected under dev1379 but will report back.

EDIT/Update: Okay, tested PH, RTH and Failsafe with vario. Works great! Two minor things: 1) it looked like it was RTH whilst rising to the target altitude, ie. it didn't rise to target altitude and then navigate to home, but RTH and rise to target altitude at the same time. 2) Also, I note that it doesn't seem to PH well during rise or fall, sometimes drifting up to 10m during a descent before reaching a target altitude and then moving back into position, I'm not sure whether this is a problem with GPS location developing error over a range of altitudes or something in vario causing PH to disable. I didn't confirm whether I have this same issue on the default dev1379 codebase.

Really love your work NHA!

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Hi Adrian,

I've finally got a SRF08 sonar and was wondering whether you would look at integrating Sonar into your altitude/vario control/calculations? I see there are a few implementations floating around but it doesn't look like anything made it into 2.2 despite several sensor fusion solutions in forked code. Correct me if I'm wrong but can't see anything in your r22 code nor in _Shared tree.

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

The moving in PH during rising/descending is a natural behaviour since the GPS PIDs are tuned for hoveing.
Since it is not serious issue I didn't try to solve this.

There is not any sonar code in 2.2, only sonar altitude is printed into debug but nothing more.
Once I'll get a sonar I'll try to implement some fusion.
But my goal would be not to fusion the altitude reading but correct the ground level altitude under the copter.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Yeah, I've been doing some reading on sensor fusion, looks like some people much smarter than me have already looked at this problem, fusing GPS + Sonar + Barometer with a transition threshold and doing some advanced kalman / complimentary filtering with two cases, one for below 6m (or whatever the upper bound of accuracy is for sonar eg 6m for SRF08) where Sonar + GPS data may be integrated (interestingly he discards Baro due to "land disturbances") a second case where sonar is discarded above 6m and Baro + GPS are fused. The paper may be downloaded here: "An Adaptive Altitude Information Fusion Method for Autonomous Landing Processes of Small Unmanned Aerial Rotorcraft, X Lei, J Li - Sensors, 2012 - mdpi.com" http://www.mdpi.com/1424-8220/12/10/13212/pdf . My brain hurts!

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

I'll test latest NHA release today and make a full featured video.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Today i crashed two times inthe same way: all engines stopped foa a momment in gps ph with baro. I was using MWC NHA R22 on Crius Aiop.
The motors stopped ALL with a squiky sound. First time they stopped when i pressed "Write to eeprom " in EZ GUI at PID config regarding GPS PH angle of corection P. Crash from 3 m altitude.
Second time when i engaged RTH motors stopped for about one second and started again but too late and crashed with landing gear on the ground.
Also i observed that GPS pos hold wonders around quite long distances. It has no precision at all.
I recommand CAUTION regarding R22

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

dramida wrote:Today i crashed two times inthe same way: all engines stopped foa a momment in gps ph with baro. I was using MWC NHA R22 on Crius Aiop.
The motors stopped ALL with a squiky sound. First time they stopped when i pressed "Write to eeprom " in EZ GUI at PID config regarding GPS PH angle of corection P. Crash from 3 m altitude.
Second time when i engaged RTH motors stopped for about one second and started again but too late and crashed with landing gear on the ground.
Also i observed that GPS pos hold wonders around quite long distances. It has no precision at all.
I recommand CAUTION regarding R22


hi,

sad to hear that.
Regarding to crashes:
1) about first crash, I read somewhere in the forum that it is quite dangerous to update PID and write EEPROM during flight, I not recommend at all!!! I'm always updating PIDs when copter is on the ground and disarmed.
2) about second crash. It is quite interresting, since if you are right, you had a disarm/arm within a second in the air. I'll double check if this can be happened via any of my modifications!
May I ask you if you were in altitude hold when engaged the RTH for the second time or not???

regarding to GPS precision, my modifications are only related to altitude handling and updating WP-s. None of GPS PID regulation part are touched!!! So I'm sure that the precision problem is not related to my code.
The problem is that even in official releases, the GPS PID part wasn't touched for a long time. I can't immagine what caused the precision problem.

***UPDATE: Could you please double check if you didn't have ARMED checkbox checked for the same channel as RTH?***

BR
Adrian

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

I always Tweak PID's in gps ph, even i your previous releases.
Second crash was with baro activated also.
I can confirm that arm box was unchecked. One more observation:All the motors screamed and stalled when crash ocured.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by copterrichie »

dramida wrote:I always Tweak PID's in gps ph, even i your previous releases.
Second crash was with baro activated also.
I can confirm that arm box was unchecked. One more observation:All the motors screamed and stalled when crash ocured.


A flight data recorder would prove its value in situations like this, especially running developmental code.

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

dramida wrote:I always Tweak PID's in gps ph, even i your previous releases.
Second crash was with baro activated also.
I can confirm that arm box was unchecked. One more observation:All the motors screamed and stalled when crash ocured.


Could you describe this? I can't really understand what screamed means in this way...
Probably do you have a video?

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Sorry to hear of your troubles Dramida.

I've done a few PH PID tweaks whilst airborne via bluetooth dongle but thankfully didn't experience any system failure like you've described. I did notice that the engines would briefly spike but nothing major and ultimately settle very quickly (<1sec) after the remote PID update. I've only ever done PH or Nav PID changes whilst in the air, typically I would land for anything else.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Regarding crash with NHA22, software works but seems the standard FW for ESC's are not responding OK to spikes. I had exactly the same behaviour in MWC dev R1391.
MWC NHA R22 IS WORKING FINE

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

dramida wrote:Regarding crash with NHA22, software works but seems the standard FW for ESC's are not responding OK to spikes. I had exactly the same behaviour in MWC dev R1391.
MWC NHA R22 IS WORKING FINE


Hi Dramida,

thanks for your feedback.
I had 4 10min long flights, continously testing RTH and PH with EZ-GUI WP update, and worked just fine.
I'm using simonK firmwared ESCs (6A turnigy, with Atmel).

BR
Adrian

ps.: today once I raised to 100m, it was quite scarry with such a small bird. And then, I pulled throttle stick back fully, and with vario mode I descended slowly to 20m, without any major wobbles or instability!!!
I'm really happy and proud right now... :D:D:D
Here is a small video:
http://www.youtube.com/watch?v=j1viA9P_F-k

franko_
Posts: 15
Joined: Tue Apr 16, 2013 7:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by franko_ »

Hi Adrian,

where´s your latest code, or is it not public at the moment?

BR
Frank

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

franko_ wrote:Hi Adrian,

where´s your latest code, or is it not public at the moment?

BR
Frank


Az I said perviously in my post, always check the first post!
The latest link will be there all time!

BR
Adrian

franko_
Posts: 15
Joined: Tue Apr 16, 2013 7:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by franko_ »

Sorry for spam, okay latest release 1379.

BR
Frank

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Tazzy »

Hello thanks adrian I love this forkoff but now i need some support and pid tips ;)
I have changed my motors and props and need change my pids.
After the hardware change it fly as a jojo and jumps up and down with nha latest and default pids, with multiwii 2,2 with default pids all works ok and it is stable and also the barro and poshold is ok.
What pid need i modify to adjust jumping behavior?
I have a crius aio pro v1.

Regards Tazzy

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Tazzy wrote:Hello thanks adrian I love this forkoff but now i need some support and pid tips ;)
I have changed my motors and props and need change my pids.
After the hardware change it fly as a jojo and jumps up and down with nha latest and default pids, with multiwii 2,2 with default pids all works ok and it is stable and also the barro and poshold is ok.
What pid need i modify to adjust jumping behavior?
I have a crius aio pro v1.

Regards Tazzy


It should fly with the same PIDs are used for 2.2! At least hover, because in hovering (0 vario) the regulation is the same as in 2.2!
Did you balanced your props? Vibration can cause such a problem.

BR
Adrian

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Tazzy »

Hello Adrian thanks for the reply

Props and motors are balanced, i will give it one more try and erase the arduino first, i don't remember if i did that before i flashed it.
I will tell how it goes ;)

// Tazzy

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Hi Adrian,

I notice when I try and enable RTH_ALT_MODE but with AUTOLAND undefined, Arduino throws an error:

Code: Select all

MultiWii.cpp.o: In function `loop':
/Applications/MultiWii.ino:1777: undefined reference to `altToAutoland()'


I don't want AUTOLAND feature enabled (to save memory), but would like to have a custom RTH approach height, shouldn't they be independent?

Cheers

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

felixrising wrote:Hi Adrian,

I notice when I try and enable RTH_ALT_MODE but with AUTOLAND undefined, Arduino throws an error:

Code: Select all

MultiWii.cpp.o: In function `loop':
/Applications/MultiWii.ino:1777: undefined reference to `altToAutoland()'


I don't want AUTOLAND feature enabled (to save memory), but would like to have a custom RTH approach height, shouldn't they be independent?

Cheers


Hi,

Good catch!
I'll upload r23 in the evening, to correct this BUG.

BR
Adrian

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Tazzy »

Hello Adrian
I have problem again to compile r22 with pilotlamp, buzzer, without vbat
I link to the config.h http://pastebin.com/REGL5ggJ

// Tazzy

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Multiwii r1411 NHA r23

Post by nhadrian »

Hi,

there was a BUG caused compile error when AUTOLAND was commented.
I corrected it. Tazzy, I checked and compiles with your config.h!
So, in r23 there is not any major changes in functions, only compile BUG correction.

So I attached my r23 code, based on official Multiwii r1411.
For changes in r1411, please check the multiwii repository:
http://code.google.com/p/multiwii/

And, as always, TRY IT ON YOUR OWN RISK!!! ;)

BR
Adrian
Attachments
Multiwii_r1411_NHA_r23.zip
(169.77 KiB) Downloaded 1225 times

Goetz
Posts: 82
Joined: Sun Mar 04, 2012 3:40 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Goetz »

could anybody please explain how to get the right gui for this version.

thank you

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Goetz wrote:could anybody please explain how to get the right gui for this version.

thank you


Hi, you can use the gui in _shared.
You will need Processing to make app.
But I think the GUI for MWI2.2 would also work.

BR
Adrian

ps.: link to shared:
http://code.google.com/p/multiwii/sourc ... onf_shared

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Hi Adrian,

I haven't had a chance to check out the updated version yet. I should have some time on Sunday.

In the meantime, I've just been thinking about the Advanced Headfree mode which made it into _shared. Nice work on that! There have been some requests around a virtual fence mode, which would be similar to activating RTH when reaching the advanced headfree range, but with altitude fencing as well, by placing a upper and lower altitude boundary which would likewise activate RTH_ALT_MODE or Baro/Vario to climb back to the altitude threshold or something like that. Another perhaps more simple feature would be activating LEVEL and BARO/Vario Altitude hold when progressing below a altitude threshold when in Horizon or Acro mode to assist people when learning flips etc... Just thinking out loud here :)

Cheers and as always, love your work!

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Hi I think there is something related to MAG_DECLINATION broken under 1411, it was fixed in 1414 it seems. Would this be an issue for r23?

nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

felixrising wrote:Hi I think there is something related to MAG_DECLINATION broken under 1411, it was fixed in 1414 it seems. Would this be an issue for r23?


Hi,

yes, it can be an issue, I'll merge with latest soon and upload.

BR
Adrian

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Tazzy »

Thanks Adrian
I have fixed some with the hardware on my quad and now it works like a charm ;)
The barro code rocks also in windy weather ..... I love it and now i need to tweak the std pids little.

http://www.youtube.com/watch?v=2_ujrNIAu60

Thanks and Regards Tazzy

jamesbit
Posts: 5
Joined: Fri Feb 08, 2013 5:06 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jamesbit »

Hallo !!!

Please can someone upload the last stable version ?

Thank you.

Jamesbit.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Hi James,

r23 is on the first post....

There haven't been many changes to the _shared tree for a while, the only noteworthy ones are the gyro scale factor changes which can be rolled in manually pretty easily.

jamesbit
Posts: 5
Joined: Fri Feb 08, 2013 5:06 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jamesbit »

Hi felixrising !

Do you mean Multiwii_r1411_NHA_r23 ?

I read that it has problem with Mag Declination.

I'm searching at least for r1414.

Anyway thank you.

Jamesbit.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Yeah, but not a big issue, you can also take a look at the declination related changes:
mag_declination changes:
https://code.google.com/p/multiwii/source/detail?r=1414 (only the eeprom.ino file change)
https://code.google.com/p/multiwii/source/detail?r=1416 (doesn't really matter, you can change it if you want)
and gyro scale changes:
https://code.google.com/p/multiwii/source/detail?r=1428 (ignore the eeprom.ino change)

EDIT: if you have a L3G4200D gyro, then you might want to wait on the changes to finalise or just review the pending changes from this thread here viewtopic.php?f=8&t=3520

jamesbit
Posts: 5
Joined: Fri Feb 08, 2013 5:06 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jamesbit »

No, I have another type of gyro so I will use the r1414 with eeprom.ino and multiwii.ino changes only.

Thank you.

Regards,

Jamesbit.

felixrising
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by felixrising »

Each gyro has a different scale factor, before those changes, they were all the same - more or less... which was incorrect leading to interesting level flight mode characteristics (it would tilt) after loops etc.

Post Reply