RTH min height on 2.3 *without* GPS NAV version

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
rubadub
Posts: 154
Joined: Mon Apr 28, 2014 2:36 am

RTH min height on 2.3 *without* GPS NAV version

Post by rubadub »

I have a quad that I'd like to setup with the "RTH minimum height" feature (i.e., have it do GPS HOLD & climb to RTH height before trying to initiate RTH). I realize that EOSBandi's GPS NAV version already has this feature. Unfortunately, I ran into some weird issues when using his code (my quad would go into NAV mode, get stuck, and I couldn't get it out). So, I'm going back to the regular 2.3 version, and I'd like to add this feature to the regular code. I'm just looking for something that's simple & works, without all of the sophisticated navigation engine stuff in EOSBandi's version. I remember seeing mention of this on another thread, but I can't seem to find it now.

Anyway, I came up with my own quick hack for temporarily enabling GPS HOLD & climbing to the RTH height before actually RTH'ing.
I was hoping I could get another set of eyes on it in case I might have missed something.
Here goes:

in config.h, add a new define in the GPS section

Code: Select all

#define RTH_MIN_HEIGHT 500 //in cm


in Multiwii.cpp, within the GPS mode processing routines
line ~1040+

Code: Select all

   #if GPS
   
   #if defined (RTH_MIN_HEIGHT)
   static uint8_t rth_height_holding=0;   
   #endif

   static uint8_t GPSNavReset = 1;
      if (f.GPS_FIX && GPS_numSat >= 5 ) {
        if (rcOptions[BOXGPSHOME]) {  // if both GPS_HOME & GPS_HOLD are checked => GPS_HOME is the priority
          if (!f.GPS_HOME_MODE)  {
          
   #if defined (RTH_MIN_HEIGHT)
          if(alt.EstAlt<RTH_MIN_HEIGHT){
            if(!rth_height_holding){
               rth_height_holding=1;
               AltHold=RTH_MIN_HEIGHT;
               f.GPS_HOLD_MODE = 1;
               GPSNavReset = 0;
               #if defined(I2C_GPS)
               GPS_I2C_command(I2C_GPS_COMMAND_POSHOLD,0);
               #else
               GPS_hold[LAT] = GPS_coord[LAT];
               GPS_hold[LON] = GPS_coord[LON];
               GPS_set_next_wp(&GPS_hold[LAT],&GPS_hold[LON]);
               nav_mode = NAV_MODE_POSHOLD;
               #endif
            }
          }else{
             rth_height_holding=0;
   #endif
         f.GPS_HOME_MODE = 1;
            f.GPS_HOLD_MODE = 0;
            GPSNavReset = 0;
            #if defined(I2C_GPS)
              GPS_I2C_command(I2C_GPS_COMMAND_START_NAV,0);        //waypoint zero
            #else // SERIAL
              GPS_set_next_wp(&GPS_home[LAT],&GPS_home[LON]);
              nav_mode    = NAV_MODE_WP;
            #endif
         #if defined(RTH_MIN_HEIGHT)
          }
         #endif
         
          }
        } else {
         #if defined (RTH_MIN_HEIGHT)
         rth_height_holding=0;
         #endif
         
         f.GPS_HOME_MODE = 0;

          if (rcOptions[BOXGPSHOLD] && abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE) {
            if (!f.GPS_HOLD_MODE) {
              f.GPS_HOLD_MODE = 1;
              GPSNavReset = 0;
              #if defined(I2C_GPS)
                GPS_I2C_command(I2C_GPS_COMMAND_POSHOLD,0);
              #else
                GPS_hold[LAT] = GPS_coord[LAT];
                GPS_hold[LON] = GPS_coord[LON];
                GPS_set_next_wp(&GPS_hold[LAT],&GPS_hold[LON]);
                nav_mode = NAV_MODE_POSHOLD;
              #endif
            }
          } else {
            f.GPS_HOLD_MODE = 0;
            // both boxes are unselected here, nav is reset if not already done
            if (GPSNavReset == 0 ) {
              GPSNavReset = 1;
              GPS_reset_nav();
            }
          }
        }
      } else {
      #if defined (RTH_MIN_HEIGHT)
      rth_height_holding=0;
      #endif
        f.GPS_HOME_MODE = 0;
        f.GPS_HOLD_MODE = 0;
        #if !defined(I2C_GPS)
          nav_mode = NAV_MODE_NONE;
        #endif
      }
    #endif


Basic idea is to test if the current height is below the RTH height when trying to engage GPS HOME mode. If so, then force GPS HOLD mode and set AltHold to the target height RTH_MIN_HEIGHT (this assumes that the user also already enabled BARO mode).

I don't intend to propose this patch for all users or for integration into the mainstream MW code. I'm also not concerned with the sophistication or ugliness of the code at this point. I'd just like to get this working on my own personal setup, so I'd appreciate some feedback in case there's something that I'm missing (i.e., perhaps there's some kind of weird fall-through condition that I don't see, where my code will fail and cause things to get stuck in a certain mode or completely break RTH). thanks in advance.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: RTH min height on 2.3 *without* GPS NAV version

Post by EOSBandi »

My NAV code is integrated to the mainstream multiwii codebase, and apparently working flawless.. Instead of hacking with 2.3 codebase I recommend you to try the latest 2.4RC from the repository.

Simply setting the target altitude in althold mode won't work since the althold code will react violently on large target_altitude changes.

I would rather trying to figure out what was wrong with the NAV code on your copter.

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: RTH min height on 2.3 *without* GPS NAV version

Post by PatrikE »

It would be nice to have RTH as a failsafe option.

rubadub
Posts: 154
Joined: Mon Apr 28, 2014 2:36 am

Re: RTH min height on 2.3 *without* GPS NAV version

Post by rubadub »

EOSBandi wrote:My NAV code is integrated to the mainstream multiwii codebase, and apparently working flawless.. Instead of hacking with 2.3 codebase I recommend you to try the latest 2.4RC from the repository.

Simply setting the target altitude in althold mode won't work since the althold code will react violently on large target_altitude changes.

I would rather trying to figure out what was wrong with the NAV code on your copter.


I actually tried your code because I needed this specific feature on a quad where I would be flying from a hilltop and would descend below my starting altitude when flying down into small dips and valleys. Unfortunately, no, your GPS NAV code isn't working flawlessly. You can take it or leave it, but I'm no longer comfortable running your version.

Your code has an issue where it's getting stuck in autopilot mode, and attempting to switch in&out of the either GPS HOLD or GPS HOME modes via the AUX switches doesn't always work. I have to toggle the switches multiple times in order to force it out of autopilot mode. I have had this happen to me multiple times when failsafing at the edge of range (failsafe settings programmed for ANGLE,BARO,MAG,GPS HOME, and throttle 50%). With the normal 2.3 code, this doesn't happen and RTH works perfectly. And, BTW, I also noticed that your GPS nav code causes violent attitude shifts when engaging the GPS modes, while the normal 2.3 version doesn't; same exact quad, same exact settings, yet yours jars the quad around violently when enabling RTH or HOLD.

I posted about this issue your GPS NAV thread but was simply ignored.

Actually, I've managed to test it, and the climb rate isn't too bad if you don't have an overly-aggressive ALT P-factor and there isn't too much of a difference between the current altitude and the target RTH altitude. I'm only shooting for around 15m height for RTH, so it doesn't rocket up like crazy.

any other *productive* feedback that's not defensive and pompous would be appreciated. In the meantime, I'll continue to test.

BTW, why isn't there an emergency landing mode for BARO-enabled boards that doesn't rely on GPS? I think that might be my next project, even if the MW gods don't approve...

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: RTH min height on 2.3 *without* GPS NAV version

Post by EOSBandi »

rubadub wrote:
EOSBandi wrote:My NAV code is integrated to the mainstream multiwii codebase, and apparently working flawless.. Instead of hacking with 2.3 codebase I recommend you to try the latest 2.4RC from the repository.

Simply setting the target altitude in althold mode won't work since the althold code will react violently on large target_altitude changes.

I would rather trying to figure out what was wrong with the NAV code on your copter.


I actually tried your code because I needed this specific feature on a quad where I would be flying from a hilltop and would descend below my starting altitude when flying down into small dips and valleys. Unfortunately, no, your GPS NAV code isn't working flawlessly. You can take it or leave it, but I'm no longer comfortable running your version.

Your code has an issue where it's getting stuck in autopilot mode, and attempting to switch in&out of the either GPS HOLD or GPS HOME modes via the AUX switches doesn't always work. I have to toggle the switches multiple times in order to force it out of autopilot mode. I have had this happen to me multiple times when failsafing at the edge of range (failsafe settings programmed for ANGLE,BARO,MAG,GPS HOME, and throttle 50%). With the normal 2.3 code, this doesn't happen and RTH works perfectly. And, BTW, I also noticed that your GPS nav code causes violent attitude shifts when engaging the GPS modes, while the normal 2.3 version doesn't; same exact quad, same exact settings, yet yours jars the quad around violently when enabling RTH or HOLD.

I posted about this issue your GPS NAV thread but was simply ignored.

Actually, I've managed to test it, and the climb rate isn't too bad if you don't have an overly-aggressive ALT P-factor and there isn't too much of a difference between the current altitude and the target RTH altitude. I'm only shooting for around 15m height for RTH, so it doesn't rocket up like crazy.

any other *productive* feedback that's not defensive and pompous would be appreciated. In the meantime, I'll continue to test.

BTW, why isn't there an emergency landing mode for BARO-enabled boards that doesn't rely on GPS? I think that might be my next project, even if the MW gods don't approve...


Again.
There is no gps-nav fork. That fork was merged to the main codebase on September, and got a number of improvements and fixes since then. Check 2.4RC and if you still experiences this behavior then it can be investigated.

Btw, if you not comfortable flying "my version" then I have a bad news for you, all GPS related navigation code written mostly by me. Including the HOLD and RTH code in 2.3. And when 2.4 is released the hidden fly-away routines will be activated in 2.3 :D

rubadub
Posts: 154
Joined: Mon Apr 28, 2014 2:36 am

Re: RTH min height on 2.3 *without* GPS NAV version

Post by rubadub »

well, whatever name you'd like to place on it, but I'm referring to any version (whether it be yours or anyone else's) with the advanced navigation engine that cycles through the nav modes within the GPS processing routines in GPS.cpp, vs. the more simplistic mode processing routine in Multiwii.cpp. In all honesty, I like the idea of having a more sophisticated GPS navigation engine, but I was pretty disappointed and disturbed by the unstable performance that I observed. So, in the interest of avoiding crashes, I decided to revert to *your* older, more basic GPS code which is implemented in 2.3. I don't need waypoint navigation or any of the other fancy new features; I just want basic RTH yet with a minimum RTH height.

Again, please understand that I'm not interested in making waves or proposing large experimental changes. I just need some advice on how to hack the 2.3 version to get a more/less decent RTH minimum height working.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: RTH min height on 2.3 *without* GPS NAV version

Post by EOSBandi »

rubadub wrote:well, whatever name you'd like to place on it, but I'm referring to any version (whether it be yours or anyone else's) with the advanced navigation engine that cycles through the nav modes within the GPS processing routines in GPS.cpp, vs. the more simplistic mode processing routine in Multiwii.cpp. In all honesty, I like the idea of having a more sophisticated GPS navigation engine, but I was pretty disappointed and disturbed by the unstable performance that I observed. So, in the interest of avoiding crashes, I decided to revert to *your* older, more basic GPS code which is implemented in 2.3. I don't need waypoint navigation or any of the other fancy new features; I just want basic RTH yet with a minimum RTH height.

Again, please understand that I'm not interested in making waves or proposing large experimental changes. I just need some advice on how to hack the 2.3 version to get a more/less decent RTH minimum height working.


If you willing to take time and help figuring out what caused the unstable performance of the 2.4 code, that will move forward the whole project.
If you hack 2.3 instead to get your required function that good for you, but bring no value to the project.
It is up to you to decide, which way you follow.

Post Reply