Airplane mode RTH

[PatrikE]

RTH really saved my day!...

Flew FPV and managed to knock my groundstation over....
Lost image in a second.
Ripped the googles of but couldn't locate the plane...

Flipped RHT-switch and the plane came cruising from a totally different direction than i thought it would come from.

All i can say i would never have found the plane without it...

Now i have to resolder my cloverleaf antenna!

[crashlander]

That would be second reported case of plane RTH saving the day!

Regards
Andrej

[Vertigo]

I have read most of this thread, and first of all, big thank you to PatrikE

I will be trying this on a (yet to buy) flying wing, and a multiwii Pro + MTK GPS that Im re-purposing from my quad.

Am I right in understanding that the barometer is not used for RTH ? Or will it automatically use the baro instead of GPS altitude if there is one defined?
Also someone asked about implementing OSD, but it didnt get a response. I have a minimOSD, will this still work ?

[rbirdie001]

I have read most of this thread, and first of all, big thank you to PatrikE

I will be trying this on a (yet to buy) flying wing, and a multiwii Pro + MTK GPS that Im re-purposing from my quad.

Am I right in understanding that the barometer is not used for RTH ? Or will it automatically use the baro instead of GPS altitude if there is one defined?
Also someone asked about implementing OSD, but it didnt get a response. I have a minimOSD, will this still work ?

Hi!
bigger experst are here but at least what I know:
I think only GPS height is used, not from baro. Be careful - MTK chipset have very long lag in height measurement - can be problematic for navigation. Ublox seems better for me. Minim OSD can be used but of course then you need free serial port for it (so no Promini GPS). It's tested by crashlander.
Regards
Roman

[surf_akinys]

Thanks, Patrick, I like servos config in GUI.
Finaly PWM servos works with CRIUS AIO (all servos ok, but throttle still on D3)
If wheater allows, weekend will be field testing days

clue: after #define USE_THROTTLESERVO throttle goes to D8

[surf_akinys]

I have read most of this thread, and first of all, big thank you to PatrikE

I will be trying this on a (yet to buy) flying wing, and a multiwii Pro + MTK GPS that Im re-purposing from my quad.

Am I right in understanding that the barometer is not used for RTH ? Or will it automatically use the baro instead of GPS altitude if there is one defined?
Also someone asked about implementing OSD, but it didnt get a response. I have a minimOSD, will this still work ?

If you want to use baro, change in FW_NAV() this:

GPS_AltErr = GPS_altitude - GPS_hold[ALT];

to this:

GPS_AltErr = (alt.EstAlt - 100*(GPS_hold[ALT]-GPS_home[ALT]))/100;

[crashlander]

If you want to use baro, change in FW_NAV() this:
...
GPS_AltErr = (alt.EstAlt - 100*(GPS_hold[ALT]-GPS_home[ALT]))/100;

Have you tested this?
Using (simple, one hole) baro on fast flying plane can be problematic due to pressure change from speed change....
..that is why real airplanes have more complex air "wiring" to measure air speed, altitude and altitude change (vario).
but like Roman said using UBLOX GPS is more than enough for this kind of application.

Regards
Andrej

[surf_akinys]

If you want to use baro, change in FW_NAV() this:
...
GPS_AltErr = (alt.EstAlt - 100*(GPS_hold[ALT]-GPS_home[ALT]))/100;

Have you tested this?
Using (simple, one hole) baro on fast flying plane can be problematic due to pressure change from speed change....
..that is why real airplanes have more complex air "wiring" to measure air speed, altitude and altitude change (vario).
but like Roman said using UBLOX GPS is more than enough for this kind of application.

Regards
Andrej

If you look at the code, you will find that alt.EstAlt is averaged value.
Also I must point, that flight controller in planes sits in cockpit, so, speed changes do not affect baro readings so mutch.
I have a tested on my 2m 26cc Cub with CRIUS AIO v2 board - works well.

[crashlander]

If you look at the code, you will find that alt.EstAlt is averaged value.
Also I must point, that flight controller in planes sits in cockpit, so, speed changes do not affect baro readings so mutch.

On planes static pressure is taken through holes on left and right side of the plane body, perpendicular to flight direction/air flow.
Otherwise you will get more or less speed (attack angle, or rudder) influenced data (averaged or not).
But it is nice to hear that it works as such.
Is in your opinion resolution much better/useful for plane than simple GPS alt.?

