Airplane mode RTH

Post Reply
rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: AW: Airplane mode RTH

Post by rbirdie001 »

Kayle wrote:Hi all,
today i tested my Teksumo with a level pid of 5. It doesn´t make a roll of death anymore. But when i switch to ACC the control of the plane realy rough. I must give full elevator that the plane put his nose up. Gyro mode works very well. I only fly in Gyro mode. But ACC mode doesn´t work for me. It´s a shame :-(
Kayle

Hi Kayle,
but then you are done - it's exactly how the ACC mode works also for me - plane flies mostly in level and sticks have just limited influence.
ACC mode is mainly if you want to fly straight (photo, video taking) or as a base for RTH function. You can't expect doing acrobacy in it.
Roman

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Airplane mode RTH

Post by rbirdie001 »

Hi Guys,
finally everything works! :D
I removed elevator filtering and just reduced GPS_ALTCORR from 6 to 2 and everything now works just GREAT!
Today I tested RTH in the wind about 8 m/s and it worked perfect including height control. It was funny to see the plane in such wind as it was hanging above my head, nose pointing against the wind and ground speed was almost zero. When it finally reached home point, it made turn and because it was now flying with the wind, it made very fast circle and again pointed against wind and sloooooowly returned to me. Height control worked also perfectly.
There is (almost ;) ) nothing to improve now but I have one idea:
Multiwii could check ground speed from GPS during RTH and if it's below minimal (e.g. 2 m/s), autopilot should add some throttle to CRUICETHROTTLE to reach at least minimal reasonable speed. It can prevent situation when in the strong wind plane doesn't have enough power to get home within reasonable time as the cruice speed is almost equal to wind speed.
Just idea to think about because now I'm very satisfied with current code and will start implementing it into my FPV plane.
Roman

aydineser
Posts: 8
Joined: Mon Jun 17, 2013 11:54 am

Re: Airplane mode RTH

Post by aydineser »

Hi All,

I am trying to test multiwii airplane code too. I am using a Crius AIOP V2.0 board. I uploaded the firmware,
But I could find pin for second aileron servo (wing 2). Any idea ? connection diagram etc ...

Aydin

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Airplane mode RTH

Post by rbirdie001 »

aydineser wrote:Hi All,

I am trying to test multiwii airplane code too. I am using a Crius AIOP V2.0 board. I uploaded the firmware,
But I could find pin for second aileron servo (wing 2). Any idea ? connection diagram etc ...

Aydin

Hi Aydin,
try to look here: http://fotoflygarn.blogspot.cz/2012/03/ ... -same.html
I hope you can find all necessary there.
Regards
Roman

aydineser
Posts: 8
Joined: Mon Jun 17, 2013 11:54 am

Re: Airplane mode RTH

Post by aydineser »

Hi Roman,
Thank you very much,

I have solved the problem by enabling #define MEGA_HW_PWM_SERVOS
and updating output.ino from latest regular Multiwii code from git.
Then it works now, D3:Thr, D6:Rud, D7:Elv, D11/D12:Ail

Aydin
Last edited by aydineser on Fri Jun 28, 2013 8:21 pm, edited 1 time in total.

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: AW: Airplane mode RTH

Post by crashlander »

