Airplane mode RTH

PatrikE · Post by **PatrikE** » Thu Oct 24, 2013 1:37 pm

Hi Andrej,

I love to get input on the code!...

The theory..

One don't know what altitude the plane keeps when returning.
It's just there to let the plane circulate and descend with low throttle until RTH altitude is close.
Low throttle makes my plane use propellor as efficient airbrake.
And then Disarm and autoland.

But it's maybe a unnecessary check?

GPS_MAXCORR and GPS_MAXCLIMB is mostly related to the type of plane.
It just limits the Maximum control Gps can apply during navigation.
20-30 degrees is a quite normal banking on most planes.
Maby a little to much in a climb in auto mode.

But as you say.
Better to run lower values as default.

Code: Select all

/* Maximum Limits for controls */
#define GPS_MAXCORR    15   // Degrees banking applied by GPS.
#define GPS_MAXCLIMB   15   // Degrees climbing . To much can stall plane.

One more thing that needs to be determined is The PID max values.

Code: Select all

/* Set Maximum Limits for PID-controls */
#define MAX_I 200    // Increase steps by 10 for more control (1 degree)
#define MAX_D 200    // 100 = 10 degree

Cheers
Patrik

i3dm · Post by **i3dm** » Thu Oct 31, 2013 10:11 am

This is a long and very interesting thread.
i apologize in advance for not reading entirely through it - but is there a good stable version of MultiWii airplane with RTH already available?
if so i might be able to assist in some testing soon..

crashlander · Post by **crashlander** » Thu Oct 31, 2013 7:16 pm

i3dm wrote:This is a long and very interesting thread.
i apologize in advance for not reading entirely through it - but is there a good stable version of MultiWii airplane with RTH already available?
if so i might be able to assist in some testing soon..

IMO nothing is stable!

That said I believe that PatrikE's code is mature and stable enough to test it (no serious bugs is known for long time).
But as always take plane that is not the most expensive / fast / hideous and start learning how to tune it properly.

Regards
Andrej

PatrikE · Post by **PatrikE** » Thu Oct 31, 2013 7:27 pm

Info on latest code download
viewtopic.php?f=7&t=2456&start=340#p42611

rbirdie001 · Post by **rbirdie001** » Mon Nov 04, 2013 12:48 am

Hi Patrik,
new version 131024 is loaded in my flying wing, but there weren't good conditions to test it yet.

Just to be sure - do I understand right, that altitude control was rewritten and now P term is adjusted via GUI (Alt P)? Does it remaid only P or full PID regulator?
Thanks for explanation!
Roman

PatrikE · Post by **PatrikE** » Mon Nov 04, 2013 3:12 am

rbirdie001 wrote:Hi Patrik,
Just to be sure - do I understand right, that altitude control was rewritten and now P term is adjusted via GUI (Alt P)? Does it remaid only P or full PID regulator?
Roman

Use GUI PIDALT P for field adjustments.
Only P is integrated for altitude.

For navigation there is a full PID controlled by Gui NavR P I D.

Let's hope for better weather for testing.

/Patrik

aydineser · Post by **aydineser** » Tue Nov 12, 2013 3:03 pm

Hi Patrik,

I have noticed a few things in your code ...
Firstly roll compansation in gps.cpp

Code: Select all

 line 1478    GPS_angle[PITCH]+=(abs(att.angle[ROLL]) * ELEVATORCOMPENSATION /100); // Compensate elevator compared with rollAngle

then later

Code: Select all

line 1546 // Compensate elevator compared with rollAngle
      GPS_angle[PITCH]-= ( abs(att.angle[ROLL]) * ELEVATORCOMPENSATION ) /100;

I am confused... Is booth lines true or necessary ?

end secondly in PID control loop

Code: Select all

line 1527 naverrorD += ((dif - oldif) *navPID_PARAM.kD) * gpsFreq;
line 1528 naverrorD =constrain(naverrorD,-MAX_D,MAX_D);

You have accumulated Differential error just like Integral ?

Best Regards
Aydin

PatrikE · Post by **PatrikE** » Tue Nov 12, 2013 5:11 pm

Hi Aydin,

I know the ELEVATORCOMPENSATION is added twice.
I don't know at what point it became added the second time.
But since it seems to work as it is i haven't removed any of them.

