Airplane mode RTH

rbirdie001 · Post by **rbirdie001** » Mon May 06, 2013 9:55 am

crashlander wrote: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 · Post by **crashlander** » Mon May 06, 2013 11:37 am

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 · Post by **dr.tom** » Tue May 21, 2013 8:27 pm

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 · Post by **crashlander** » Wed May 22, 2013 7:12 am

@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 · Post by **Exyator** » Sat May 25, 2013 4:59 pm

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 · Post by **crashlander** » Sat May 25, 2013 5:32 pm

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 · Post by **Mis** » Sat May 25, 2013 8:34 pm

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 · Post by **PatrikE** » Sun May 26, 2013 7:18 am

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 · Post by **crashlander** » Sun May 26, 2013 10:20 am

@ 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 · Post by **danielzt** » Mon May 27, 2013 5:57 pm

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 · Post by **PatrikE** » Mon May 27, 2013 7:12 pm

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 · Post by **danielzt** » Mon May 27, 2013 11:06 pm

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 · Post by **PatrikE** » Tue May 28, 2013 8:01 am

danielzt wrote: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..

danielzt wrote: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 · Post by **rossbemo** » Thu Jun 06, 2013 4:18 pm

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 · Post by **Kayle** » Fri Jun 07, 2013 4:52 am

rbirdie001 wrote:
Kayle wrote: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 · Post by **crashlander** » Fri Jun 07, 2013 8:13 am

Kayle wrote: 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 · Post by **Kayle** » Fri Jun 07, 2013 6:22 pm

crashlander wrote:
Kayle wrote: 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 · Post by **rbirdie001** » Fri Jun 07, 2013 8:57 pm

Kayle wrote: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 · Post by **Exyator** » Sat Jun 08, 2013 9:39 pm

crashlander wrote:@ 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 · Post by **PatrikE** » Sat Jun 08, 2013 11:13 pm

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 · Post by **rbirdie001** » Tue Jun 11, 2013 10:59 pm

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 :lol:

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 · Post by **PatrikE** » Wed Jun 12, 2013 3:43 am

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 · Post by **rbirdie001** » Wed Jun 12, 2013 7:41 am

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 · Post by **crashlander** » Wed Jun 12, 2013 8:13 am

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 · Post by **Kayle** » Wed Jun 12, 2013 9:18 pm

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

rbirdie001 wrote:
Kayle wrote: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 · Post by **rbirdie001** » Thu Jun 13, 2013 9:05 pm

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 · Post by **PatrikE** » Fri Jun 14, 2013 9:08 pm

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 · Post by **rbirdie001** » Sat Jun 15, 2013 10:56 am

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 · Post by **Kayle** » Sun Jun 16, 2013 5:47 pm

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

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

rbirdie001 wrote:
Kayle wrote: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 · Post by **PatrikE** » Sun Jun 16, 2013 9:38 pm

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.

rbirdie001 · Post by **rbirdie001** » Sun Jun 16, 2013 9:50 pm

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 · Post by **rbirdie001** » Sun Jun 16, 2013 10:13 pm

Hi Guys,
finally everything works!

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 · Post by **aydineser** » Mon Jun 17, 2013 12:04 pm

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 · Post by **rbirdie001** » Mon Jun 17, 2013 3:14 pm

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 · Post by **aydineser** » Mon Jun 17, 2013 3:56 pm

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

crashlander · Post by **crashlander** » Mon Jun 17, 2013 6:15 pm

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 · Post by **aydineser** » Tue Jun 25, 2013 12:00 pm

Hi patrik,

Does your RTH code including Crostracking ?

Aydin

PatrikE · Post by **PatrikE** » Tue Jun 25, 2013 3:16 pm

aydineser wrote:Hi patrik,

Does your RTH code including Crostracking ?

Aydin

Nope..
Just stear towards waypoint.

surf_akinys · Post by **surf_akinys** » Wed Jun 26, 2013 11:21 pm

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 · Post by **PatrikE** » Thu Jun 27, 2013 7:20 pm

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 · Post by **rbirdie001** » Fri Jul 12, 2013 1:08 pm

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"

?
Once more thanks to all, namely Patrik for the effort!
Have all nice holidays!
Regards
Roman

Peter · Post by **Peter** » Fri Jul 12, 2013 3:42 pm

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 · Post by **PatrikE** » Fri Jul 12, 2013 8:25 pm

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

PatrikE · Post by **PatrikE** » Wed Jul 17, 2013 10:42 pm

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 · Post by **rbirdie001** » Sat Jul 20, 2013 10:47 am

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:

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 · Post by **rbirdie001** » Wed Jul 24, 2013 6:07 pm

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.

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.

Good luck!
Roman

Romeo84 · Post by **Romeo84** » Wed Aug 21, 2013 9:34 pm

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 · Post by **PatrikE** » Thu Aug 22, 2013 10:22 am

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 · Post by **surf_akinys** » Thu Aug 22, 2013 9:21 pm

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 · Post by **Romeo84** » Fri Aug 23, 2013 1:58 pm

PatrikE Thanks!