rbirdie001 wrote:
Kayle wrote:Hi all,
today i tested my Teksumo with a level pid of 5. It doesn´t make a roll of death anymore. But when i switch to ACC the control of the plane realy rough. I must give full elevator that the plane put his nose up. Gyro mode works very well. I only fly in Gyro mode. But ACC mode doesn´t work for me. It´s a shame :-(
Kayle

Hi Kayle,
but then you are done - it's exactly how the ACC mode works also for me - plane flies mostly in level and sticks have just limited influence.
ACC mode is mainly if you want to fly straight (photo, video taking) or as a base for RTH function. You can't expect doing acrobacy in it.
Roman

I'm using HORIZON mode instead and I'm flying all those videos in it. It is sure no acro but I find it nice to fly in it.

Regards
Andrej

aydineser
Posts: 8
Joined: Mon Jun 17, 2013 11:54 am

Re: Airplane mode RTH

Post by aydineser »

Hi patrik,

Does your RTH code including Crostracking ?

Aydin

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

Re: Airplane mode RTH

Post by PatrikE »

aydineser wrote:Hi patrik,

Does your RTH code including Crostracking ?

Aydin

Nope..
Just stear towards waypoint.

surf_akinys
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

in FW_nav now is:

GPS_AltErr = GPS_altitude - GPS_hold[ALT];

i think this is not correct, must be:

GPS_AltErr = GPS_altitude - GPS_hold[ALT] - GPS_home[ALT];

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

Re: Airplane mode RTH

Post by PatrikE »

Same question explained once here.
http://www.multiwii.com/forum/viewtopic.php?f=7&t=2456&start=220#p36690
Read some posts after this one.

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Airplane mode RTH

Post by rbirdie001 »

Hi all!
Just to wake up this little sleepy thread:
During last month I did many flights using RTH with my flying wing (to be honest I got now quite lazy and when my plane got into some uncomfortable or risky situation, I simply call RTH and plane saves itself and returns ;) ).
This is maybe bad for my skills but definitely good judgement for the RTH code so I'd like to needle Patrik a little - why not to join RTH into main MWC code when it's already a "proven working function" :D ?
Once more thanks to all, namely Patrik for the effort!
Have all nice holidays!
Regards
Roman

Peter
Posts: 82
Joined: Mon Jun 11, 2012 2:09 pm

Post by Peter »

I have a flying wing with this software. Balanced prop, lpf on 20hz, default gyro smoothing, pitch P on 1.8 and TPA on 0.9. And I still get oscillations on high speed for acro and level.

Any ideas? Could I get the Ps from other flying wing owners?

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

Re: Airplane mode RTH

Post by PatrikE »

I need to get familiar with the new .cpp/.h files first.
And the weather is to good for sitting inside.

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

Re:

Post by PatrikE »

Peter wrote:Any ideas? Could I get the Ps from other flying wing owners?

I haven't tested it on a flying wing but try to increase GYRO_SMOOTHING for roll.
GYRO_SMOOTHING {60, 20, 3} I don't think you need to smooth Pitch as much as roll.

TPA on 0.9 should almost disable pid's at full throttle totally.

Otherwise i think you need lower rates for high speed.
Maybe it should be some dual rates in Mwii to handle it.(Not in TX)
Or some sort of deadband.

On my slow Bixler type plane i use Standard Pid's and no smoothing at all...
The problem seems to be related to high speed and to large throws.

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re:

Post by rbirdie001 »

Peter wrote:I have a flying wing with this software. Balanced prop, lpf on 20hz, default gyro smoothing, pitch P on 1.8 and TPA on 0.9. And I still get oscillations on high speed for acro and level.

Any ideas? Could I get the Ps from other flying wing owners?


Hi Peter,
I'm now on holidays so I have only laptop with some old config, but at leat I share this for the first reference:
MW_flying_wing.png

You can try it. Generally I don't like much D terms, somehow for me it usually makes things worse than better (even in multicopter world).
Put also in flying wing section of config.h in values from #define PITCH_DIRECTION_L to ROLL_DIRECTION_R numbers 0.5 or -0.5 instead of 1 or -1. It reduces too big throws and "splits" elevon travel between AILE and ELE. When values are +-1 and ELEVATOR and AILERON throws are in the same direction, elevon soon reaches its travel end.
Also I have some vibrations (if the motor is running, I have slight jello efect on the attached camera) but with LPF 42Hz and some litle gyro smoothing it works. With 1500kV motor on 3S should be vibration freuency somewhere between 50-300Hz so 20Hz LPF should be OK.
More info I can post next week, when I'll be back home at my table PC.
Good luck.
Roman

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re:

Post by rbirdie001 »

Peter wrote:I have a flying wing with this software. Balanced prop, lpf on 20hz, default gyro smoothing, pitch P on 1.8 and TPA on 0.9. And I still get oscillations on high speed for acro and level.

Any ideas? Could I get the Ps from other flying wing owners?


Hi Peter,
as I promised, here are my actual working settings I use on my 900mm flying wing Toro 900.
FW_nav_RTH_config_Toro_blue_working_20130724.png
Here are some important parts from my config.h file:

Code: Select all

/*************************************************************************************************/
/****           CONFIGURABLE PARAMETERS                                                       ****/
/*************************************************************************************************/