I would test to remove the first to start with.(Before the constrains)

I actually don't know much about PID.
Any help on this is appreciated..

I think the PID is what's missing for launching it in public branch.

Greets
Patrik

aydineser · Post by **aydineser** » Wed Nov 13, 2013 12:55 pm

Hi patrik,

I am not good at PID theory too.

But as far as I know when you accumulate differantial error it becomes something else. Because differantial error
shows how quickly the system recovers the error and behaves like a brake.
I have lested with following line...

Code: Select all

line 1527 naverrorD = ((dif - oldif) *navPID_PARAM.kD) * gpsFreq;

And gpsFreq, you are using 2Hz, Unless if you dont do it onpurpose, we should use higher, if you have higher rate GPS.
(for example I have UBlox 5Hz)

I know, Tuning PID controller without a proper logging is very difficult task ( for example naverror, integral error, differantial error )

For the elevator roll compensation, As I read from the code negative GPS_angle[PITCH] means climb, positive GPS_angle[PITCH] means dive,
So I will remove the line 1478, because it produces a dive command ( But I have not tested removing it yet )

Code: Select all

line 1478  GPS_angle[PITCH]+=(abs(att.angle[ROLL]) * ELEVATORCOMPENSATION /100);

Aydin

rbirdie001 · Post by **rbirdie001** » Wed Nov 13, 2013 11:57 pm

Hi,
I'm trying to follow your discussion but don't feel like having enough knowledge to join it. Because I see it's going close to altitude control which I'm still fighting with, maybe at least my observations could help you:
I tested FW_nav_131024 with commented out all additional conditions for altitude control except of altitude itself so this part of GPS.cpp was commented out:

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 >SAFE_DECSCEND_ZONE){ GPS_angle[PITCH]=0 ;} // RTH Nav Stage Use only ACC to maintain altitude
          else { rcData[THROTTLE]= IDLE_THROTTLE;}                           // RTH Descend only when within 100 meters
          if( f.FAILSAFE_RTH_ENABLE){
            if (GPS_distanceToHome <20  && GPS_AltErr <=5 ){f.ARMED = 0;}    // Home is within 20 meters DISARM and glide.
          }
        } */

I catched good weather and tested on flying field big enough to give me freedom in testing.
I set SAFE ALTITUDE to 90 m :!:

