Airplane mode

PatrikE · Post by **PatrikE** » Mon Mar 31, 2014 10:42 pm

Atm...
Don't throttle back fully during RTH!
I will limit the Elevator when motors is stopped to prevent stall in next release.

PatrikE · Post by **PatrikE** » Mon Mar 31, 2014 11:01 pm

Magik30 wrote:Hi
I have a twin engines electric , model superhero, no rudder, just wing elevon mixer.
I'd like to do with differential engine to turn right or left.
just use the gas, and the differential yaw
I have a CRIUS SE.
it is posible?
Code exists?

No code exists and need a special mixtable.
Just need add a extra motor to FlyingWing.
Not impossible to fix.

Plüschi · Post by **Plüschi** » Tue Apr 01, 2014 12:05 pm

Questions (noob to airplane mode):

Is there a easy-read list of changes done in PatrikE airplane?

The gps velocity in my test setup, using navisim as gps emulator, is very jumpy. I did have to smooth that velocity vector to get decent results. Is a real gps velocity also jumpy or is that smooth?

My planes need aile and rudder to turn nicely. Is there some sort of rudder-aile mixing in the code and where ?

A plane only needs "direction to home" coupled to rudder to do basic RTH. Right?

I have a mag-less "gyro - gps" sensor fusion. Basically this relies on gyro for North direction, and uses gps direction to compensate for drift. This makes direction lag-free and accurate, and also doesent mind gps dropouts or standstills for some time. Intrested?

Edit: What i found today:

The ParickE "beef" is in gps.c, provc FW_NAV().
The calculated corrections are fed into GPS_angle[] which is then used in the main pid loop.
Altitude corrections go into pitch and throttle, while direction goes into yaw and roll.

Overall this looks very good

shikra · Post by **shikra** » Tue Apr 01, 2014 12:52 pm

Yeah - I'm kinda interested too in a bit of an overview.

i3dm · Post by **i3dm** » Tue Apr 01, 2014 10:18 pm

PatrikE wrote:Atm...
Don't throttle back fully during RTH!
I will limit the Elevator when motors is stopped to prevent stall in next release.

i thought multiwii controlled the throttle during RTH?

PatrikE · Post by **PatrikE** » Wed Apr 02, 2014 8:11 am

@ Plüschi
It's a good summary of the function.

I just compare Ground Heading with direction to target and use to compensate Roll/Yaw.
Altitude from Gps is used to control elevator.
Throttle is mainly controlled depending on Altitude errors and Attack angle.

PatrikE · Post by **PatrikE** » Wed Apr 02, 2014 8:23 am

@i3dm

#define MOTORSTOP.
Will stop motor if throttle all way back. (Even in RTH)
It's a nice safety feature when handling and Preflight checking the plane on ground.
If you enable RTH on ground the motor will start at almost full throttle to start climbout.

Failsafe will override MOTORSTOP.

Plüschi · Post by **Plüschi** » Fri Apr 04, 2014 2:31 am

Simulation of (what i think) PatrikE does when plane reaches home point (P factor is limiting):

If i hard limit the banking angle i get this:

A tangential approach to the circle with hard limited banking angle:

A nicer approach is to start tangential mode only when distance_to_home is less than 3*circle_radius:

Processing source including tangential approach code is attached.

Plüschi · Post by **Plüschi** » Sun Apr 06, 2014 5:08 am

Making it better:
For the promicro ( $19 nanowii ) i wonder why not use the A32U4_4_HW_PWM_SERVOS define. You just have to skip around the "not a helicopter" warning messege and it works. Its ALL hardware PWM with #define A32U4_4_HW_PWM_SERVOS. Pins are changed, 9 elev, 10 aile1, 5 yaw, 6 thro, 11 aile2. Hardware PWM means no jitter and no problems, better resolution and stability.

One upping the thing:
By not using aile2 and mapping yaw to pin11 instead of pin5 then pin 13 can then be used as ICP input for timer3. This would mean ppm-sum signal goes to pin13 and ppmsum would become hi-res and jitter-free hardware timed input. But its lots of work.

felixrising · Post by **felixrising** » Sun Apr 06, 2014 6:13 am

Anyone want to port this to baseflight?

serpa4 · Post by **serpa4** » Tue Apr 08, 2014 4:04 am

Good day all.
I have two flight boards of which I know nothing about.
1) MWC MultiWii Lite Lightweight Version 4 Axis Flight Control Board. http://www.myrcmart.com/mwc-multiwii-lite-lightweight-version-axis-flight-control-board-p-6204.html