/* Correct direction by setting +/-
   Increase for harder compensating
   Set to Zero to  disable         */
#define GPS_RUDDCORR   1    // P for Rudder.
#define GPS_NAVCORR    2    // P for Roll.
#define GPS_ALTCORR    2   // P for Elevator.

/* Maximum Limits for controlls */
#define GPS_MAXCORR    22   // Degrees banking allowed.
#define GPS_MAXCLIMB   15   // Degrees climbing allowed. To much can stall plane.

//#define SAFETY_SWITCH  AUX4 // Use a Safty switch for AutoThrottle. Must be over 1700�s THROTTLE can also be used
#define CLIMBTHROTTLE  1700 // Max allowed throttle in GPS modes .
#define CRUICETHROTTLE 1500 // Throttle to set in cruice. bylo 1300

// ....!!! New Defs !!!....
#define IDLE_THROTTLE 1200  // Lowest throttleValue during Descend was 1150
#define SCALER_THROTTLE 10   // Adjust to Match Power/Weiget ratio of your model
#define RTH_BAILOUT  true  // Forced RTH Climbout with Level Wings
#define FAILSAFE_RTH true  // Enable RTH for failsafe incl Auto DisARM at home


#define ELEVATORCOMPENSATION 120 // Compensate elevator with % of rollAngle
                                 // Elevator compensates up when plane Roll
 
    #define FLYING_WING
 
    /***************************    independent sensors    ********************************/
      /* leave it commented if you already checked a specific board above */
      /* I2C gyroscope */
      //#define WMP
      //#define ITG3200
      //#define L3G4200D
      #define MPU6050       //combo + ACC

      /* enforce your individual sensor orientation - even overrides board specific defaults */
      #define FORCE_ACC_ORIENTATION(X, Y, Z)  {imu.accADC[ROLL]  =  -X; imu.accADC[PITCH]  = -Y; imu.accADC[YAW]  = Z;}
      #define FORCE_GYRO_ORIENTATION(X, Y, Z) {imu.gyroADC[ROLL] = Y; imu.gyroADC[PITCH] =  -X; imu.gyroADC[YAW] = -Z;}
      //#define FORCE_MAG_ORIENTATION(X, Y, Z)  {imu.magADC[ROLL]  =  X; imu.magADC[PITCH]  =  Y; imu.magADC[YAW]  = Z;}

  /***********************          Flying Wing                   ***********************/
    /* you can change change servo orientation and servo min/max values here
       valid for all flight modes, even passThrough mode
       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)
 
      /* MPU6050 Low pass filter setting. In case you cannot eliminate all vibrations to the Gyro, you can try

      #define MPU6050_LPF_20HZ
       // Use this only in extreme cases, rather change motors and/or props

    /
      #define GYRO_SMOOTHING {10, 10, 3}    // (*) separate averaging ranges for roll, pitch, yaw

  /************************        continuous gyro calibration        ********************/
  /* Gyrocalibration will be repeated if copter is moving during calibration. */
    #define GYROCALIBRATIONFAILSAFE

 
    #define FAILSAFE                                // uncomment  to activate the failsafe function
    #define FAILSAFE_DELAY     30                     // Guard time for failsafe activation after signal lost. 1 step = 0.1sec - 1sec in example
    #define FAILSAFE_OFF_DELAY 600                    // Time for Landing before motors stop in 0.1sec. 1 step = 0.1sec - 20sec in example
    #define FAILSAFE_THROTTLE  (MINTHROTTLE + 300)    // (*) Throttle level used for landing - may be relative to MINTHROTTLE - as in this case

    #define GPS_PROMINI_SERIAL   // Will Autosense if GPS is connected when ardu boots
   
    #define GPS_BAUD   115200

    #define NMEA
   
    #define GPS_LEAD_FILTER                      // Adds a forward predictive filterig to compensate gps lag. Code based on Jason Short's lead filter implementation
   
    #define GPS_FILTERING                        // add a 5 element moving average filter to GPS coordinates, helps eliminate gps noise but adds latency comment out to disable
    #define GPS_WP_RADIUS              200       // if we are within this distance to a waypoint then we consider it reached (distance is in cm)
    #define NAV_SLEW_RATE              30        // Adds a rate control to nav output, will smoothen out nav angle spikes

    #define MOTOR_STOP

  /***********************         Servo Refreshrates            ***********************/
    /* Default 50Hz Servo refresh rate*/
    #define SERVO_RFR_50HZ