and P coeficient for Alt control to 9 (because previously it looked that with smaller values Alt control didn't work at all but with last "for me working version" FW_Nav_130322 I could use only P=3 because higher values vere causing "jumping" and "wing breaking" effect

http://www.youtube.com/watch?v=Ss67va4QxMk&
Result was that altitude control some way works for me at 131024 but very strange and not very good. After activating RTH plane started diving, then quite low (I guess at 20-30m) it got "kicked" by some control and started climb but was so teribly wobbling in PITCH, that if it wouldn't be my extra reinforced flying wing, it would break it's wing. After few circles it some way stabilized altitude and was circling around, but often was badly wobbling in PITCH.
I have implemented these two lines to reduce wobbles, but my wobles were obviously on PITCH axis (not on ROLL):

Code: Select all

      if (GPS_distanceToHome <=10) dif=0;  // fly straight over home
// Wrap Heading 180
      if (dif <= - 180) dif += 360; 
      if (dif >= + 180) dif -= 360;
            if abs(dif > 160) dif = 160; // To resole wobbles turn left. Man's mind :)

IN normal GYRO or ACC mode is the plane stable and not wobbling even at high speed so it looks like wobbles are coming from navigation input.
I have UBLOX NEO 6M 5Hz GPS.
Any further improvement on Alt control would be great, maybe also introducing I term can allow to lower P term which can help reduce wobbles but keep reasonable altitude control.
I took yesterday some videos of that tests (from a hat camera

) so if some of behaviour is visible there (not seen yet), I'll definitely post it for you to see what I'm trying to describe.
Thanks for your effort boys!
Regards
Roman

aydineser · Post by **aydineser** » Thu Nov 14, 2013 10:30 am

Hi Roman,

I am using GPS_ALTCORR=3 and its quite sucessfull.
But there is another problem, when you used automatic control booth on throttle and elevator.
In some conditions, for example RTH against wind, your plane gain altitude rapidly, then autopilot reduce throttle ( even use IDDLE THROTTLE )
while commanding elevator down. As a result your plane slows down ( even stops in high winds ) When you are near stall speed, you can not expect
perfect command from the autopilot.

I am using manual throttle (with a switch) when necessary against the wind, It is the quick and dirty solution. But it works.
You can test with P=3 and manual throttle. Higher P value is not the solution. If your plane has speed, altitude control works well.

My plane has returned from a 9km flight while controlling altitude in max 10-15 meter error. - without manual throttle it can be much better, but it may never come home

Regards
Aydin

PatrikE · Post by **PatrikE** » Thu Nov 14, 2013 10:48 am

Hi Aydin,

You're right about elevator compensation.
If i remember correct i added it because i lost some altitude in turns.
Tested it and it became worse and couldn't understand why.(probably added the dive code)
Forgot about it and tested after a while and added it a second time correct this time.
problem solved (but forgot the first fix)!

I set 2 HZ to get bigger diff between readings.
I use a 10hz gps and don't see the need of that high update on a plane.
First i did run the code every loop.(even in FW_Nav_130322 )
Feel free to experiment.

One thing is for certain...
You become blind when staring at the code for a while!
Obvious errors become invisible.

Keep testing while weather allow.
/Patrik

PatrikE · Post by **PatrikE** » Thu Nov 14, 2013 11:15 am

@Roman

The autopilot is working as long as it possibly can to balance the plane.
But as Aydin say if the plane slows down to much the only way it goes is.... Down

Test to increase IDLE_THROTTLE.
Because together with a high SCALER_THROTTLE throttle can decr very fast.
It calculates ( Alt_error * SCALER_THROTTLE ).
Maybe you shouldn't fly slower than CRUICETHROTTLE

And since we don't check actual speed it can be potential problems.

I have also made a mod on the Mixtable for flyingWing.
To keep symmetric controls at full commands.

Code: Select all

   #define ROLLRATE 0.5
   #define PITCHRATE 0.5
    if (f.PASSTHRU_MODE) {    // do not use sensors for correction, simple 2 channel mixing
      servo[3] = (SERVODIR(3,1) * rcCommand[PITCH])*PITCHRATE + (SERVODIR(3,2) * rcCommand[ROLL])*ROLLRATE;
      servo[4] = (SERVODIR(4,1) * rcCommand[PITCH])*PITCHRATE + (SERVODIR(4,2) * rcCommand[ROLL])*ROLLRATE;
    } else {                  // use sensors to correct (gyro only or gyro+acc according to aux1/aux2 configuration
      servo[3] = (SERVODIR(3,1) * axisPID[PITCH])*PITCHRATE   + (SERVODIR(3,2) * axisPID[ROLL])*ROLLRATE;
      servo[4] = (SERVODIR(4,1) * axisPID[PITCH])*PITCHRATE   + (SERVODIR(4,2) * axisPID[ROLL])*ROLLRATE;
    }

rbirdie001 · Post by **rbirdie001** » Fri Nov 15, 2013 12:48 am

Hi guys,
thanks for so many ideas to think about!
I currently have little time for that because I have to complete some Iceland photos for Saturday presentation to friends, but then I'll read all again, study the video I took during last RTH test flight and hopefuly there will be visible some of strange behaviour I'm describing.
Just to clarify - I have set P for elevator to 9 (I did it because with smaller values was my plane circling lower and lower until I had to manually pull elevator just 2-3 meters above the ground). :shock:

SCALER_THROTTLE is 8. I have generaly quite strong thrust so stall isn't real problem, my plane flies quite fast (I set it higher exactly because of returning against the wind). Problem is kind of "flutter" which I also call "wobble" or "jumping" in some my posts. Generally it's the same - both elevons make big "wawes" up and down in approx 1 Hz period and because the plane have quite high speed, it causes big stress to wings which normal plane wouldn't survive.
It happens mostly close to home position and obviously comes from navigation code. Because I have aplied some measures to limit wobbles from "GPS heading chaos" close to home (see my previous post) and also I see, that wobles are pure in PITCH, not in ROLL, I gues it has to come from something else - probably altitude control loop. Generally I observed it always from the first versions I tested (FW_Nav_130322), now, after I replaced GPS from 10Hz Mediatek to 5Hz Ublox, oscillations seems to be faster. (But Ublox GPS have in reality faster altitude response than MTK). This also points to altitude control from GPS data.
Additional info: I have #define GPS_LEAD_FILTER, but commented out //#define GPS_FILTERING. Is it OK?
See you later!
Roman

rbirdie001 · Post by **rbirdie001** » Thu Nov 21, 2013 12:19 am

HI!
I watched videos I made using "head camera" during my last RTH tests and unfortunately I have to admit, that there is not much to see to show you my problems. Because I really want to make RTH working for me, I'm again reading the code, will try to do some changes and then do new tests (when weather allows). One sunny day I should win over it!

In the code I don't understand well some things. Patrik, can you please give me some info about it? (Do you know the advice, that to find mistake in your theory you should explain it to your cleaning lady?

)