and this

2) MWC MultiWii SE V3.0 Flight Control Board Standard Edition Mini Aircraft Compatible. http://www.myrcmart.com/product_info.php?products_id=6815

I need to stabilize a flying wing that is difficult to lauch and nothing else. Which board is best (SEv3 I'm pretty sure)? Where can I learn how to load the correct software and make it fly a wing? I bought a hex copter and it came as an extra part. Now I need it for a wing (if it can do it).

I know nothing about programing it. However, I use an AMP board in my quad and the GUI makes it easy to pick what I fly and just check little boxes and it does the rest. Is the SEv3 have a similar GUI for airplanes?

If anyone can point me in the right direction, I'll read up and learn.

simply · Post by **simply** » Tue May 06, 2014 9:32 am

I've an issue I've seen in both 2.2 and 2.3 in Airplane mode, and I kind of hope I've just missed something...

In Passthrough, with all sticks centered, no trim and plane level on table, servo outputs are centered, verified with GUI (output 1500)

But as soon as I switch from Passthrough to Stable mode, servo outputs for Ailerons (Wing1,Wing2) change about 20-50us.
Sticks still centered and plane level, ie nothing moved.

Has anyone else experienced this phenomenon, know what causes it, has a solution?

Thanks in advance!
//

PatrikE · Post by **PatrikE** » Tue May 06, 2014 12:10 pm

It's just PID regulator adding sensor compensation.
Nothing to worry about.
Just make sure it's centered in Passthru.

simply · Post by **simply** » Tue May 06, 2014 1:52 pm

PatrikE wrote:It's just PID regulator adding sensor compensation.
Nothing to worry about.
Just make sure it's centered in Passthru.

OK, but why compensate for practically nothing? Or will it not happen when IRL when flying?

It _looks_ bad, especially on a small funfighter that have very small span between full up/down aileron, around +/- 200us around MID :S

//

PatrikE · Post by **PatrikE** » Tue May 06, 2014 6:12 pm

With "Stable mode" do you mean Acro or Horizon/Angle?
If its Horizon/Angle the plane will compensate if its tilted in any direction.

All the tiny error calculations adding up.
MWii is trying to compensate and nothing happens because the plane is static on the table.
Everything will even out when the plane is in motion.

Start in passthru and when you are comfortable switch to Acro.
Horizon or Angle is next step.

You can start with Half P value for Gyro (1.5) first test.

simply · Post by **simply** » Wed May 07, 2014 5:54 pm

PatrikE wrote:With "Stable mode" do you mean Acro or Horizon/Angle?
If its Horizon/Angle the plane will compensate if its tilted in any direction.

Sorry, with Stable I mean Acro, gyro only. And the plane is not tilted and it's calibrated in this position, not moved after calibration. All sensors in GUI flatlined...

PatrikE wrote:All the tiny error calculations adding up.
MWii is trying to compensate and nothing happens because the plane is static on the table.
Everything will even out when the plane is in motion.

Yeah, but even if it's only around 20us, it's freakishly a lot of movement for this small aircraft - On my Bixler it's hardly noticeable

oh well, will try and see what happens...

Thanks!

//

zinets · Post by **zinets** » Sun Jun 22, 2014 12:18 pm

hi

i (again) have one stupid question

crius se v2 board, bixler, no gps; mwii 2.3 without any changes (my expiriens with mwii - qcopter(s), plane & flying wing)

this time if i switch to angle/horizont mode, controller make throtle 90-100%! Why? is there any define in config.h for it?

baro and/or magnetometer can affect motor's behavior?

PatrikE · Post by **PatrikE** » Sun Jun 22, 2014 1:41 pm

For planes BaroMode will control throttle Not Elevator
It's meant for copter use where throttle is used for controlling altitude.
It's a little wrong approach for planes...

Otherwise i don't think throttle should be controlled in V2.3.
You can test to clear Eeprom.
Is all servo/Esc on correct pins?

Start with only your FC + Airplane & receiver.

You can test the Fixed wing Nav branch instead.
FW_Nav_1140402.zip
It will work just as good without GPS attached.
And it have improved failsafe for planes.
Don't forget to enable #define FAILSAFE
Without GPS It will set the plane in a turn instead of flying off with level wings.
With Gps it will do return to home.

Patrik

Jarzas · Post by **Jarzas** » Fri Jun 27, 2014 5:01 pm

Hi

I have a Promini board and I want to use pin12 to AUX2 (Promini settings #define RCAUXPIN12).
With copter the AUX2 is working ok and follow pin12,
but with aeroplane the AUX2 follows ROLL channel and pin12 don't do anything.
This happen with mw2.3 , with older mw2.2 version it's works correctly.

Any idea?

Plüschi · Post by **Plüschi** » Sat Jul 19, 2014 3:52 pm

I have a nanowii board from HK. The $19 one. Very small and light with dsmx sat. Does patrike code run on this with hardware pwm servo?
IS there a 328 / 32u4 plane fork yet?

I intend to add a GPS but not with a heavy patch antenna, i want a wire / leaf ant. Anyone experience with that?

The whole thing should go on my slowstick, this

captaingeek · Post by **captaingeek** » Sat Jul 19, 2014 4:32 pm

any recommendations on using this for a flying wing? IE only 2 servos?

theailer · Post by **theailer** » Thu Jul 24, 2014 2:11 pm

captaingeek wrote:any recommendations on using this for a flying wing? IE only 2 servos?

It's pretty straight forward. Just type mixer flying_wing in cli to enable it.

Joseph97 · Post by **Joseph97** » Tue Jul 29, 2014 2:31 am

Plüschi wrote:I intend to add a GPS but not with a heavy patch antenna

Maybe try this: http://www.rcgroups.com/forums/showthread.php?t=2012386. I'm using it with great success with PatrikE code on a 4 ounce foamie. Or it should be possible to replace the heavy patch on a regular GPS with your own version of this antenna at very low cost.

rubadub · Post by **rubadub** » Tue Sep 02, 2014 10:40 am

PatrikE wrote:For planes BaroMode will control throttle Not Elevator
It's meant for copter use where throttle is used for controlling altitude.
It's a little wrong approach for planes...

Otherwise i don't think throttle should be controlled in V2.3.
You can test to clear Eeprom.
Is all servo/Esc on correct pins?

Start with only your FC + Airplane & receiver.

You can test the Fixed wing Nav branch instead.
FW_Nav_1140402.zip
It will work just as good without GPS attached.
And it have improved failsafe for planes.
Don't forget to enable #define FAILSAFE
Without GPS It will set the plane in a turn instead of flying off with level wings.
With Gps it will do return to home.

Patrik

new here.
I'm trying to setup Patrik's fixed wing code on a teksumo flying wing.
questions:
- I understand why the standard 'baro' mode is useless for the current fixed wing implementation, but why isn't the actual sensor value from the baro being used? For example, I took a look at the 'FW_NAV()' function in GPS.cpp. Based on the code in that function, the GPS altitude is being used for altitude corrections when in RTH mode. Wouldn't it make more sense to use the altitude calculated from the baro sensor? Can someone please explain why this is setup this way? I'd much rather trust my baro sensor for altitude readings than the GPS-calculated altitude (or at least would like to have the option to enable this).

PatrikE · Post by **PatrikE** » Tue Sep 02, 2014 11:54 am

The Idéa behind it is that it should work with a minimum of sensors.
And there can be problem if the Baro is affected by airspeed.
GPS altitude is good enough for RTH But not precision Navigation.
My plane rarely diff more than 2-3 meters in alt.'

In void FW_NAV() you can change it to use Baro.

Code: Select all

  // Calculated Altitude over home in meters
  //int16_t curr_Alt = GPS_altitude - GPS_home[ALT]; // GPS_Altitude
  int16_t curr_Alt = alt.EstAlt/100; // Test with BaroAltitude

GPS use Meters and Baro cm That's why it's divided by 100.

Patrik

rubadub · Post by **rubadub** » Wed Sep 03, 2014 1:24 am

PatrikE wrote:The Idéa behind it is that it should work with a minimum of sensors.
And there can be problem if the Baro is affected by airspeed.
GPS altitude is good enough for RTH But not precision Navigation.
My plane rarely diff more than 2-3 meters in alt.'

In void FW_NAV() you can change it to use Baro.
Code: Select all
  // Calculated Altitude over home in meters
  //int16_t curr_Alt = GPS_altitude - GPS_home[ALT]; // GPS_Altitude
  int16_t curr_Alt = alt.EstAlt/100; // Test with BaroAltitude
GPS use Meters and Baro cm That's why it's divided by 100.

Patrik

cool, thanks for the help Patrik.
Ok, I think I see your point about pressure vs airspeed; I'm assuming you mean because the airflow could cause a pressure drop? What if the baro sensor is foam-shielded?

Also, any ideas on how one might try to fuse the GPS and baro height, perhaps add some kind of complementary filter or something?

rubadub · Post by **rubadub** » Wed Sep 03, 2014 2:04 am

another issue that I'm finding is that ANGLE mode is enabled by default during testing (ANGLE box is green in MWGUI) and I can't disable it.
I have FAILSAFE disabled in config.h and I have no receiver connected to the FC.
THR channel reads 1350 & ROLL reads 1450 (not sure why, should be at 1500).
All other channels are at 1500. All AUX switches are disabled.
I checked the code and can't find where ANGLE is being enabled by default.

any ideas why this is happening?

PatrikE · Post by **PatrikE** » Wed Sep 03, 2014 9:52 am

It's Failsafe!..
Failsafe throttle is 1350 if you have not changed it.
Roll 1450 is there to put the plane in a large left turn instead of flying level for ever.(Flyaway)
Start Transmitter and Angle mode should be disabled.

Make sure you commented FAILSAFE in config.

rubadub · Post by **rubadub** » Wed Sep 03, 2014 10:32 am

PatrikE wrote:It's Failsafe!..
Failsafe throttle is 1350 if you have not changed it.
Roll 1450 is there to put the plane in a large left turn instead of flying level for ever.(Flyaway)
Start Transmitter and Angle mode should be disabled.

Make sure you commented FAILSAFE in config.

yes, but the strange thing is that FAILSAFE is completely disabled in the config, I triple-checked, and it is definitely disabled...

PatrikE · Post by **PatrikE** » Wed Sep 03, 2014 6:47 pm

In gps.h.
#define FAILSAFE // Enable RTH failsafe incl Auto DisARM at home to autoland

Comment that too.

rubadub · Post by **rubadub** » Thu Sep 04, 2014 1:42 am

PatrikE wrote:In gps.h.
#define FAILSAFE // Enable RTH failsafe incl Auto DisARM at home to autoland

Comment that too.

aaaah, ok, that must have been it, the defines were all hidden in GPS.h.
Do you need approval to send them to config.h? It would be a lot more helpful if they were in the main config file

PatrikE · Post by **PatrikE** » Thu Sep 04, 2014 9:13 am

I've just kept the defines separated while testing.
In the Config file is hard to see the trees because of the forrest!..

It should be merged in Config.h
Or even settable from gui.

rubadub · Post by **rubadub** » Wed Sep 17, 2014 3:08 am

questions about ROLLRATE and PITCHRATE constants for flying wing's.
What's the reasoning behind selecting the default values of 0.5 for these constants?
What effect would changing them have on flying wing performance?
- I read the code & can understand the algorithm, but I'm trying to get a real-world perspective on how & when these values should be modified for best performance.

What would need to be done in order for these items to be configurable via serial protocol/GUI? In order to test different values for these rates, you'd be forced to modify the code, re-compile & re-upload, which is very impractical.

PatrikE · Post by **PatrikE** » Wed Sep 17, 2014 10:18 am

What's the reasoning behind selecting the default values of 0.5 for these constants?

It's away to keep symmetrical throws on combinated full throws on Roll/Pitch.
If you apply Roll without the 0.5 constant it can use whole Servorange.
When you then apply elevator that servo can't move past the endpoint.
Then only one servo can move freely while the other is already at endpoint.

Using the constant will limit each RC function to use half the actual servo range.
Leaves room for both axis inside the endpoints and gives symmetrical throws.

Lot's of theory and it's only when you use large throws it will be noticeable.
I usually set it to 0.8 on my plane.

To adjust from Gui means quite some work.
And memory consuming on a 328.

rubadub · Post by **rubadub** » Wed Sep 17, 2014 11:03 am

PatrikE wrote:
What's the reasoning behind selecting the default values of 0.5 for these constants?

It's away to keep symmetrical throws on combinated full throws on Roll/Pitch.
If you apply Roll without the 0.5 constant it can use whole Servorange.
When you then apply elevator that servo can't move past the endpoint.
Then only one servo can move freely while the other is already at endpoint.

Using the constant will limit each RC function to use half the actual servo range.
Leaves room for both axis inside the endpoints and gives symmetrical throws.

Lot's of theory and it's only when you use large throws it will be noticeable.
I usually set it to 0.8 on my plane.

To adjust from Gui means quite some work.
And memory consuming on a 328.

thanks for the explanation.
so, how did you come to a value of 0.8 for your flying wing? what caused you to conclude that this value was adequate? How much trial&error did it require? Would you recommend 0.8 as a starting point, or should I simply stick with 0.5?

theailer · Post by **theailer** » Wed Sep 17, 2014 1:07 pm

It would be quite easy to determine. Just push full up on elevator and see if it's travels half of the servo range or if you have instructions from the manufacturer to determine max elevator deflection. And then do the same for aileron and lastly both together.

PatrikE · Post by **PatrikE** » Wed Sep 17, 2014 4:37 pm

I tested 0.8 and the throws was close to recommendations in the manual for the plane.
It would be easier to be able to adjust from Gui..

In Baseflight version it can be set from CLI.

rubadub · Post by **rubadub** » Wed Sep 17, 2014 9:51 pm

PatrikE wrote:I tested 0.8 and the throws was close to recommendations in the manual for the plane.
It would be easier to be able to adjust from Gui..

In Baseflight version it can be set from CLI.

ok, thanks.
yes, it would be great to have in the GUI or CLI, at least for the MEGA versions...

rubadub · Post by **rubadub** » Wed Sep 17, 2014 11:07 pm

quick question:
from looking at the code, it appears that the MOTOR_STOP option doesn't have any effect on FLYING_WING mode.
I've made the following change, but I'm not sure what consequences it might have on Patrik's NAV code

Code: Select all

    /*****************************             FLYING WING                **************************************/
    if (!f.ARMED) {
      servo[7] = MINCOMMAND;  // Kill throttle when disarmed
    } else {
   #if defined(MOTOR_STOP)
      servo[7] = constrain(rcCommand[THROTTLE], MINCOMMAND, MAXTHROTTLE);
        #else
      servo[7] = constrain(rcCommand[THROTTLE], conf.minthrottle, MAXTHROTTLE);
        #endif
    }
    motor[0] = servo[7];

should this be ok, or will it interfere with other throttle-related functions?

PatrikE · Post by **PatrikE** » Thu Sep 18, 2014 2:20 pm

MOTOR_STOP is handled later after all mixers.
And applies on all models.

rubadub · Post by **rubadub** » Thu Sep 18, 2014 8:50 pm

PatrikE wrote:MOTOR_STOP is handled later after all mixers.
And applies on all models.

I was under the impression that this wasn't the case when using a servo pin for throttle. Also, FLYING_WING mode has a motor count of zero in def.h, which would it exclude it from the "motor normalization" section of the mixer. I've enabled MOTOR_STOP, armed it, and I'm still seeing the motor output jump to minThrottle instead of minCommand.

EDIT:
nevermind, I was using the 'THROTTLESERVO' option, which I just realized wasn't necessary.
So, it works fine with the normal motor[0] pin (D3 on the MEGA). The code still looks like it might have issues for anyone using the 'THROTTLESERVO' option. Unless I'm missing something, at no point is the MOTOR_STOP option handled for the servo outputs. It might be something to look into...

rubadub · Post by **rubadub** » Tue Sep 30, 2014 10:03 am

question:
what's the best practice for deciding on "servo rates"? It seems that the only effect they have is to multiply the PID factor by the specified percentage, so then couldn't the values simply be set to 100 and then have the throw controlled only by the PID term? Or, am I missing something? It seems like it would be easier to just dial the PID values up or down vs. having to recompile to experiment with the servo rates (I don't believe that they can be configured over MSP or can they?)...

Basically, what's the best way to go about configuring these values?
FYI, this is for a bixler1 airframe...

PatrikE · Post by **PatrikE** » Tue Sep 30, 2014 8:45 pm

You can do most servo settings from the gui.
Look at the servo tab.

brewski · Post by **brewski** » Thu Oct 02, 2014 9:15 am

I have a Crius SE V2.3 328P based FC as well as UBlox 6M sitting in my (good) junk box. I dug out my Bixler 1.1 the other day & after reading some posts/threads on MW Airplane Mode I thought I might give the old plane some intelligence.
Is there any guide on how to set up a 328P based FC running MW Airplane mode with a plane such as the Bixler that has ailerons, rudder & elevator?
Also with such a basic FC is GPS RTH possible?

Cheers..B

Hoppsan_84 · Post by **Hoppsan_84** » Thu Oct 02, 2014 9:53 am

Short answer, Yes.
I use PatrikE firmware in my Easy Star with a Arduino Mini, and a neo6 gps.

Works perfectly with RTH, PH and Failsafe

PatrikE · Post by **PatrikE** » Thu Oct 02, 2014 10:21 am

Is there any guide on how to set up a 328P based FC running MW Airplane mode with a plane such as the Bixler that has ailerons, rudder & elevator?

http://fotoflygarn.blogspot.com/2012/03 ... -same.html
http://fotoflygarn.blogspot.com/2014/04 ... plane.html

PatrikE · Post by **PatrikE** » Thu Oct 02, 2014 10:23 am

Hoppsan_84 wrote:Short answer, Yes.
I use PatrikE firmware in my Easy Star with a Arduino Mini, and a neo6 gps.

Works perfectly with RTH, PH and Failsafe

Nice that you managed to get it working Hoppsan..

rubadub · Post by **rubadub** » Thu Oct 02, 2014 10:32 am

FYI, for anyone using FLYING_WING...

In case anyone wants to play with the rate settings for pitch&roll without having to recompile, here's what I did...

Code: Select all

//Output.cpp, mixTable() function
  #elif defined( FLYING_WING )
  #elif defined( FLYING_WING )
    /*****************************             FLYING WING                **************************************/
    if (!f.ARMED) {
      servo[7] = MINCOMMAND;  // Kill throttle when disarmed
    } else {
      servo[7] = constrain(rcCommand[THROTTLE], conf.minthrottle, MAXTHROTTLE);
    }
    motor[0] = servo[7];

   int8_t s3d=conf.servoConf[3].rate < 0 ? -1:1;
   int8_t s4d=conf.servoConf[4].rate < 0 ? -1:1;
   
   if (f.PASSTHRU_MODE) {    
      // do not use sensors for correction, simple 2 channel mixing
      servo[3] = (s3d*rcCommand[PITCH]*(int32_t)abs(conf.servoConf[3].rate)  - s3d*rcCommand[ROLL]*(int32_t)abs(conf.servoConf[4].rate))/100L;
      servo[4] = (s4d*rcCommand[PITCH]*(int32_t)abs(conf.servoConf[3].rate) + s4d*rcCommand[ROLL]*(int32_t)abs(conf.servoConf[4].rate))/100L;

   } else {                  // use sensors to correct (gyro only or gyro+acc according to aux1/aux2 configuration
      servo[3] = (s3d*axisPID[PITCH]*(int32_t)conf.servoConf[3].rate    -  s3d*axisPID[ROLL]*(int32_t)conf.servoConf[4].rate)/100L;
      servo[4] = (s4d*axisPID[PITCH]*(int32_t)conf.servoConf[3].rate   +  s4d*axisPID[ROLL]*(int32_t)conf.servoConf[4].rate)/100L;
   }
   
   servo[3] += get_middle(3);
   servo[4] += get_middle(4);

the integer math might stand to be cleaned up and a bit more optimized, but this seems to work ok for now & for my needs.

what that does is use the user-configurable rates for servos 3 & 4 in place of the PITCHRATE and ROLLRATE constants.

A negative number indicates an reversed servo.
On my teksumo wing, I have left servo set to -50 and right servo to 50.

use at your own risk, but this is working great for me.
I can configure the rates on the fly via ez-GUI's servo settings window, which is pretty cool...

Hoppsan_84 · Post by **Hoppsan_84** » Thu Oct 02, 2014 10:35 am

PatrikE wrote:
Hoppsan_84 wrote:Short answer, Yes.
I use PatrikE firmware in my Easy Star with a Arduino Mini, and a neo6 gps.

Works perfectly with RTH, PH and Failsafe

Nice that you managed to get it working Hoppsan..

Works incredibly well. A bit boring almost. But it can be turned off if it gets too easy

brewski · Post by **brewski** » Thu Oct 02, 2014 10:57 am

PatrikE wrote:
Is there any guide on how to set up a 328P based FC running MW Airplane mode with a plane such as the Bixler that has ailerons, rudder & elevator?

http://fotoflygarn.blogspot.com/2012/03 ... -same.html
http://fotoflygarn.blogspot.com/2014/04 ... plane.html

Wow this is fantastic! This is what Multiwii needs for multirotors.
Something like this professionally done blog would make it so much easier for noobies to MW & do away with the so out of date & un user friendly WiKi.
I am now determined & fully informed as how to setup my Bixler V1.1 & start to use it in FPV role with confidence.