I see as a very important "flying wing" section, where are +-0.5 values instead of values +-1. This limits crazy throws which original config gives.
Also check carefully if both GYRO and ACC have correct orientation. As you can see, I had to make custom adjustments in the sensor orientation section, which is very strange if you consider that MPU6050 have both GYRO+ACC on a single chip, but this is FOR ME proven correct. Check it according this description http://www.multiwii.com/faq (nearly at the end of the page.)
Not much time now so please look at it and give some attempts. If you have some more questions, ask now or wait 2 more weeks because I'll be two weeks on holidays. :D
Good luck!
Roman

Romeo84
Posts: 16
Joined: Wed Aug 21, 2013 8:32 pm

Re: Airplane mode RTH

Post by Romeo84 »

Hello guys.
I'm from Russia and speak english bad. So i can't understand, what should i do to my airplane come back to me (to home) when it lost signal from my TX(or when i switch off it). Help me please. I have got crius multiwii, gps, i2c gps, software version 2.2 installed on my plane. Help me please.. )

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

Re: Airplane mode RTH

Post by PatrikE »

Hi,
You can find the latest RTH here. MultiWii/Airplane/NAV_PID.rar
Use the Gui from /MultiWii_dev_2013_07_15_r1539.zip to setup servos.

Set NavR PID's in Gui To
P 1.4
I 0.08
D 0.045

Good luck
PatrikE

surf_akinys
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by 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 :)

Romeo84
Posts: 16
Joined: Wed Aug 21, 2013 8:32 pm

Re: Airplane mode RTH

Post by Romeo84 »

PatrikE Thanks!

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

Re: Airplane mode RTH

Post by PatrikE »

RTH really saved my day!...

Flew FPV and managed to knock my groundstation over.... :o
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. :D

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

Now i have to resolder my cloverleaf antenna!

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Airplane mode RTH

Post by crashlander »

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

Regards
Andrej

Vertigo
Posts: 41
Joined: Mon Jul 08, 2013 6:58 pm

Re: Airplane mode RTH

Post by 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
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Airplane mode RTH

Post by rbirdie001 »

Vertigo wrote: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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

surf_akinys wrote: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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

Vertigo wrote: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
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Airplane mode RTH

Post by crashlander »

surf_akinys wrote: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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

crashlander wrote:
surf_akinys wrote: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
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Airplane mode RTH

Post by crashlander »

surf_akinys wrote: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
Last edited by crashlander on Thu Aug 29, 2013 11:02 am, edited 2 times in total.

surf_akinys
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

crashlander wrote: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
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Airplane mode RTH

Post by 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 :lol: )
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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by 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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

crashlander wrote:
surf_akinys wrote: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
Last edited by surf_akinys on Thu Aug 29, 2013 8:21 pm, edited 1 time in total.

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Airplane mode RTH

Post by crashlander »

rbirdie001 wrote: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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

crashlander wrote:
@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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Airplane mode RTH

Post by 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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by 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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

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

Akinys

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Airplane mode RTH

Post by rbirdie001 »

surf_akinys wrote:..
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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by 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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by 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
Posts: 4
Joined: Sat Aug 24, 2013 3:33 pm

Re: Airplane mode RTH

Post by 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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Airplane mode RTH

Post by 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
Posts: 19
Joined: Wed Jun 05, 2013 9:47 pm

Re: Airplane mode RTH

Post by surf_akinys »

rbirdie001 wrote: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
Posts: 4
Joined: Sat Aug 24, 2013 3:33 pm

Re: Airplane mode RTH

Post by dieterke »

PatrikE wrote: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
Posts: 4
Joined: Sat Aug 24, 2013 3:33 pm

Re: Airplane mode RTH

Post by dieterke »

PatrikE wrote: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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: Airplane mode RTH

Post by PatrikE »

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

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

Re: Airplane mode RTH

Post by 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
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: Airplane mode RTH

Post by rbirdie001 »

surf_akinys wrote: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" :D .
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 :D )
Regards
Roman

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: Airplane mode RTH

Post by crashlander »

dieterke wrote: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

Post Reply