So here are lines in FW_nav_131024 GPS.cpp, where I'm in doubts:
line 1471

Code: Select all

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

GPS_altitude should be absolute over the sea level, so is the GPS_hold[ALT] also over the sea level? Where and how it's calculated?
I suppose it from the line 1475, where is the GPS_altitude used like if it's "over MSL".

Code: Select all

int16_t curr_Gps_Alt = GPS_home[ALT] - GPS_altitude;              // Calculate Altitude over home

Edit: Found, it's in MultiWii.cpp, line 1057, understood, looks OK.

line 1478

Code: Select all

GPS_angle[PITCH]+=(abs(att.angle[ROLL]) * ELEVATORCOMPENSATION /100); // Compensate elevator compared with rollAngle

I think, that this line is the wrong one (as previously discussed). It has wrong polarity and position (adding positive value pushes elevator down and all following corrections can affect it's influence) while similar line at the end (around 1550) is the right one (adding negative value pulls elevator up and it has always the same effect because it's behind all other corrections). I'll remove first line and keep second, OK?

Line 1488

Code: Select all

 if(GPS_AltErr < 0 && f.CLIMBOUT_FW && f.GPS_HOME_MODE ){ ...

Is the flag f.CLIMBOUT_FW set to 1 always, if we get lower than safe alt, or only at the time of RTH activation and then never more while RTH remains active?

Thank you in advance! I want to do all possible corrections in the code and load it by this weekend just for the case there would be good weather at the weekend...

BTW: I got my Orange Open LRS TX+RX, loaded kha's firmware, set everything and it seems to work really great. This should allow me to fly to bigger distances than before so RTH functionality would be REALLY usuefull! :mrgreen:

See you!
Best reagards
Roman

PatrikE · Post by **PatrikE** » Fri Nov 22, 2013 3:50 pm

Hi Roman,

The flag f.CLIMBOUT_FW is set only when RTH is enabled.

I uploaded a new ver with all changes discussed in the thread fixed.
Tested and works fine on my plane.
-5 degrees and sunny today.. 8-)

Used P3 for Alt
and P2 : I=0.08 : D=0.045 for NavR

This is the changes i make in my config.

Code: Select all

// Settings for Fixedwing_RTH
#define AIRPLANE

#define GPS_PROMINI_SERIAL
#define GPS_BAUD   115200
#define NMEA

#define SERIAL_SUM_PPM         ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11

#define MINTHROTTLE 1000
#define MAXTHROTTLE 2000

#define NO_FLASH_CHECK

// Make rearming in air possible/easier
#undef ONLYARMWHENFLAT
#define DONT_RESET_HOME_AT_ARM

#define MAG_DECLINATION  3.6f

The Nav Pids is not god Tuned because the plane can't really Get on course.
It's almost there But turns back before it's on course for a while.(I & D tuning!)

I also added a deadspan on +/- 1m on altitude!
should remove "flutter" on elevator.

I'll be working all weekend so no more flying for me

https://multiwii.googlecode.com/svn/bra ... 131122.rar

Greetings.
/PatrikE

rbirdie001 · Post by **rbirdie001** » Sat Nov 23, 2013 12:34 am

Hi Patrik,
I see there are many news in the code so I hope NOW it will start working also for me. :lol:

I made minimal necessary changes only and loaded into my wing. Tomorrow should be reasonable weather, so...

Have as good working weekend as possible!
Roman

rbirdie001 · Post by **rbirdie001** » Sun Nov 24, 2013 9:28 pm

Hi Patrik,
I hope you had peaceful weekend at work and all robots behaved well