Regards
Andrej

BTW: in this video you can observe reported Alt. (measured with GPS) vs. real (perceived).
http://www.youtube.com/watch?v=UT9ijBGmggc

[surf_akinys]

On planes static pressure is taken through holes on left and right side of the plane body, perpendicular to flight direction/air flow.
Otherwise you will get more or less speed (attack angle, or rudder) influenced data (averaged or not).
But it is nice to hear that it works as such.
Is in your opinion resolution much better/useful for plane than simple GPS alt.?

Regards
Andrej

BTW: in this video you can observe reported Alt. (measured with GPS) vs. real (perceived).
http://youtu.be/dftO3jZv4cw

"Video was removed by user "
I took PatrikE last code and changed so many things. I am trying to make wp navigation, pos hold.
Some nights I drive with my CUB in the back of the van to see, how it works. Its obsession
What related to baro readings - I think baro is usefull for low altitudes, especially for failsafe.
With the baro it is possible to detect wery low altitude, stop navigation and turn motor off.
After all debugging was done I will try to log baro and gps alt values to see differences.

[rbirdie001]

Hi surf_akinys!
Nice to see another "obsessed"
Generally great idea to work out new functions - can be always usefull but for emergency save and return the plane is current code more than good enough. If you have enough landing place at home position, it's sufficient to stop the engine while keep navigating and plane nicely lands itself - I tested it many times. Exact height is much more important for multicopters - if you cut throttle due to height measurement inacuracy in 5m instead of 0m at the plane, it's no problem but at multicopter it's worse (unless you are just above a haystack )
I wouldn't be afraid of baro errors due to airflow around (my planes are slow and fuselage has many holes to all directions) but for planes I use very small and simple Crius lite boards which have only MPU6050 chip so BARO nor MAG isn't available. Additionally you can get easily over 328 CPU program memory and RAM if you activate too many sensors. But for sure - let's play and let's see!
Roman
BTW: Originally linked Andrej's video http://www.youtube.com/watch?v=UT9ijBGmggc plays OK and "removed video" you reported is a different one. It looks like "too many opened windows" problem
R.

[surf_akinys]

Hi, Roman,

In Andreys video I see altitude value lag for 1-2s. Trees are about 20m, power lines also.

So, today was third water day (my CUB with floats) and I am happy to share my fork with some new NAV functions: GPS_HOLD and GPS_NAV.

In GPS_HOLD mode plane tries to keep fixed altitude and flies to fixed point continously. Fixing occurs when entering in GPS_HOLD mode.

In GPS_NAV mode plane flies from wp[1] to wp[3] coordinates and tries to keep wp_alt[i] altitude. After last wp plane flies to wp[0], in this wp are stored home pos and alt.
If navigation lasts more than MAX_NAV_MIN minutes, plane goes to wp[0] imediatelly.
If to swith from GPS_NAV mode to GPS_HOLD mode, nav pauses, but counter for MAX_NAV_MIN still works and after switching back to GPS_HOLD counter value is compared to MAX_NAV_MIN.

All nav modes (GPS_HOME, GPS_HOLD, GPS_NAV) modes now works only with HORIZON and ANGLE modes.
All nav modes have options:
NAV_BARO - averaged barometer value for altitude control. If option off, GPS altitude used.
NAV_MAG - navigation by compass and GPS_ground_curse. If option off, navigation only by GPS ground curse.

Until now no NAV PID's - for field testing I set scallers for ALT, THRO, ROLL and YAW like this:
//conf.pid[PIDALT].P8/10.0; ALTCORR scaller
//conf.pid[PIDNAVR].P8/10.0; SCALER_THROTTLE
//conf.pid[PIDNAVR].I8/10.0; ROLL scaller
//conf.pid[PIDNAVR].D8/10.0; YAW scaller
So, it was possible to adjust scallers by BT link, not by uploading new firmware.

If not PASSTHRU mode, all RC inputs in nav modes are muted.

If baro alt les than SAFE_ALT_TO_NAV, nav stops and plane must land with IDLE_THROTTLE. (this is not safe, but because I affraid that if I set MINCOMAND, my CUB gas engine stops and there will be no chances to recover from this situation)

