Airplane mode RTH

[Kayle]

Hello,

I have a simple question The Version is shown in GUI as v221. So is it based on mw2.2 ? I ask because i want to use kv-team osd which Support only mw Versions greater than 2.1

Kayle

[crashlander]

Yes it is based on 2.2 (or at least one of the latest pre 2.2 versions (maybe even post 2.2 dev versions))!
So the OSD is working.

Regards
Andrej

[Kayle]

Thank you for your help.

Kayle

[PatrikE]

It's based on _shared branch from 0322.
So its newer than V2.2

[Kayle]

Thank you Patrik. Another question: i use a GPS with 9600 Baud ( default from GPS ). I use a mtk gps in nmea mode with an i2c gps board. In gui i get 3d fix. So it seems to work. Is there any disadvantage with such a low baudrate ?

Kayle

[PatrikE]

Only thing is at 9.6k the updaterate gets lower.
But i dont hink its any disadvatage on planes.

[Kayle]

Hello,

yesterday i changed the baudrate from 9k6 to 38k4. I changed it in the GPS and in the i2c nav board. Today it was the maiden flight with gps, multiwii and osd. The osd works good but it shows wrong values for height, amps and speed. Thats another problem. The main problem was that when i switch to "angle" mode my flying wing shakes so much that i don´t can fly with it. So the most time i use "passthrough" mode. I have a lot vibrations and use LPF Filter on 98hz and gyro smoothing. I think i must tune my pid ( at the moment the pid are default ). Or should i use a lower LPF Filter ?

Kayle

[crashlander]

For mpu6050 I'm using

Code: Select all

#define GYRO_SMOOTHING {20, 20, 3} 