.
I tried to test new version FW_Nav_131122 but as I had several complications, so not much results

.
I loaded it and firstly connected bluetooth module to the promini serial port. I did adjustment and servo trimming, test flight - that went OK. Then I plugged GPS into the promini serial, let GPS fix and wanted (as always) to save home by stick gesture but this didn't work :?:

. I was trying it several times, reboot, different switch position, arm/disarm (that was normally possible), lower/increase THRO trim... but no gyro and acc calibration activation when PITCH and YAW at minimum. As it was quite windy and cold, I spent some 10 minutes with it and gave up...
I tried to activate RTH anyway and autothrottle started the motor so RTH was really active (home was probably saved when GPS got fix) but I didn't rely much to this "home" because altitude info from GPS could be quite inacurate at the time. Altitude control anyway didn't seem working well but there was too many abnormal conditions to take it seriously (unsure home and strong wind).
When I got back home into warm room, gyro calibration worked always - without GPS fix and with GPS fix as well so I don't understand what was before wrong.
I decided to use next time I2C GPS instead of promini serial because this will allow me to keep GUI connected and don't be so "blind". I have only BT module with range of ~10m. In worst case I should be able to run up and down hill with plane in one hand and notebook in the other but at least "see" inside MWI

Because 131122 still not compile with I2C GPS setting, I'll use this patch: viewtopic.php?f=7&t=2456&start=330#p42557 ,with this it compiles OK.
I'll keep posting about my progress but also here is weather going worse and worse (at least for flying

) so it may take longer.
Regards
Roman

rbirdie001 · Post by **rbirdie001** » Tue Nov 26, 2013 10:54 pm

Can anything ever work for me straightforward without days and weeks troubleshooting?
I prepared new I2C GPS board, modified FW_Nav_131122 config accordingly, uploaded, connected and it communicates but I have 31 I2C errors from the beginning. I aplied this patch: viewtopic.php?f=8&t=4246&start=30#p43393, which helped me in standard 2.3, but it doesn't help in FW_Nav_131122 - I'm still have I2C errors from the beginning. It will probably work anyway, but is anyone sees the solution, it would be better not to have I2C errors...

Roman

PatrikE · Post by **PatrikE** » Wed Dec 25, 2013 11:24 am

With help from rbirdie001 with debugging and testing.
We have made progress with the code.

It's now ready to be tested .
https://multiwii.googlecode.com/svn/bra ... 131225.rar
Use Gui from V2.3

I added a textfile with recommendations in the Rar file.

The code uses
Gyro/Acc + Gps ( Mandatory )
If MAG is present it will be used to.
Baro is not used for navigation.

Reset from Gui when you have uploaded the code first time.
Setup servos from Gui.

Set desired altitude to return to with ALT_D in Gui (50 meters default)

Get out and fly.
But look out if Santa's flying low

Happy hollidays

i3dm · Post by **i3dm** » Wed Dec 25, 2013 11:15 pm

is this now a stable version for plane flying with RTH for Multiwii?

PatrikE · Post by **PatrikE** » Thu Dec 26, 2013 5:00 pm

i3dm wrote:is this now a stable version for plane flying with RTH for Multiwii?

I can verify that it works on my plane.
It's safe to fly this version.

It just needs more flight testing and PID tuning.
All navigation stages for RTH works.

A Preflight check is important for Gps navigation!

Make sure You have GPS Lock.
Home position is reset when calibrating gyros.(Not reset at Arming)
Always calibrate gyros (Use stick command)
or reboot FC before takeoff!

Check gps lock
Activate RTH on ground.
Elevator will go up to reach RTH alt if home is set.
Motor will Run at climbThrottle value and not idle when throttle is applied.

Stages of RTH
#1
Set RTH altitude.
If plane is higher use current altitude.

#2
Start a Climbout in 2 stages if plane is to low.
-1: Below 20 meters Full climb with level wings.
-2: Below RTH-Alt Full climb but also start navigation.

#3
Navigate to home maintain altitude.

#4
Descend to the altitude set in Gui with ALT_D
And keep returning to home position until battery run flat or RTH is aborted.

If Failsafe is active.
Motor is disarmed after 1:st pass over home position. (or FAILSAFE_OFF_DELAY times out. Set high for longdistance)
And return altitude will be changed to Home altitude.
In next ver FAILSAFE_OFF_DELAY will be overridden by Fixedwing