In all naw functions, when they are activated and in GPS_NAV, when eatch wp was reached, plane tries to climb with CLIMB_TROTTLE to programmed altitude + ALT_OVERSHOOT. This can be very useable to gliders and also for nav debugging - it is signal that wp was "taken".

If someone wan to try, download for my fork: https://docs.google.com/file/d/0B2QJcuD ... sp=sharing

P.S. GPS waypoints now are hardcoded in firmware, so, for every new mission you need to recompile fw. Maybe later, when winter comes, and all debugging was done, maybe will be time to program some GUI for wp setting and mission planning.

Akinys.

[surf_akinys]

If you want to use baro, change in FW_NAV() this:
...
GPS_AltErr = (alt.EstAlt - 100*(GPS_hold[ALT]-GPS_home[ALT]))/100;

Have you tested this?
Using (simple, one hole) baro on fast flying plane can be problematic due to pressure change from speed change....
..that is why real airplanes have more complex air "wiring" to measure air speed, altitude and altitude change (vario).
but like Roman said using UBLOX GPS is more than enough for this kind of application.

Regards
Andrej

Yes, today I finally managed to work GPS_HOLD and GPS_NAV.

I tested baro alt mode vs gps alt mode while in GPS_HOLD and did not observed any big differences, but baro mode keeps altitude better (with the same scallers).
Also I tested navigation by only gps and compass, again - no big differences, but in mag mode turns are better (with the same scallers).

Also I observed stange wobble: when plane passed GPS_HOLD coordinates, and get out of GPS_WP_radius[i], plane starts wobbling for 3-5 times and only after some more wobbles turns and goes back to GPS_HOLD coordinates.
Because was no wind, I take presumption that in the point after wp_distance > GPS_WP_radius[i] navigation error was 181 (or -181) - plane flies by wire from hold point.
When banking and yaw was applied, diff jumps from 181 to -181 (or from -181 to 180) and starts wobbling. So, after that conclusion add code, that when abs(navDIFF) > 175 then allways turn left (men mind). After that wobbles dissapeared.

Akinys

Akinys

[crashlander]

BTW: Originally linked Andrej's video http://www.youtube.com/watch?v=UT9ijBGmggc plays OK and...

Sorry for that I edited my video and corresponding post couple of times and Akinys got one (no longer valid) snapshot ...

@Akinys: PatrikE discussed one of those point-to-point navigational options with me in the spring, but than abandoned/postponed the idea due to EOSBandi's promise/post that he will implement that in mainline MWII.

Regards
Andrej

[surf_akinys]

@Akinys: PatrikE discussed one of those point-to-point navigational options with me in the spring, but than abandoned/postponed the idea due to EOSBandi's promise/post that he will implement that in mainline MWII.

Regards
Andrej

I read about this in forum but I was so impatient

[PatrikE]

Hi,

My idé was almost the same.
A hardcoded triangle.
But it uses HomePosition as reference and should fly a triangle with 111 meter Baseline.

+10000 gives a base of ~111 meters.

Code: Select all

void nextWP(uint8_t x){
#define BASELINE 10000
  if(x=0){ // WP0  East of homePos
    GPS_hold[LAT] = GPS_home[LAT];
    GPS_hold[LON] = GPS_home[LON]+BASELINE; }  

  else if(x=1){ // WP1   NorthEast of homePos
    GPS_hold[LAT] = GPS_home[LAT]+BASELINE;  
    GPS_hold[LON] = GPS_home[LON];}

  else{ // WP2 HomePos
    GPS_hold[LAT] = GPS_home[LAT];
    GPS_hold[LON] = GPS_home[LON];}
  }

It's a little more flexible than hardcoded positions.
Just change BASELINE length to suit your needs.
Could be changed to be Gui configurable to.

Cheers
Patrik

[surf_akinys]

I think that wp nav should be configurable from some GUI app, that uses google maps (like APM mission planner).

In my code change 1d arrays:

int32_t GPS_WP_LAT[GPS_WP_number];
int32_t GPS_WP_LON[GPS_WP_number];
int16_t GPS_WP_ALT[GPS_WP_number];
uint8_t GPS_WP_radius[GPS_WP_number];

to one 2d array:
#define GPS_WP_number 10
int32_t WP_NAV[GPS_WP_number][4];

only recently i found, that in Arduino it is possible to use 2d array - this happens.
( Z80 asm programmer (20 years before), that last 10 years programs foxpro and sql and never coded in C++, started coding Arduino...)