with no LPF and it works perfectly (with default PID's).

Regards
Andrej

[Kayle]

For mpu6050 I'm using

Code: Select all

#define GYRO_SMOOTHING {20, 20, 3} 

with no LPF and it works perfectly (with default PID's).

Regards
Andrej

Thanks. Don you have many vibrations on your plane ?

[PatrikE]

I dont use any at all in my plane.
Poorly Balanced motor and prop.

I use a Mongroose Fc.
Itg gyro.
Bma acc.

But a flying wing might transport Vibrations More han a Bixler typer.

Gyrosmoothing dont smooth Acc.
Test 42hz lpf
Fix the Vibrations first.

[rbirdie001]

The main problem was that when i switch to "angle" mode my flying wing shakes so much that i don´t can fly with it. So the most time i use "passthrough" mode. I have a lot vibrations and use LPF Filter on 98hz and gyro smoothing. I think i must tune my pid ( at the moment the pid are default ). Or should i use a lower LPF Filter ?
Kayle

Hi Kayle,
for more exact answers would help if you in description clearly separate between Gyro mode (not passthru but nothing else active) and Acc mode (not passthru+level or horizon active) also between random crazy shaking, especially when motor is on (probably vibrations) and regullar pulsing which can happen even during gliding without engine, especially at higher speed during descend (probably oscillations).
Stock PID (created for multicopter) were too high for my plane with big control throws (Easystar with digital servos and big throws) but too low for my other "lazy" plane where ailerons have very little effect. So at first you can try lovering P value (try e.g. 3.3->2.2) and observe if it improves and if plane shakes also while gliding. First test in Gyro only mode (no checkbox active), when OK, you can test ACC as well. Then you can find the solution or at least ask more exactly.
Good luck
Roman

[Kayle]

Hi Roman,

thanks for reply. My Plane is a HK Teksumo Flying Wing with "big" control throws. During gliding the "shaking" is not so much like with motor is on. So i think i have to much vibrations. First i fix the vibration and then i will lower my P Pid value.

Kayle

[rbirdie001]

Hi Roman,
thanks for reply. My Plane is a HK Teksumo Flying Wing with "big" control throws. During gliding the "shaking" is not so much like with motor is on. So i think i have to much vibrations. First i fix the vibration and then i will lower my P Pid value.
Kayle

Probably you are right and vibrations from the motor are always bad and should be avoided as much a possible.
Higher speed gives more effect to control throws so to be sure, do an easy test:
Try gliding at minimal speed and then push a little elevator and let plane gain higher speed by descending. It the shaking get worse, you probably have too high P.
Be sure you don't have ACC active, only GYRO.
ACC is the next step when GYRO mode is OK.
Roman

[Kayle]

Hello,

I fix the vibrations as good as possible. Then i select 42hz lpf and lower my pid. Tomorrow i will Test and give Report.

Kayle

[rbirdie001]

I use a function to slowdown Flaps.
It could be possible to use similar function for Nav if Nav error is bigger than ex.100.
And if the error is less use full speed.

It could look like this.

Code: Select all

// Test to slowdown servos NOTE!.. Untested
      #define SERVOSPEED   3  // zero to disable  Increase for faster speed reverse with minus
      #define SLOW_ANGLE 100  // Ajust where slow servos activates >> if (dif > SLOW_ANGLE) <<
      static int16_t slowNav = dif;
      if (slowNav < dif ){slowNav+=SERVOSPEED;}else if(slowNav > dif){slowNav-=SERVOSPEED;}     
      if(abs(dif) > SLOW_ANGLE  && SERVOSPEED != 0) dif = (constrain(slowNav,-GPS_MAXCORR*10, GPS_MAXCORR*10));
// Test to slowdown servos *******************

// Limit outputs
.....

The code compiles but is untested in the plane.
The servospeed is dependant on the cykleTime. It adds 3µs to slowNav every loop.
Be careful if testing.
Patrik

Hi Guys,
I have to report you an unsuccessfull testing of gyro slowdown function above.
I tested it on he ground but not enough and this will cost me a lot of glue .
I can't say exactly what is wrong with it. It seems that this patch some way out-trim the plane even in gyro only mode, which is strange. I trimmed it temporary by ELE trim so it was so-so flying in gyro and acc mode. Then I tried to activate RTH. Bailout to 35m worked as usual so I didn't suspect that something can get so much wrong, When plane started turning home, it got very fast diving spiral under high throtle and crashed so fast, that I didn't time to realise what's happenning and where I can disable RTH.
My fault, I wasn't ready...
Just for you to know that you have to be really carefull with this.
Roman

[dr.tom]

I am happily waiting for further development here, I don't understand coding like you,
but can try it on the field and report bugs if I find any

especially looking forward to ability to take speed into account, because fast planes must NOT turn too sharp,like bixler or some other FPV planes can, full deflection of control surfaces...
it can rip them appart.. (I will try to install it int o 330+ km/h rc plane )
with small arduino board 3-4 grams, + IMU 4 grams + gps around 20 grams, it should be possible.

than with reliable RTH i can put vtx on it and try insane fast FPV with failsafe in case video link gets disrupted

http://www.youtube.com/watch?v=DPBYCDJ4H2M
http://www.youtube.com/watch?v=kWZvo6Auuqs

[crashlander]

@dr.tom
Operating 300km/h+ planes over shaky FPV link it's almost "criminally insane" by itself.
But the current (from march) code is IMO stable and tested enough that you can put it on your X8 and test RTH from couple of km (I have only tested it on sub 1km distances).

Regards
Andrej

[rbirdie001]

I will try to install it int o 330+ km/h rc plane

Hi dr.tom,
also I agree with Andrej, that FPV on such plane can be quite dangerous! If you are going to fly in the middle of desert or wide fields, it can be quite OK, but when you (or someone else) get idea compete with cars on the highway or flying in public areas, then it's like shooting blinded in the park...
If you read RC forums, you have to know that there is rising pressure from goverments (US is the first but in Europe it comes as well) to stronger bind and regulate RC hobby, especially FPV and every acciddent or maybe even dangerous video on YT can strengten that force. So please keep your brain in your head and don't give them evidence that they are right.
Thanks
Roman

[rbirdie001]

Hi guys,
I have some bad times now because last two RTH testing days ended up in plane scaterred into pieces.
On the 1st May I was testing servo slowdown function to make navigation more fluent and my plane experienced bad crash with these results:

In short it was probably caused by slowed down reaction of autopilot because my plane started rotating in fast spiral (so heading vector was fast turning around). When the direction was just right, autopilot wanted to stop turning and keep the current direction but it wasn't fast enough so plane overshoot the turn and keep turning. It was turning faster and faster and at the end ended up in a fast diving spiral and a crash.
It costed me a lot of glue but I repaired the plane (god bless the inventor of EPP material!) so I told myself that I should start again with something basic which works fine.

So I took pure FW_Nav_130322 just with added following line:

Code: Select all

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

and with one new change in config.h:

Code: Select all

#define RTH_BAILOUT  false  // Forced RTH Climbout with Level Wings

I decide to disable straight climbing because for some reasons my plane was always overshooting the safe height very much (probably because of GPS lag) so even if the safe height was set to 50m, it usually started turning home when it was about ~250m high and ~400m away. Unfortunately I didn't realize that it also means that navigation will be performed at CLIMBTHROTTLE 1800 and not CRUICETHROTTLE 1500.
Yesteday I was testing it and result was even worse crash and even more damage on the plane:

What happened?
Something I know but something is mysterious. Here is the video: http://www.youtube.com/watch?v=Ss67va4QxMk&
I started the plane in ACC mode and at about 0:20 I activated RTH.
Automatic started navigation but because the plane was under the safe height, it also applied CLIMBTHROTTLE 1800 and started climbing. My usual PID were probably too high for that speed and elevator control was additionally affected by pulses from navigation input (ELEVATORCOMPENSATION 80) (we know that navigation at turns isn't 100% smooth and there is usually some jerking) so plane started wawing UP and DOWN on PITCH axis. It didn't look SOOO dangerous so I didn't disable RTH and watched if it recoveres alone.
My Easystar II was about stock weight (~770g) - no FPV gear installed yet - but unbeliveable happened - it's wing broke in the air from the PITCH pulses just where the laminate wing spar ends!
The result was obvious - spiral fall - but while the plane was falling I tried to stick control the plane at least to slowdown the fall but it looked that no stick input had any effect.
After the plane "landed", you can hear in the video strange beeping pattern (LLL?), which I cant find here: http://code.google.com/p/multiwii/wiki/ ... ion_Buzzer so this is also piece of mystery. Maybe something happened also in electronic?
Any ideas what could have happenned are wellcome but now I'm going make for some days/weeks break in my testing. My plane will need a LOT of glue and I need to gain some time and power for it.
I just hope these my experiences will help others to avoid similar crashes.
Good luck!
Roman

[crashlander]

Ugly crash!

but while the plane was falling I tried to stick control the plane at least to slowdown the fall but it looked that no stick input had any effect.

It is quite possible that during descend the plane was in very stable stall turn and thus the lack of stick control.

means that navigation will be performed at CLIMBTHROTTLE 1800 and not CRUICETHROTTLE 1500

I prefer this way of handling RTH since level wings normally takes my wing too far away and also at he end of climb the wing gets into uneasy "TH low > wing level > wing turn" maneuver that means immediate drop of height (my wing has quite big speed tolerances so it is hard to overspeed it especially in climb). Maybe you should lower CLIMBTHROTTLE.
Also from your video it does not seem that your plane is pitching up (climbing) when RTH is enabled, or is just camera wide angle?!

During last week I had couple of successful PH and RTH flights with my and friend's wing (with both 130322 and later unpublished servo-test version of Patrik's code).

Regards
Andrej

[rbirdie001]

Ugly crash!

but while the plane was falling I tried to stick control the plane at least to slowdown the fall but it looked that no stick input had any effect.

It is quite possible that during descend the plane was in very stable stall turn and thus the lack of stick control.

While the plane was falling down, whole half of one main wing was missing but anyway I hoped that full ELEVATOR or AILERON (truly only one aileron ) can affect turning speed or something, but really NOTHING happened. What about that strange beeping at the end?

means that navigation will be performed at CLIMBTHROTTLE 1800 and not CRUICETHROTTLE 1500

I prefer this way of handling RTH since level wings normally takes my wing too far away and also at he end of climb the wing gets into uneasy "TH low > wing level > wing turn" maneuver that means immediate drop of height (my wing has quite big speed tolerances so it is hard to overspeed it especially in climb). Maybe you should lower CLIMBTHROTTLE.
Also from your video it does not seem that your plane is pitching up (climbing) when RTH is enabled, or is just camera wide angle?!

My plane have quite weak engine (thrust about 60% of plane weight) so for climbing I rather set higher throttle to be sure that stall condition won't happen.
While I was using RTH_BAILOUT true, it worked perfectly, just the plane got uncomfortably far and high before it started turning home (my 10Hz GPS has strange lag on height readings so plane always overshooted safe height very much).
I think that when RTH was activated, plane really set ELEVATOR for climbing, but because at the same time it banked for turn, elevator throw was used for turn to made it tighter (smaller radius) so in fact the nose didn't point too much up. That theory supports also fact, that after RTH activation plane made two full 360deg. turns meaning that it twice missed correct heading to home without levelling wings. Turning was probably too fast and navigation loop too slow to react. (I think that navigation PID instead of P would help here...)
I don't think that plane "wawing" (like a racing swimmer under water) came from overspeed (the engine really isn't strong enough to overspeed the plane at climb) but was introduced from navigation code and amplified by GYRO and ACC PID.
One day when I repair the plane (damage is now really big ) I'll try to even lover allowed banking (so open turns), reactivate RTH_BAILOUT true and set very low safe height (expecting it will overshoot anyway).
Next days I'll be on holidays so have nice days!
Roman

[crashlander]

What about that strange beeping at the end?

I do not have beeper on any of my MWII's so beeping is unfamiliar to me.

My plane have quite weak engine (thrust about 60% of plane weight)

Also my wing has poor push/weight ratio but it still climbs easily with CLIMBTHROTTLE 1950.

very low safe height (expecting it will overshoot anyway)

As you can see from my videos the wing overshoots target height for 7m at most (but I'm using UBlox binary protocol with NEO6)!

Enjoy your holidays and I hope you will soon gain enough willpower to repair your plane and continue testing.
Regards
Andrej

[dr.tom]

here's my setup,


from left to right:
serial Ublox gps sensor, RCTimer - http://www.rctimer.com/index.php?gOo=go ... oductname=
328p serial gps <---> i2c converter - http://rctimer.com/index.php?gOo=goods_ ... oductname=
328p based shield with GY86 IMU - http://www.goodluckbuy.com/kcopter-mult ... s5611.html (after initial tests, gonna be replaced with promini+same IMU, for smaller footprint to fit into plane )
USB FTDI adapter...

it works well with this i2c fw, tested many times last year (before AIO PRO came to market)
http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=
and 2.1 MWC code for multirotors
http://code.google.com/p/multiwii/downl ... p&can=2&q=

pic



now I tried this airplaneNAV version, it seems to work on bench
https://code.google.com/p/multiwii/sour ... 130322.rar

pic



anybody has some advice? I see some crashed planes here, want to minimise the risk, if some bug was found in code or similar... ?
I really want to try it on my very fast plane this summer, my primary RTH OSD can't fit in it's fuse (StormOSD) but still, I don't want to lose the plane because of experimenting with new code

thanks


P.S. is this fw going to work with this OSD?
http://www.rctimer.com/index.php?gOo=go ... oductname=
http://www.rcgroups.com/forums/showthread.php?t=1786599

[crashlander]

@dr.tom
That (and one after (even less official)) release was successfully tested many times on flying wing by me, my friend and rbirdie001 (on plane).
Tests on my side were done using Crius AIO Pro (Mega2560) and serial GPS (UBLOX and NMEA).
IMO planes/wings that have wider speed margin are easier to setup since before you will fine-tune parameters as:

Code: Select all

#define CLIMBTHROTTLE 
#define CRUICETHROTTLE
#define IDLE_THROTTLE
#define SCALER_THROTTLE
#define ELEVATORCOMPENSATION

your flying object will probably gain some speed in turns, especially first turn when RTH is enabled and when ALT is higher than set, or will lose speed when reaching home and start to circle with min or no TH.

Regards
Andrej

[Exyator]

Hi everybody,
First of all I'd like to thank everyone who worked on this.
Today I tried FW_Nav_130322 on my Skywalker, RTH seemed to work fine, the plane turned to home(I couldn't wait until it would start to circle, there was a road nearby).
All the stabilized modes too (angle, horizon, acro).
I have a question about "angle" mode, on what axes should the aircraft auto-level?
Mine seemed to keep level wings, but did allow me to set it in a climb angle (and leave the sticks).

[crashlander]

It should level on both axes. Look for the thread of Airplane integration because I believe there are some tips for PID setup.

Regards
Andrej

[Mis]

Mine seemed to keep level wings, but did allow me to set it in a climb angle (and leave the sticks).

You must perform ACC calibration with more "nose" down.

[PatrikE]

A perfect trimmed acc should be able to fly the plane level with less than +/- 1/100 height change at cruicethrottlein LevelMode.
In gpsmode the alt will be corrected by gpsAlt, But the gps accuracy is >2 and have some latency.

[crashlander]

@ Exyator
You asked incomplete question and got three correct but maybe insufficient answers...

So to summarize:
If your plane always tries to level with nose up (climbing) than you should set/reset level with slightly nose down.
If your plane levels perfectly on aileron axis but keeps pitch position in whatever angel for long time than it can be wrong PID on pitch axis. Planes tend to be more stable (harder to disturb) on pitch than on roll.
And perfectly level trimmed plane should keep its course (altitude and direction) in angle/level mode for long time and if you disturb-it it should return to level in short.

Regards
Andrej

[danielzt]

Hi Patrik

I downloaded the file "FW_Nav_130322" of your branch and I think I found a bug on RTH function. Could you please take a look?

On line:

Code: Select all

      GPS_AltErr = GPS_altitude - GPS_hold[ALT]; // Altitude error - means your'e to low

I should be HOME instead of HOLD... I'm I correct?

Code: Select all

      GPS_AltErr = GPS_altitude - GPS_home[ALT]; // Altitude error - means your'e to low

Also I inserted a minimum altitude for the RTH function, since the plane can be flying somewhere higher than home location. So this was my final and working version:

Code: Select all

      GPS_AltErr = GPS_altitude - GPS_home[ALT] - RTH_MINALTITUDE; // Altitude error - means your'e to low

And inserted on config:

Code: Select all

#define RTH_MINALTITUDE    50

Thanks

[PatrikE]

GPS_home[ALT] only holds the Altitude of Home position.

GPS_hold[ALT] Is the is the Altitude of Home position + PID ALT D . = 50 meters Over startingpoint

Code: Select all

GPS_hold[ALT]  =  conf.pid[PIDALT].D8  + GPS_home[ALT];

It's set in when f.GPS_HOME_MODE is set in multiWii tab.

PID ALT D is set in Gui. and is set to 50 as default.

Good catch
But no need to modify i think.

/Patrik

[danielzt]

You're right, confirmed!

I checked that RTH only works when enabled with ANGLE or HORIZON... Why?

Is there anyone working on waypoints? I would like to do it

Thanks

[PatrikE]

I checked that RTH only works when enabled with ANGLE or HORIZON... Why?

It's works the same way for MUlticopters to.
Probaby it's a good ide'a if the model is able to fly Level before it try to navigate..

Is there anyone working on waypoints? I would like to do it

Not in the present code.
EosBandi is working on a new Gps/Navigation.
And hopefully it will include waypoints.

You could experiment with Eizo adroidApp.
There's a function to move the returnPoint temporarily.
You need a BlueTooth/433mhz relay station of course to increase the range.

PositionHold sets a waypoint when enabled.
You could Hardcode a WP ex. 200 meter away from Home and switch between Rth and Hold.(Pylon)

[rossbemo]

I just wanted to say thank you to all of you who developed the code for the airplane RTH. I've used it on my popwing with excellent results. I've tested it out to about a mile and flip the switch... and home it comes! For reference I'm using the multiwii pro v1 with Ublox 5hz GPS from witespy.

-Ross

P.S. Would it be possible to add in the OSD code, or is there not enough room on the board?

[Kayle]

Hi Roman,
thanks for reply. My Plane is a HK Teksumo Flying Wing with "big" control throws. During gliding the "shaking" is not so much like with motor is on. So i think i have to much vibrations. First i fix the vibration and then i will lower my P Pid value.
Kayle

Probably you are right and vibrations from the motor are always bad and should be avoided as much a possible.
Higher speed gives more effect to control throws so to be sure, do an easy test:
Try gliding at minimal speed and then push a little elevator and let plane gain higher speed by descending. It the shaking get worse, you probably have too high P.
Be sure you don't have ACC active, only GYRO.
ACC is the next step when GYRO mode is OK.
Roman

Hello,

yesterday i did another Test. Gyro Mode is OK now. It flies very great in Gyro Mode. But when i switch to ACC / Level Mode my FlyingWing does a "roll of death" It turns over right side and put the nose down. I don´t know why. Question -> What P Value should LEVEL have ?

Kayle

[crashlander]

But when i switch to ACC / Level Mode my FlyingWing does a "roll of death" It turns over right side and put the nose down.

Did you calibrate ACC with wing level (in GUI or with stick combination)?!
What happens when you enable Level/Horizon mode when wing is level in your hands/on the ground (normally you should not observe any real throw of control surfaces).
Even completely wrong P in level should not produce strong roll or pitch correction out of level when the above conditions are met.

Regards
Andrej

[Kayle]

But when i switch to ACC / Level Mode my FlyingWing does a "roll of death" It turns over right side and put the nose down.

Did you calibrate ACC with wing level (in GUI or with stick combination)?!
What happens when you enable Level/Horizon mode when wing is level in your hands/on the ground (normally you should not observe any real throw of control surfaces).
Even completely wrong P in level should not produce strong roll or pitch correction out of level when the above conditions are met.

Regards
Andrej

Hello,

ACC is calibrated. On ground the control throws goes in correct direction. So i think i have to much vibrations when Motor is in

Kayle

[rbirdie001]

ACC is calibrated. On ground the control throws goes in correct direction. So i think i have to much vibrations when Motor is in
Kayle

Hi Kayle,
not everything is caused by vibrations...
If the gyro mode is OK, easy test for ACC:
Calibrate ACC with plane levelled in all axis. Then if it's in the same position as during calibration, switching between GYRO and ACC mode shouldn't move control surfaces.
When in ACC mode and you take it in hands and move e.g. nose up, elevator should move down and opposite. When you tilt the plane e.g. to the left, ailerons should move contra this movement. These throws should be permanent (i.e. elevator keeps deflected down as long as nose is held up, throw doesn't reset in time but only by levelling the plane back - this is different from GYRO reactions.)
Another trick is that you can guess ACC PID from GYRO PID. For the first attempt correct level PID in the same rate against defaults as you corrected pitch and roll GYRO PIDs.
Last test: When your plane is levelled on the table and GYRO/ACC switchover doesn't do anything, hold the plane firmly and start the engine. Starting engine shouldn't have (almost) any effect to control surfaces, otherwise you have too much vibrations.
OK?
Roman

[Exyator]

@ Exyator
You asked incomplete question and got three correct but maybe insufficient answers...

So to summarize:
If your plane always tries to level with nose up (climbing) than you should set/reset level with slightly nose down.
If your plane levels perfectly on aileron axis but keeps pitch position in whatever angel for long time than it can be wrong PID on pitch axis. Planes tend to be more stable (harder to disturb) on pitch than on roll.
And perfectly level trimmed plane should keep its course (altitude and direction) in angle/level mode for long time and if you disturb-it it should return to level in short.

Regards
Andrej

Thanks for the detailed answer. I meant the 2nd scenario.
I have flown a couple more times since and noticed that it is leveling on the pitch axis too.

Still need to do some tuning but RTH works great! I do have one question though:

After the aircraft reaches home what should happen?
My Skywalker got to home position, kept flying in the same direction for a couple of seconds, turned ~90 degrees (once to the left and once to the right) and kept flying there until I took over.
Is that correct or should it circle around home position?

Cheers,
Exyator

[PatrikE]

The plane will aim for home repeatedly until batteries run empty.
It turns Randomly right or left after every pass.
But if you enable failsafe Rth it will initiate a landing after first first pass.

[rbirdie001]

Hi Guys!
I'm back after some time!
I sadly looked into the box with pieces of my Easystar scatered during the last RTH test (viewtopic.php?f=7&t=2456&start=210#p35774) and then rather decided to build new 900mm flying wing and tune-up RTH on it...

My new flying wing Toro 900 with stabilization

It's equipped with Crius Lite MWC board (new piece) and Ublox Neo-6M GPS (also new) and after last experience with the Easystar's wing broken in flight is that wing strongly reinforced with carbon and flies great.
I'm still tuning GYRO and ACC mode yet but today I first time tested RTH. It seems to work but I clearly seen the same problem which killed my Easystar - pulsing in PITCH axis during navigation to home.
I mean what you can see here http://www.youtube.com/watch?v=Ss67va4QxMk& from the time 0:21. Today there wasn't so much throttle and this plane is much stiffer than Easystar so this time there wans't any damage, but I clearly saw that both elevons were moving big throws up and down in about 1 second pulses and plane was waving until I disabled RTH.
Plane had already reached safe height and was navigating home @ CRUICETHROTTLE.
First idea was that it could be bad PID and it's caused by GYRO or ACC oscillations but it's probably not. My PIDs are not perfect yet but both GYRO and ACC modes are safely flying without such oscillations so it has to be coming from navigation code (or better to say from height control part because wing was at the time flying in straight line.)
Now I come to the question: Anyone else noticed this? I'm used that I sometimes have problems which nobody else ever seen , but to have such problem on two completely different hardwares
Can someone advice (thanks Patrik ) some averaging filter for GPS height control (not affecting elevator control from ACC and for turns!) I'd like to try if it helps...
Thanks in advance!
Regards
Roman

[PatrikE]

Hi Roman,

A averaging filter would look something like this.

Code: Select all

static int16_t  My_average;
static uint8_t AvgLength = 5; // Adjust length
My_average=((My_average*(AvgLength-1))+ GPS_angle[PITCH])/AvgLength;
GPS_angle[PITCH] = My_average;

Insert in FW_Nav in a suitable location.
Before or after the limit lutputs.
you'll have to test where.
It will only effect GpsPart of the Code and not Gyro/Acc/Radio.

Can it be related to the overshoot in altitude when you tested Bailout?

[rbirdie001]

Hi Patrik,
thanks for quick reply!
I meantime I was still thinking about the possible reasons and have one more idea: I could have too big P value in #define GPS_ALTCORR 6.
Other navigation values I usually lovered for my planes but this value I kept default. I'll play with it and see.
For this new flying wing I bought brand new GPS module with different chipset (previous one was a Mediatek 3329 but current is Ublox Neo-6M - the same as is using Andrej) so I shouldn't have the same problems and if yes, it's not coming from GPS type.
Is there any significant functional difference between the FW_Nav_130322 and the version with servos setup code you sent me PM? I guess that second one is more perspective for future upgrade so shouldn't I rather begin with this one?
Thanks!
Roman

[crashlander]

Welcome back Roman!
I put my wing away for while since I "rediscovered" FPV passion with multi's (bought used FPV googles and build cheap quad) now I'm flying low and not so slow between trees and electrical pool's.
So I only bench tested PatrikE's code based on r1447.
But as you can see from my videos I had no issues with oscillations on pitch axe with almost stock PID's (but it is true that X5 has longer body than normal flying wings). Had some pitch/roll oscillations on my previous wing when flying faster (but those were not GPS based since I could reproduce them in normal gyro/horizon mode).

Regards
Andrej

[Kayle]

Hi Roman,

i recalibrated acc with plane levelled in all axis. When i switch between GYRO and ACC there is a very verry little movement on the Servo. The control throws goes in the correct directions when i tilt the plane. When i switch to ACC and then power up Motor there is also a very little movement on the control throws. So i decide to decrease the level pid from 9 to 5 for test. At the Weekend i will test the plane with acc.

Kayle

ACC is calibrated. On ground the control throws goes in correct direction. So i think i have to much vibrations when Motor is in
Kayle

Hi Kayle,
not everything is caused by vibrations...
If the gyro mode is OK, easy test for ACC:
Calibrate ACC with plane levelled in all axis. Then if it's in the same position as during calibration, switching between GYRO and ACC mode shouldn't move control surfaces.
When in ACC mode and you take it in hands and move e.g. nose up, elevator should move down and opposite. When you tilt the plane e.g. to the left, ailerons should move contra this movement. These throws should be permanent (i.e. elevator keeps deflected down as long as nose is held up, throw doesn't reset in time but only by levelling the plane back - this is different from GYRO reactions.)
Another trick is that you can guess ACC PID from GYRO PID. For the first attempt correct level PID in the same rate against defaults as you corrected pitch and roll GYRO PIDs.
Last test: When your plane is levelled on the table and GYRO/ACC switchover doesn't do anything, hold the plane firmly and start the engine. Starting engine shouldn't have (almost) any effect to control surfaces, otherwise you have too much vibrations.
OK?
Roman

[rbirdie001]

Hi!
Perfect
Today I tested modified navigation on my flying wing Toro 900 with reduced #define GPS_ALTCORR 2 and with elevator control filtering 5 segments long and it was navigating home and circling around it PERFECTLY. I'll have to go back higher with GPS_ALTCORR value because now the autopilot doesn't have enough authority to climb and can even hardly keep the same height level but I hope that if I extend elevator filtering lenght to e.g. 8, elavator won't oscillate even with GPS_ALTCORR 4 or more. Additionally I'll try to move COG of the wing little to front and trim elevons up - this should naturally improve speed/height stability.
I'll let you know about the progress, but again Patrik - THANKS!
Roman
P.S. Okay, I again tried to look into the code and (surprisingly ) I have some more beginners questions:
Is GPS_altitude and other similar variables rated directly in meters? (or centimeters, decimeters...)?
What (aproximately) is the rate (unit) of GPS_angle[PITCH]? (i.e.~ degrees or e.g. servo control miliseconds...)
How ofter is executed FW_Nav part of the code (so how big delay means one step in moving average filter?) Is it each cycle (which I have about 3800 microseconds)?
I ask just to understand how big numbers can I expect where.

Shouldn't be in flying wing section of config.h in values from #define PITCH_DIRECTION_L to ROLL_DIRECTION_R default numbers 0.5 or -0.5 instead of 1 or -1? I expected that this servo travel "splitting" between ELEVATOR and AILERON is done somewhere in the mixing table so I adjusted only +- signs and then I was getting crazy big throws. Additionally when ELEVATOR and AILERON throw were in the same direction, elevon soon reached its travel end. Maybe I missed something, but if not, then it should be corrected even in the main Multiwii code. Am I right or wrong
R.

[PatrikE]

GPS_altitude resolution = Meters
Can be tweaked to dm or cm but real resolution isn't really better than meters.

GPS_angle is degrees x 10

FW_Nav is executed every cycle.
Gps update is depending on your gps 5 - 10 Hz
Actually FW_Nav is doing calculations on old gps data most of the time.
I don't think a larger average will be noticeable for you.
Besides you don't need as fast regulation on a plane as on a multi.

[rbirdie001]

Patrik, thanks for explanation about the units - I'll look into the code with the new info in head.
I was again flying my flying wing with GPS_ALTCORR 4 and GPS_MAXCLIMB 15 and it still looks like that during RTH there isn't any elevator control at all . Plane seems to remain in the same level as I activated RTH and very slowly descends. When I try autolaunch with RTH_BAILOUT true, plane flies on level and doesn't go up until I pull elevator stick. (In the other hand I don't have wawing elevator and this is what I wanted - isn't it? )
Here is how I aplied you averaging function - do you see something wrong?

Code: Select all

// Wrap Heading 180
      if (dif <= - 180) dif += 360; 
      if (dif >= + 180) dif -= 360;

    static int16_t  Elevator_avg;    //elevator filtering
    static uint8_t AvgLength = 8; // Adjust length
    Elevator_avg=((Elevator_avg*(AvgLength-1))+ GPS_angle[PITCH])/AvgLength;
    GPS_angle[PITCH] = Elevator_avg;

// Limit outputs
      GPS_angle[PITCH] = constrain(GPS_angle[PITCH],-GPS_MAXCLIMB*10,GPS_MAXCLIMB*10); 

I'll probably return to original (unfiltered) version to check if there is elevator control again.
Roman
Edit:
Maybe there is an error that variable declaration is executed in every loop. Doesn't it always reset Elevator_avg value?
With the new info from Patrik I anyway think, that lenght e.g. 8 is useless because if the FW_Nav is executed every loop (each ~4ms), this probably means, that filtration have efects for frequencies above cca 30Hz so data from GPS with 5Hz refresh would be directly transfered. It would either need moving average lenght >500 (but then would be needed increase lenght for both variables) or use some flag that there are new GPS data and average only unique GPS data.
As I'm not very confident doing such things, I'll rather as a first step only decrease GPS_ALTCORR to 2 and hope it will remove wawing but keep some height control...
Any ideas or corrections are wellcome, I'm really not very familiar with the coding
Roman

[Kayle]

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 Roman,

i recalibrated acc with plane levelled in all axis. When i switch between GYRO and ACC there is a very verry little movement on the Servo. The control throws goes in the correct directions when i tilt the plane. When i switch to ACC and then power up Motor there is also a very little movement on the control throws. So i decide to decrease the level pid from 9 to 5 for test. At the Weekend i will test the plane with acc.

Kayle

ACC is calibrated. On ground the control throws goes in correct direction. So i think i have to much vibrations when Motor is in
Kayle

Hi Kayle,
not everything is caused by vibrations...
If the gyro mode is OK, easy test for ACC:
Calibrate ACC with plane levelled in all axis. Then if it's in the same position as during calibration, switching between GYRO and ACC mode shouldn't move control surfaces.
When in ACC mode and you take it in hands and move e.g. nose up, elevator should move down and opposite. When you tilt the plane e.g. to the left, ailerons should move contra this movement. These throws should be permanent (i.e. elevator keeps deflected down as long as nose is held up, throw doesn't reset in time but only by levelling the plane back - this is different from GYRO reactions.)
Another trick is that you can guess ACC PID from GYRO PID. For the first attempt correct level PID in the same rate against defaults as you corrected pitch and roll GYRO PIDs.
Last test: When your plane is levelled on the table and GYRO/ACC switchover doesn't do anything, hold the plane firmly and start the engine. Starting engine shouldn't have (almost) any effect to control surfaces, otherwise you have too much vibrations.
OK?
Roman

[PatrikE]

Level p effects the total throw in accMode and makes your plane fly like a Airbus if it's lowered.
If Level is calibrated correct and all sensors is correct orientated you should be able to run stock P on Level.