I hope for some test reports.
/Patrik

Chriss · Post by **Chriss** » Mon Dec 30, 2013 7:23 pm

Hi Patrik,

I have flashed new firmware to my Crius SE V2.5 in my Bixler2. Connect to GUI works fine, also the settings for switches and so on. I have only issues with servo settings. I cant save the settings (reversing) to my board. If I press "Read" (after "Save") its shows me the default settings!

FW: 131225
GUI: latest (2.3)

Any solutions?
Best wishes from Germany,
Chriss

P.S.: also BT connection fails with Android and GUI, connection is good, but in Android it shows me "no data received" and GUI dont show real data, only that the board is connected...

EDIT: use MW GUI 2.3pre4 and everythings work fine!

I will give a feedback, if I was in the air!

msev · Post by **msev** » Thu Jan 09, 2014 9:00 pm

Btw are V-tail planes supported? Either vtail+dihedral wing or vtail+wing with ailerons.

Ubx protocol is supported right? (i just define it in config.h), since the notes mentions something about nmea.

i got a spare arduino mega and mpu6050&hmc5883 so I could maybe try it once i finish my testing platform.

Another thing for what is the magnetometer used? Maybe heading hold?

PatrikE · Post by **PatrikE** » Thu Jan 09, 2014 11:01 pm

Hi msev.
You can use a Vtail plane as Ailerion/Elevator.
Vtail mix with ruddercontroll is NOT available.
It needs a specialmixtable.

Mag is used to get the heading of the plane and is optional.
RTH works just as fine with a mpu6050 & GPS.

This is the latest dev.
MultiWii_140109.rar

Dev is in sync with repository.
Every units in MWii is included in this dev.

rudyauction509 · Post by **rudyauction509** » Sat Jan 11, 2014 11:40 am

Not wanting to read 30 pages and a search of the thread for "download" doesn't show anything the past few months, where do I get the code? Also will this combo from hobbyking work with it? http://www.hobbyking.com/hobbyking/stor ... odule.html

I'm looking for a backup RTH for my bixler 2 short/mid range (max 2-3 mile) FPV plane so if I go out of range it will turn around and fly back into range. I don't want to put $100+ into an RTH if this will work. Also I don't care if it lands in the field or maintains an exact altitude or anything, just that it keeps above the trees and flies in the general direction of the field until I can regain control.

PatrikE · Post by **PatrikE** » Sat Jan 11, 2014 6:09 pm

Here's a link to the latest version.
MultiWii_140109.rar

The Pinout on this FC is not optimal for airplanes.
Some pin's aren't available.
But with some trix it can be fixed.

The code should suit your needs just fine.
RTH can be used as a flightmode activated by switch and FailsafeRTH.

FailsafeRTH will fly the plane home and "Land" at home.

Chriss · Post by **Chriss** » Sun Jan 12, 2014 6:30 pm

Hi Patrik,

I will give you a feedback with my Bixler2 and your RTH MultiWii Code!

I don't change the defaults PID's and with that it works very well!

Stabilize and RTH works very well!

Thank you very much for that piece of Software!

But I have a issue: if I connect the LiPo and the plane is not leveled, it seems it save this level. Is this right? I thought, I can level with GUI and don't level before each flight.

What changes you make in 140109? I have testet 131225.

Best wishes from Germany!
Chriss

PatrikE · Post by **PatrikE** » Mon Jan 13, 2014 7:43 am

Hi,
Good to hear it works.

Changes made since 1225.
Several overflow identified and corrected.
PID regulator. (still needs tuning)
Fully functional FailsafeRTH.

The weather have been flyable.
Help from rbirdie001 with debugging.

The only thing i can think of that affects Boot i've made is in def.h
Row 238 : #undef ONLYARMWHENFLAT.
Test to remove it.

It's there for making ReArm in air easier.

msev · Post by **msev** » Tue Jan 14, 2014 6:21 pm

PatrikE wrote:Hi msev.
You can use a Vtail plane as Ailerion/Elevator.
Vtail mix with ruddercontroll is NOT available.
It needs a specialmixtable.

Mag is used to get the heading of the plane and is optional.
RTH works just as fine with a mpu6050 & GPS.