in function GPS_reset_home_position(void) i fill all values of this array with home coordinates, altitude +conf.pid[PIDALT].D8 and waypoint radius.

from some hypotetic GUI will be possible set values for waypoints filling array by serial protocol.
unconfigured waypoints holds home values, so, in FW_NAV() this can be easily detectable and go home (or start again, or rollback) can be implemented.

this version I will test tomorow - last still and sunny day in my town.

Akinys

[surf_akinys]

version, tested today with 2D wp array:
https://docs.google.com/file/d/0B2QJcuD ... sp=sharing

Akinys

[rbirdie001]

..
Also I observed stange wobble: when plane passed GPS_HOLD coordinates, and get out of GPS_WP_radius[i], plane starts wobbling for 3-5 times and only after some more wobbles turns and goes back to GPS_HOLD coordinates.
Because was no wind, I take presumption that in the point after wp_distance > GPS_WP_radius[i] navigation error was 181 (or -181) - plane flies by wire from hold point.
When banking and yaw was applied, diff jumps from 181 to -181 (or from -181 to 180) and starts wobbling. So, after that conclusion add code, that when abs(navDIFF) > 175 then allways turn left (men mind). After that wobbles dissapeared.
..
Akinys

Hi!
I'm really too weak in programming to understand new ideas in previous posts but I was interested by idea that strange wobling when the plane is passing by home position can be removed by nav error filtering if it's close to 180 deg. I tried to write this line but I see big risk that I made something wrong. I'm really not a coder. What do you think? I also don't know if "left" should be +175 or -175.

Code: Select all

// Wrap Heading 180
      if (dif <= - 180) dif += 360; 
      if (dif >= + 180) dif -= 360;
      if (abs(dif) >175) dif = 175;      //new turn always left (?)

For long time I'm successfully using this line:

Code: Select all

  if (GPS_distanceToHome <=15) dif=0;  //new fly straight over home
// Wrap Heading 180

It helps little but wobbling is still there.
I finally managed to do all adjustments and edits I in the latest PID FW_NAV version and I hope to test it this weekend...
Regards
Roman

[surf_akinys]

+175 is left, -175 is right. You can try set smaller angle, for example 170 or 165. This is safe and you can try it in GPS_HOME mode.

[surf_akinys]

I took a look at serial protocol and found that almost all for filling wp array are already here.
If 15 waypoints are enough, than serial.cpp code for MSP_SET_WP can look like that and there is only the need for GUI (like eziosoft android app):

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)
       uint16_t radius = read16();              // future: to set heading (deg)
       read16();                       // future: to set time to stay (ms)
       read8();                        // future: to set nav flag
       if (wp_no == 0) 
       {
         GPS_home[LAT] = lat;
         GPS_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) AltHold = alt;  // temporary implementation to test feature with apps
       } 
       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
             GPS_hold[LAT] = lat;
             GPS_hold[LON] = lon;
             if (alt != 0) AltHold = alt;  // temporary implementation to test feature with apps
             #if !defined(I2C_GPS)
               nav_mode      = NAV_MODE_WP;
               GPS_set_next_wp(&GPS_hold[LAT],&GPS_hold[LON]);
             #endif
           }
           else // wp1-wp15
           {
             WP_NAV[wp_no][LAT] = lat;
             WP_NAV[wp_no][LON] = lon;
             WP_NAV[wp_no][ALT] = alt;
             WP_NAV[wp_no][RADIUS] = radius;
           }
       }

[dieterke]

Hello Guys

I use this Version MultiWii/Airplane/NAV_PID and it works very nice. At the beginning i had anny lidl problems but they are fixed now. Its a very good work from you.
But some questions i have.
If I switch to RTH the plane go's down. Thats for me a Problem, because we have many trees there. I live in switzerland.
Is in this version Autolanding in ? If yes where I can switch off?

Sorry my bad english

Dieter

[PatrikE]

When the plane is within 100 meter from home it will descend to reach the set RTH Alt
Use GUI PID ALT D To set RTH Alt. It's only set to 24 meters as default atm.
Set 50 to 100 meters instead.

Almost last in Gps.h

Code: Select all

#define FAILSAFE_RTH true   // Enable RTH for failsafe incl Auto DisARM at home

Change to false
Otherwise the plan will cut throttle and autoland after it reached home.

/Patrk

[surf_akinys]

for emergency save and return the plane is current code more than good enough. If you have enough landing place at home position, it's sufficient to stop the engine while keep navigating and plane nicely lands itself - I tested it many times.

Roman
R.

Failsafe must be not only function to return plane to home. Failsafe also must mind "what if something goes wrong" - stalled or broken servo, too strong wind, preventing plane go home, programming errors, unwanted motor start on the ground, etc.
Altitude check to stop nav functions can be handy.

[dieterke]

When the plane is within 100 meter from home it will descend to reach the set RTH Alt
Use GUI PID ALT D To set RTH Alt. It's only set to 24 meters as default atm.
Set 50 to 100 meters instead.

Almost last in Gps.h

Code: Select all

#define FAILSAFE_RTH true   // Enable RTH for failsafe incl Auto DisARM at home

Change to false
Otherwise the plan will cut throttle and autoland after it reached home.

/Patrk

Hi Patrik

Thank you for your help, i will test it.

Dieter

[dieterke]

Use GUI PID ALT D To set RTH Alt. It's only set to 24 meters as default atm.
Set 50 to 100 meters instead.

Almost last in Gps.h

Code: Select all

#define FAILSAFE_RTH true   // Enable RTH for failsafe incl Auto DisARM at home

Change to false
Otherwise the plan will cut throttle and autoland after it reached home.

/Patrk

Sorry but how I Change in the gui the green windows. I try the gui with W7 and XP but i can't Change the numbers in the green windows. Servo-offset works well.

Dieter

[PatrikE]

The numberboxes works like sliders.
Use the mouse and pull to change the numbers.

[PatrikE]

@surf_akinys

The current failsafe is the same as for Multis.
It just detect lost or out of range radio signals.

If the plane is still intact and weather permits it.
The plan can land by it self within <50 meters from where it was launched.

#define FAILSAFE_OFF_DELAY 200 can be a issue if the plane have a long way home.( 200 = 20 seconds)
Maybe it should be a separatd failsafe handling wor FixedWings.

If the features you mentioned should work there should be a separate Failsafe controller to monitor any faults in the main controller.

/Patrik

[rbirdie001]

Failsafe must be not only function to return plane to home. Failsafe also must mind "what if something goes wrong" - stalled or broken servo, too strong wind, preventing plane go home, programming errors, unwanted motor start on the ground, etc.
Altitude check to stop nav functions can be handy.