Hi Patrik, do you have ez* with rudder+elevator+ailerons or without the ailerons? Option with rudder+elevator+dihedral wing(self stabilizing) would also work?

Any plans for vtail support, since that vtail looks sooo nice on a plane hehe

?

So mag "heading hold" mode does not work? It is used just to feed MSP for osd/telemetry? Or is it used also in the navigation routines if one has it defined?

It would be interesting to step by step implement features from your branch into baseflight, for example this was the latest commit regarding alt.hold: https://github.com/multiwii/baseflight/ ... 18f0a18f02

If you could provide some insights on how you do it here, I could relay the info to timecop on irc

, so this mode would work as good as yours. Then later maybe you could help implement some more stuff if possible (my dream would be aeroplane PH&RTH also on baseflight)...Think about it a 20$ acronaze+gps could be all what is needed, same price point like today arduino mega+mpu6050 but much smaller size

ankimo · Post by **ankimo** » Fri Jan 17, 2014 6:32 am

Hi

131225 did very good work.
https://www.youtube.com/watch?v=YWtXWg3MrmU

I try 140109 this weekend.

Thank you
Kazz

crashlander · Post by **crashlander** » Fri Jan 17, 2014 1:02 pm

Yesterday I did successful test of 140109.
I have not done any real PID tuning due to strong wind but basic RTH works and the plane returns with or in wind.
Only observation I have is the fact that plane does not actively maintain height, since my plane is trimmed slightly up it gains height during RTH stage and it seems navigation does not try to compensate that.?
But like I said I did only limited (one pack) testing.

Regards
Andrej

crashlander · Post by **crashlander** » Sun Jan 19, 2014 12:37 pm

@PatrikE one additional idea!
During testing I also noticed that during RTH when turning from in-wind flying to down-wind (from low ground speed) plane massively overshoots proper heading (90 deg.).
My suggestion is to use only compass for heading correction when heading is more than eg. 90 deg. off or when ground speed is low eg. less than 20km/h and to use GPS only heading when speed is high or correction is minimal, since that second aproach is good to overcome side-winds.

Best Regards
Andrej

PatrikE · Post by **PatrikE** » Sun Jan 19, 2014 3:37 pm

I have been thinking of something like this.

Code: Select all

if(abs(Current_Heading -(GPS_ground_course/10))>10 && GPS_speed >700) // GPS and MAG heading diff.
{
  Current_Heading = GPS_ground_course/10;
}else
{
  Current_Heading = att.heading;
}

Comparing Current_Heading & GPS_ground_course can detect sideWind.
In low speed you only want to use MAG because GPS_ground_course becomes unpredictable.

Opinions?

/P

crashlander · Post by **crashlander** » Mon Jan 20, 2014 9:52 am

PatrikE wrote:I have been thinking of something like this.
...
Comparing Current_Heading & GPS_ground_course can detect sideWind.
In low speed you only want to use MAG because GPS_ground_course becomes unpredictable.
...
/P

Hello,
that is what I had in mind.
I'll update my code and test when time/weather permits.

Regards
Andrej

P.S. Does this seems O.K.?
https://code.google.com/p/crashlander-m ... .cpp&old=8

PatrikE · Post by **PatrikE** » Mon Jan 20, 2014 8:00 pm

crashlander wrote:P.S. Does this seems O.K.?

It looks OK

In a more compact format.

Code: Select all

     #if MAG
        if (!f.SMALL_ANGLES_25) 
          if(abs(Current_Heading -(GPS_ground_course/10))>10 && GPS_speed >700) // GPS and MAG heading diff.
          {Current_Heading = GPS_ground_course/10;}else{Current_Heading = att.heading;}
      #else
        Current_Heading =GPS_ground_course/10 ;
      #endif

You might increase the allowed error from 10 deg.

/Patrik

crashlander · Post by **crashlander** » Tue Jan 21, 2014 8:29 am

What bothers me is if not SMALL_ANGLES_25

Code: Select all

 if (!f.SMALL_ANGLES_25)