Hi surf_akinys,
I have to repeat myself "every function which someone write and test is great and can be useful" .
I really don't want to be like guy, who in 19th century recomended to close patent bureau "because everything which is possible have already been invented"
Just I'm afraid that too complex code can cause many problems because always there can be situation which you haven't expected and also resources of CPU 328 aren't unlimited.
Because most of the planes can fortunately glide, seems this RTH with "simple gliding autolanding" good enough to save the plane if control is lost, but of course if you want to make real drone flying alone over waypoints, you should think about more situations. (We shouldn't forget also the law which in most countries forbides flying out of visual range ! )
I'm quite agreed even with "failsafe delay" constant because if everyone sets reasonable time according his flying range, it's another "hardware" safety measure preventing total flyaway in case e.g. lost home position... (your plane won't flyaway 20km but only 1km which is 20 times better )
OK, enough of joking: Every idea is wellcome!
Last PID version with all anti wobbling mods is loaded in my wing and I'm waiting for the weather (and for my wife to allow me going to fly )
Regards
Roman

[crashlander]

Hello Guys
If I switch to RTH the plane go's down. Thats for me a Problem, because we have many trees there. I live in switzerland.
Is in this version Autolanding in...

The other solution is to decrease "home zone" area from 100 to eg. 50, 30...m. In code around line 1524 in GPS.cpp

Code: Select all

// Navigation while Altitude is higher than RTH Alt
        if (f.GPS_HOME_MODE && !f.CLIMBOUT_FW && GPS_AltErr <=0 ){        // While we are higher than RTH alt.
          if (GPS_distanceToHome >50){ GPS_angle[PITCH]=0 ;}             // RTH Nav Stage Use only ACC to maintain altitude
         

Rationale behind this is that you can rarely estimate safe altitude for RTH in advanced but most of the time you automatically fly on safe/comfortable altitude and when you enable RTH the plane will maintain that altitude (unless it is less than preset safe one) until it will reach very close to home (and 100m is IMO not close enough).

@PatrikE: You omitted level wings "autolaunch" from later releases, but I still think it is useful for heavier/clumsier wings. Maybe reintroduce it but decoupled from basic RTH level wings eg.

Code: Select all

 rcData[THROTTLE]= CLIMBTHROTTLE;                    // Max Allowed Throttle
        if(curr_Gps_Alt <20) dif=0; // Forced Climbout with Level Wings for "AutoLaunch"
        #if RTH_BAILOUT
           dif=0; // Forced Climbout with Level Wings
        #endif 

Regards
Andrej

[rbirdie001]

Hi!
finally tested new FW NAV PID version in the air and improvement of the navigation is just GREAT! Also servo trimming from GUI is for me big help.
No more snake flight but very smooth and straight navigation towards home. Simply big improvement
I noticed only one problem of ACC mode generally: I'm unable to adjust correctly PITCH stabilization from ACC to make plane flying approx. in level or rather little pitch up. I calibrated ACC some ~10 degrees nose up (I even tested to calibrate it extremely nose up - I guess about +30 degrees but no change). When I let it fly alone in ACC, it's always gaining speed and is flying more nose down than I'd like to. When I apply high throttle, it starts descend even faster.
My flying wing is balanced little "heavy nose" compensated by elevons trimed up so if I add throttle in PASSTHRU and GYRO, it start immediately climbing, but in ACC is all the time going down. If I activate ACC in my hand and tilt the plane nose UP or DOWN, elevons are reacting in correct direction. I think it was similar in previous version too, but now it seems even worse.
I'll keep trying to find why, I'm used for the situation that something which works for everyone else doesn't work for me. I'm "natural beta tester"
Any ideas wellcome!
See you!
Roman

Edit: First findings about this: On my plane there is error behavior of LEVEL I term in HORIZON mode.
First (but logical) problem for the planes is that if THROTTLE is OFF, LEVEL I term register is continually reseted (because for the copter it mean it's on the ground). But plane can glide . I think that this reset should by bypassed for all kind of planes because even in gliding we need active I term. If no throttle in ACC mode and plane is significantly tilted in PITCH axis, servos are shaking but not adding control throw from I accumulation.
Additionally it seems to me that LEVEL I term (at my setup!) have wrong direction: If I tilt me plane in PITCH axis in ACC mode, servos reacts immediately in right direction (so P reaction is OK) but if I have set high value to LEVEL I term (I tested e.g. 0.150) and give little throttle (just to "open" I term control) servos start giving more and more correction (caused by I accumulating of PITCH error) but in ROLL direction!
There seems to be something wrong with HORIZON mode I term but with my programming knowledge I'm not sure if I can find it.
I'll try but any help will be wellcome. I guess there can be some bug in HORIZON PID calculation.
Regards
Roman

[crashlander]

I noticed only one problem of ACC mode generally: I'm unable to adjust correctly PITCH stabilization from ACC to make plane flying approx. in level or rather little pitch up. I calibrated ACC some ~10 degrees nose up (I even tested to calibrate it extremely nose up - I guess about +30 degrees but no change).

I was noticing same behavior from the beginning of RTH testing, but it is not always visible/observable (not on every setup equally). In the begging I believed it was wrong gyro scaling, but after it was fixed (and problem still remained) vibrations was next suspect....
Originali I flayed completely untrimmed wing but after fine tuning it in PASSTHRU mode that problem almost disappeared and that probably even more confirms your observations that there is an issue with horizon/level mode.

Regards
Andrej

[mariusmelc]

Hello Guys

I download the version PatrikE MultiWii_dev_2013_07_15_r1539 with NAV_PID.
I add :
need to setup servo directions here; no need to swap servos amongst channels at rx */
#define PITCH_DIRECTION_L -0.5 // left servo - pitch orientation
#define PITCH_DIRECTION_R 0.5 // right servo - pitch orientation (opposite sign to PITCH_DIRECTION_L, if servos are mounted in mirrored orientation)
#define ROLL_DIRECTION_L -0.5 // left servo - roll orientation
#define ROLL_DIRECTION_R -0.5 // right servo - roll orientation (same sign as ROLL_DIRECTION_L, if servos are mounted in mirrored orientation)
After test, I can't revese roll direction on my Flying Wing/mega/ppm. "#define ROLL_DIRECTION_L -0.5" or "#define ROLL_DIRECTION_L 0.5" don't have any effect


Samone can help me ?

Thanks

Sorry for my ennglish

[PatrikE]

Hi..

In this ver i have modified the flyingwing Mix.
It's the same file but just updated.
NAV_PID.rar

In output.cpp you can find this

Code: Select all

   #define ROLLRATE 0.5
   #define PITCHRATE 0.5

I have set it to 0,5 as default so you should be able to just upload it.

Cheers
Patrik

[mariusmelc]

Thanks PatrikE

[rbirdie001]

Hello Guys

I download the version PatrikE MultiWii_dev_2013_07_15_r1539 with NAV_PID.
I add :
need to setup servo directions here; no need to swap servos amongst channels at rx */
#define PITCH_DIRECTION_L -0.5 // left servo - pitch orientation
#define PITCH_DIRECTION_R 0.5 // right servo - pitch orientation (opposite sign to PITCH_DIRECTION_L, if servos are mounted in mirrored orientation)
#define ROLL_DIRECTION_L -0.5 // left servo - roll orientation
#define ROLL_DIRECTION_R -0.5 // right servo - roll orientation (same sign as ROLL_DIRECTION_L, if servos are mounted in mirrored orientation)
After test, I can't revese roll direction on my Flying Wing/mega/ppm. "#define ROLL_DIRECTION_L -0.5" or "#define ROLL_DIRECTION_L 0.5" don't have any effect


Samone can help me ?

Thanks

Sorry for my ennglish

Hi!
servo orientation changes were moved to GUI so these lines probably won't work anymore. Compile without it and then connect with GUI program from last dev. (currently r1555) Choose "servo" tab on the top, there "servo" and "go live" buttons. You can choose there inversion for every axis and servo and also trim servos. Result you will see immediately on the plane, then don't forget to save it.
I hope this will help.
Roman

[mariusmelc]

A BIG Thanks

I test that tomorrow in fpv

[mariusmelc]

And about mode setings ...
This is ok ?
No others mode for Airplane/FlayngWing ?

THANKS

[rbirdie001]

Hi!
I continued in discovering what is wrong with HORIZON mode I term and found that the strange behavior I found at airplane dev. version is present also in stock 2.2 tricopter configuration so it seems to be hidden software bug.
Here is short description:
Tricopter is lying on the ground and tail is supported by a brick so ROLL axis is levelled and PITCH axis is tilted to front.
In acro mode all motors are running equally because no movement so no gyro corrections.
For the first test I adjusted just P and D term for the LEVEL, I term was 0. When I activated (at 0:07) HORIZON, front motors speeded up and rear motor slowed down because P term tries to compensate tilt on PITCH but both front motors are still have the same speed (because ROLL is levelled). That's OK.
Then I adjusted I term constant to 0.069 which is more than default but still reasonable value and again activated HORIZON mode (0:28 and again 0:42).
You can see that motors first did the same as before but very fast right motor starts speed up more than left one so it looks like that I correction from PITCH is added to ROLL.
Look here and hear "narrator" http://www.youtube.com/watch?v=z2rAY_X_u3w
I didn't test all other combinations but it looks that there is something wrong in the code. Because I'm not experienced in code, I hope that someone from programmers can look at it and possibly correct it.
Guys, I'm writing it here first (to our small, friendly group ) to look at my observations and confirm me if I'm right before I'll post it to the Software developement forum and they would laugh at me if I'd be wrong .
Thanks!
Roman

[rbirdie001]

And about mode setings ...
This is ok ?
No others mode for Airplane/FlayngWing ?

THANKS

You can try also HORIZON mode, could be better.
Roman

[mariusmelc]

Thanks

[mariusmelc]

What is the effect of different mode on the Plane/FLYING_WING

ANGLE = PITCH stabilisation ?
HORIZON = ROLL stabilization ?
BARO = ALT stabilisation ?
MAG = ?
HEADFREE = ?
HEADADJ = ?
GPSHOME = Retour Home + Fly around a home point ?
GPSHOLD = Fly around a gps point ?

List of the combinated mode ? efect ?
Ex : ANGLE + HORIZON + BARO = ? ( work ?)

Another Thanks

[rbirdie001]

What is the effect of different mode on the Plane/FLYING_WING

ANGLE = PITCH stabilisation ?
HORIZON = ROLL stabilization ?
Angle and horizon are similar - both stabilizing PITCH+ROLL to horizontal level. The only difference is that angle is active always but horizon supress levelling when you give strong stick input so control is more natural. Angle stabilizes so much, that any control is difficult.
BARO = ALT stabilisation ? Yes for multicopter, not for plane except current dev. versions - see few pages back.
MAG = ? Stabilizes yaw using compass. Used in multicopter, don't know if works for plane.
HEADFREE = ? N/A for plane.
HEADADJ = ? N/A for plane.
GPSHOME = Retour Home + Fly around a home point ? Yes
GPSHOLD = Fly around a gps point ? Yes

List of the combinated mode ? efect ?
Ex : ANGLE + HORIZON + BARO = ? ( work ?) No, see above.

Another Thanks

Hope This will help
Roman

[rbirdie001]

Hi,
sorry but on my flying wing altitude control in last RTH PID version doesn't work.
With older version 130322 when plane returned home, it remained circling in safe height and was keeping the same height until I switched RTH off or batery was discharged. Navigation wasn't so nice as is now , but height control worked...
Last PID RTH version from 22.8. climbs up when RTH is activated lower than is safe height, but when plane reaches home, it is circling lower and lower until I have to disable RTH when the plane is almost touching ground, to avoid hard landing under throttle.
Safe height I have set to 45m in GUI, in GPS.h I have this value:

Code: Select all

#define GPS_ALTCORR    3   // P for Elevator.

(in previous version it was 2)
I don't know what other setting can I have set wrong. For you other (Patrik, Andrej...) it works fine?
Thanks for any ideas!
Thanks!
Roman

[PatrikE]

Hi Roman,

I think FAILSAFE_RTH is enabled in latest dev.
It makes the plane Autoland at home

Code: Select all

#define FAILSAFE_RTH    true  // Enable RTH for failsafe incl Auto DisARM at home for autoland

/Patrik

[rbirdie001]

Hi Roman,

I think FAILSAFE_RTH is enabled in latest dev.
It makes the plane Autoland at home

Code: Select all

#define FAILSAFE_RTH    true  // Enable RTH for failsafe incl Auto DisARM at home for autoland

/Patrik

Hi Patrik,
thanks for ideas, I'll gradually test them but I don't think FAILSAFE_RTH is right hint. I activated RTH by a switch and not by failsafe situation so it should be another case when the plane ends at position hold @ safe height and not autoland. Additionally the motor is still running and trying to climb the plane higher but the elevator doesn't go up so plane is just flying fast but keep descending.
Roman

[surf_akinys]

Roman, make shure that after enabling RTH plane is in angle or horizon mode. I noticed this behaviour also and found that GPS code do not check this.
Also I found that FW_NAV is hard to read and rewrote it compleatly. Thats how fork started.

[PatrikE]

@Roman

ELEVATORCOMPENSATION can be to low.
If it's to low the plane will lose altitude in banking turns.
If it's to high the plane will pitch up in turns.

Try to increase it.
Its just a percentage of compensation on elevator of rollangle.
Should be safe to increase to the double.

GPS_angle[axis] is only used if AccModes is activated in the Mwii PID calculation.

/Patrik

[crashlander]

@rbirdie001
If you enable

Code: Select all

#define FAILSAFE_RTH    true 

the plane will go into failsafe motor off when home point is reached (no mater how RTH is enabled).
I had to increase ELEVATORCOMPENSATION to 130 to get proper behavior.

@all
Today I flew latest Patrik's code (after fine tuning trimming and motor trust angle in pass-thru mode) it worked perfectly.
I did some auto-launches (my code addition). I also enabled RTH some 400m away 20m high and flying away, it returned home perfectly.

@PatrikE
Make that move into _shared and get more testers....

Regards
Andrej

[crashlander]

Hi!
I continued in discovering what is wrong with HORIZON mode I term and found that the strange behavior I found at airplane dev. version is present also in stock 2.2 tricopter configuration so it seems to be hidden software bug....

When using LEVEL/HORIZON mode MWII uses also accel. measures and those are very sensitive to vibrations (much more than gyro) so when you upped I term for level and doing your test on the ground the I term "saturated" PID loop (due to perceived tilting from vibrations).

Regards
Andrej