Since that means that when returning home (last leg of return) plane will normally take nose towards home heading and in stronger side wind it will fly on so called dog curve (http://commons.wikimedia.org/wiki/File:Dog_curve.svg), since corrections will be small, that can be far from optimal.

Thoughts on that!

Regards
Andrej

PatrikE · Post by **PatrikE** » Tue Jan 21, 2014 9:45 am

if (!f.SMALL_ANGLES_25)

Is direct copied from MagHold routine.
It's there because Mag was showing incorrect heading if mag is tilted >25 degrees earlier.
I think this is fixed now.

Code: Select all

 if(abs(Current_Heading -(GPS_ground_course/10))>10)

Will detect ig Mag flips out and makes SMALL_ANGLES_25 unnecessary.

Patrik

adilson · Post by **adilson** » Fri Jan 31, 2014 12:09 am

Hello everyone

I would like to give this a try using a Crius AIO Pro V1. I've compiled and uploaded the latest svn code and it compiles fine with exception the need to ad a "const" before the ublox GPS initialization code.
Anyway, the thing is, the multwii gui does not show the action of the sensors, for instance, I don't see any changes on the artificial horizon or the airplane profile.
Any thoughts?
Thanks in advance

crashlander · Post by **crashlander** » Fri Jan 31, 2014 8:33 am

adilson wrote:Hello everyone
I would like to give this a try using a Crius AIO Pro V1. ...
Anyway, the thing is, the multwii gui does not show the action of the sensors, for instance, I don't see any changes on the artificial horizon or the airplane profile.

Hello,
it works for me without modifications on same HW!

Regards
Andrej

BTW: That is my config.h
https://code.google.com/p/crashlander-m ... D/config.h

PatrikE · Post by **PatrikE** » Sat Feb 01, 2014 11:14 am

Test to Clear Eeprom with Arduino sketch.

ankimo · Post by **ankimo** » Mon Feb 03, 2014 3:30 am

Hi

140109 was tried.
It seems that the distance to home of OSD is wrong as compared with 131225.

My test environment
i2c_GPS:I2C GPS NAV V2.2 Beta1 (R62)mod
OSD:KV_Team_OSD_2.2_20131221

Thank you

PatrikE · Post by **PatrikE** » Tue Feb 04, 2014 11:58 am

Hi.

New update of the code.
Fixed Distance home.
Fixes Max 655m issue.
You need to use the patched I2C_GPS code included in the Rar file.
FW_Nav_140204.rar

Reset settings from Gui or run Eeprom clear scetch.

Read GpsPlane setup.txt

Happy flying..

Patrik

moti0072 · Post by **moti0072** » Sun Feb 09, 2014 10:43 am

Hi,
this fw work wth hk multiwii pro ?
i want to test it on my bixler

http://www.hobbyking.com/hobbyking/stor ... odule.html

thanks for answer
Moti

PatrikE · Post by **PatrikE** » Sun Feb 09, 2014 9:53 pm

It will work But a small Mod to move a servo pin is needed.
I will add it to next release.

moti0072 · Post by **moti0072** » Mon Feb 10, 2014 9:58 pm

PatrikE wrote:It will work But a small Mod to move a servo pin is needed.
I will add it to next release.

Ok ...

moti0072 · Post by **moti0072** » Thu Feb 13, 2014 8:44 pm

PatrikE wrote:It will work But a small Mod to move a servo pin is needed.
I will add it to next release.

Any news?

PatrikE · Post by **PatrikE** » Fri Feb 14, 2014 7:02 pm

New update witch should work on Mega boards
[url?https://multiwii.googlecode.com/svn/branches/PatrikE/FixedWingNav_Dev/FW_Nav_140214.rar]FW_Nav_140214.rar[/url]

Servo order is.
Wing1 D7 & D37
Wing2 D6
Rudd D2
Eleva D5
ESC D3

moti0072 · Post by **moti0072** » Mon Feb 17, 2014 4:45 pm

PatrikE wrote:New update witch should work on Mega boards
[url?https://multiwii.googlecode.com/svn/branches/PatrikE/FixedWingNav_Dev/FW_Nav_140214.rar]FW_Nav_140214.rar[/url]

Servo order is.
Wing1 D7 & D37
Wing2 D6
Rudd D2
Eleva D5
ESC D3

Thanks i go to test it

moti0072 · Post by **moti0072** » Tue Feb 18, 2014 7:48 am

Hi PatrikE
i go to use this line its ok?

//#define SENSORS_TILT_45DEG_RIGHT
+
for my board
//#define FFIMUv2