Airplane mode RTH

[rbirdie001]

Hi!
finally tested new FW NAV PID version in the air and improvement of the navigation is just GREAT! Also servo trimming from GUI is for me big help.
No more snake flight but very smooth and straight navigation towards home. Simply big improvement
I noticed only one problem of ACC mode generally: I'm unable to adjust correctly PITCH stabilization from ACC to make plane flying approx. in level or rather little pitch up. I calibrated ACC some ~10 degrees nose up (I even tested to calibrate it extremely nose up - I guess about +30 degrees but no change). When I let it fly alone in ACC, it's always gaining speed and is flying more nose down than I'd like to. When I apply high throttle, it starts descend even faster.
My flying wing is balanced little "heavy nose" compensated by elevons trimed up so if I add throttle in PASSTHRU and GYRO, it start immediately climbing, but in ACC is all the time going down. If I activate ACC in my hand and tilt the plane nose UP or DOWN, elevons are reacting in correct direction. I think it was similar in previous version too, but now it seems even worse.
I'll keep trying to find why, I'm used for the situation that something which works for everyone else doesn't work for me. I'm "natural beta tester"
Any ideas wellcome!
See you!
Roman

Edit: First findings about this: On my plane there is error behavior of LEVEL I term in HORIZON mode.
First (but logical) problem for the planes is that if THROTTLE is OFF, LEVEL I term register is continually reseted (because for the copter it mean it's on the ground). But plane can glide . I think that this reset should by bypassed for all kind of planes because even in gliding we need active I term. If no throttle in ACC mode and plane is significantly tilted in PITCH axis, servos are shaking but not adding control throw from I accumulation.
Additionally it seems to me that LEVEL I term (at my setup!) have wrong direction: If I tilt me plane in PITCH axis in ACC mode, servos reacts immediately in right direction (so P reaction is OK) but if I have set high value to LEVEL I term (I tested e.g. 0.150) and give little throttle (just to "open" I term control) servos start giving more and more correction (caused by I accumulating of PITCH error) but in ROLL direction!
There seems to be something wrong with HORIZON mode I term but with my programming knowledge I'm not sure if I can find it.
I'll try but any help will be wellcome. I guess there can be some bug in HORIZON PID calculation.
Regards
Roman

[crashlander]

I noticed only one problem of ACC mode generally: I'm unable to adjust correctly PITCH stabilization from ACC to make plane flying approx. in level or rather little pitch up. I calibrated ACC some ~10 degrees nose up (I even tested to calibrate it extremely nose up - I guess about +30 degrees but no change).

I was noticing same behavior from the beginning of RTH testing, but it is not always visible/observable (not on every setup equally). In the begging I believed it was wrong gyro scaling, but after it was fixed (and problem still remained) vibrations was next suspect....
Originali I flayed completely untrimmed wing but after fine tuning it in PASSTHRU mode that problem almost disappeared and that probably even more confirms your observations that there is an issue with horizon/level mode.

Regards
Andrej

[mariusmelc]

Hello Guys

I download the version PatrikE MultiWii_dev_2013_07_15_r1539 with NAV_PID.
I add :
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)
After test, I can't revese roll direction on my Flying Wing/mega/ppm. "#define ROLL_DIRECTION_L -0.5" or "#define ROLL_DIRECTION_L 0.5" don't have any effect


Samone can help me ?

Thanks

Sorry for my ennglish

[PatrikE]

Hi..

In this ver i have modified the flyingwing Mix.
It's the same file but just updated.
NAV_PID.rar

In output.cpp you can find this

Code: Select all

   #define ROLLRATE 0.5
   #define PITCHRATE 0.5

I have set it to 0,5 as default so you should be able to just upload it.

Cheers
Patrik

[mariusmelc]

Thanks PatrikE

[rbirdie001]

Hello Guys

I download the version PatrikE MultiWii_dev_2013_07_15_r1539 with NAV_PID.
I add :
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)
After test, I can't revese roll direction on my Flying Wing/mega/ppm. "#define ROLL_DIRECTION_L -0.5" or "#define ROLL_DIRECTION_L 0.5" don't have any effect


Samone can help me ?

Thanks

Sorry for my ennglish

Hi!
servo orientation changes were moved to GUI so these lines probably won't work anymore. Compile without it and then connect with GUI program from last dev. (currently r1555) Choose "servo" tab on the top, there "servo" and "go live" buttons. You can choose there inversion for every axis and servo and also trim servos. Result you will see immediately on the plane, then don't forget to save it.
I hope this will help.
Roman

[mariusmelc]

A BIG Thanks

I test that tomorrow in fpv

[mariusmelc]

And about mode setings ...
This is ok ?
No others mode for Airplane/FlayngWing ?

THANKS

[rbirdie001]

Hi!
I continued in discovering what is wrong with HORIZON mode I term and found that the strange behavior I found at airplane dev. version is present also in stock 2.2 tricopter configuration so it seems to be hidden software bug.
Here is short description:
Tricopter is lying on the ground and tail is supported by a brick so ROLL axis is levelled and PITCH axis is tilted to front.
In acro mode all motors are running equally because no movement so no gyro corrections.
For the first test I adjusted just P and D term for the LEVEL, I term was 0. When I activated (at 0:07) HORIZON, front motors speeded up and rear motor slowed down because P term tries to compensate tilt on PITCH but both front motors are still have the same speed (because ROLL is levelled). That's OK.
Then I adjusted I term constant to 0.069 which is more than default but still reasonable value and again activated HORIZON mode (0:28 and again 0:42).
You can see that motors first did the same as before but very fast right motor starts speed up more than left one so it looks like that I correction from PITCH is added to ROLL.
Look here and hear "narrator" http://www.youtube.com/watch?v=z2rAY_X_u3w
I didn't test all other combinations but it looks that there is something wrong in the code. Because I'm not experienced in code, I hope that someone from programmers can look at it and possibly correct it.
Guys, I'm writing it here first (to our small, friendly group ) to look at my observations and confirm me if I'm right before I'll post it to the Software developement forum and they would laugh at me if I'd be wrong .
Thanks!
Roman

[rbirdie001]

And about mode setings ...
This is ok ?
No others mode for Airplane/FlayngWing ?

THANKS

You can try also HORIZON mode, could be better.
Roman

[mariusmelc]

Thanks

[mariusmelc]

What is the effect of different mode on the Plane/FLYING_WING

ANGLE = PITCH stabilisation ?
HORIZON = ROLL stabilization ?
BARO = ALT stabilisation ?
MAG = ?
HEADFREE = ?
HEADADJ = ?
GPSHOME = Retour Home + Fly around a home point ?
GPSHOLD = Fly around a gps point ?

List of the combinated mode ? efect ?
Ex : ANGLE + HORIZON + BARO = ? ( work ?)

Another Thanks

[rbirdie001]

What is the effect of different mode on the Plane/FLYING_WING

ANGLE = PITCH stabilisation ?
HORIZON = ROLL stabilization ?
Angle and horizon are similar - both stabilizing PITCH+ROLL to horizontal level. The only difference is that angle is active always but horizon supress levelling when you give strong stick input so control is more natural. Angle stabilizes so much, that any control is difficult.
BARO = ALT stabilisation ? Yes for multicopter, not for plane except current dev. versions - see few pages back.
MAG = ? Stabilizes yaw using compass. Used in multicopter, don't know if works for plane.
HEADFREE = ? N/A for plane.
HEADADJ = ? N/A for plane.
GPSHOME = Retour Home + Fly around a home point ? Yes
GPSHOLD = Fly around a gps point ? Yes

List of the combinated mode ? efect ?
Ex : ANGLE + HORIZON + BARO = ? ( work ?) No, see above.

Another Thanks

Hope This will help
Roman

[rbirdie001]

Hi,
sorry but on my flying wing altitude control in last RTH PID version doesn't work.
With older version 130322 when plane returned home, it remained circling in safe height and was keeping the same height until I switched RTH off or batery was discharged. Navigation wasn't so nice as is now , but height control worked...
Last PID RTH version from 22.8. climbs up when RTH is activated lower than is safe height, but when plane reaches home, it is circling lower and lower until I have to disable RTH when the plane is almost touching ground, to avoid hard landing under throttle.
Safe height I have set to 45m in GUI, in GPS.h I have this value:

Code: Select all

#define GPS_ALTCORR    3   // P for Elevator.

(in previous version it was 2)
I don't know what other setting can I have set wrong. For you other (Patrik, Andrej...) it works fine?
Thanks for any ideas!
Thanks!
Roman

[PatrikE]

Hi Roman,

I think FAILSAFE_RTH is enabled in latest dev.
It makes the plane Autoland at home

Code: Select all

#define FAILSAFE_RTH    true  // Enable RTH for failsafe incl Auto DisARM at home for autoland

/Patrik

[rbirdie001]

Hi Roman,

I think FAILSAFE_RTH is enabled in latest dev.
It makes the plane Autoland at home

Code: Select all

#define FAILSAFE_RTH    true  // Enable RTH for failsafe incl Auto DisARM at home for autoland

/Patrik

Hi Patrik,
thanks for ideas, I'll gradually test them but I don't think FAILSAFE_RTH is right hint. I activated RTH by a switch and not by failsafe situation so it should be another case when the plane ends at position hold @ safe height and not autoland. Additionally the motor is still running and trying to climb the plane higher but the elevator doesn't go up so plane is just flying fast but keep descending.
Roman

[surf_akinys]

Roman, make shure that after enabling RTH plane is in angle or horizon mode. I noticed this behaviour also and found that GPS code do not check this.
Also I found that FW_NAV is hard to read and rewrote it compleatly. Thats how fork started.

[PatrikE]

@Roman

ELEVATORCOMPENSATION can be to low.
If it's to low the plane will lose altitude in banking turns.
If it's to high the plane will pitch up in turns.

Try to increase it.
Its just a percentage of compensation on elevator of rollangle.
Should be safe to increase to the double.

GPS_angle[axis] is only used if AccModes is activated in the Mwii PID calculation.

/Patrik

[crashlander]

@rbirdie001
If you enable

Code: Select all

#define FAILSAFE_RTH    true 

the plane will go into failsafe motor off when home point is reached (no mater how RTH is enabled).
I had to increase ELEVATORCOMPENSATION to 130 to get proper behavior.

@all
Today I flew latest Patrik's code (after fine tuning trimming and motor trust angle in pass-thru mode) it worked perfectly.
I did some auto-launches (my code addition). I also enabled RTH some 400m away 20m high and flying away, it returned home perfectly.

@PatrikE
Make that move into _shared and get more testers....

Regards
Andrej

[crashlander]

Hi!
I continued in discovering what is wrong with HORIZON mode I term and found that the strange behavior I found at airplane dev. version is present also in stock 2.2 tricopter configuration so it seems to be hidden software bug....

When using LEVEL/HORIZON mode MWII uses also accel. measures and those are very sensitive to vibrations (much more than gyro) so when you upped I term for level and doing your test on the ground the I term "saturated" PID loop (due to perceived tilting from vibrations).

Regards
Andrej

[crashlander]

...
Safe height I have set to 45m in GUI, in GPS.h I have this value:

Code: Select all

#define GPS_ALTCORR    3   // P for Elevator.

(in previous ...

I'm using Patrik's stock

Code: Select all

GPS_ALTCORR    10

and it works flawlessly altitude goes up-down inside 5 to 10m belt in calm weather and up-to 25 in stronger winds. Maybe usage of baro would help...?

Regards
Andrej

[mariusmelc]

Hello,
I dont have a good version of MultiWiiConf , ,

Good link ???? https://code.google.com/p/multiwii/sour ... FAero_Heli ???

Thanks

[PatrikE]

I added the latest in my branch.
branches/PatrikE/NAV_PID_130909.rar

[surf_akinys]

First (but logical) problem for the planes is that if THROTTLE is OFF, LEVEL I term register is continually reseted (because for the copter it mean it's on the ground). But plane can glide . I think that this reset should by bypassed for all kind of planes because even in gliding we need active I term. If no throttle in ACC mode and plane is significantly tilted in PITCH axis, servos are shaking but not adding control throw from I accumulation.
Additionally it seems to me that LEVEL I term (at my setup!) have wrong direction: If I tilt me plane in PITCH axis in ACC mode, servos reacts immediately in right direction (so P reaction is OK) but if I have set high value to LEVEL I term (I tested e.g. 0.150) and give little throttle (just to "open" I term control) servos start giving more and more correction (caused by I accumulating of PITCH error) but in ROLL direction!
There seems to be something wrong with HORIZON mode I term but with my programming knowledge I'm not sure if I can find it.
I'll try but any help will be wellcome. I guess there can be some bug in HORIZON PID calculation.
Regards
Roman

I think code, that turns off I for axies is here (MultiWii.cpp):

Code: Select all

    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0;
      #if PID_CONTROLLER == 1
        errorGyroI_YAW = 0;
      #elif PID_CONTROLLER == 2
        errorGyroI[YAW] = 0;
      #endif
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }

 

[mariusmelc]

I added the latest in my branch.
branches/PatrikE/NAV_PID_130909.rar

Hi,
And the GUI ?

Thanks

[crashlander]

And the GUI ?

GUI from current _shared will work.

Regards
Andrej

[bigcheese]

nice!
I've just ordered the MultiWii Pro with GPS from HK - looking forward to try this out
Have anyone already this Controllerboard and use Baro and everything?

cheers,
Bigcheese

[rbirdie001]

Hi guys,
I for some time had returned to my tricopter (also because I was so long time so unsuccessfull with the airplane RTH height control ) but now I got new idea which returned me to it.
When searching on ebay I found this baro sensor BMP180: http://www.ebay.com/itm/190866399811?ss ... 1439.l2649 . It should be compatible with BMP085 but better and it was so nice and so cheap , that I couldn't resist and ordered one for the test.
Earlier in this forum I've seen attempts to use baro for RTH flight viewtopic.php?f=7&t=2456&start=270#p40532 so I want to ask what were the results?
If it works, it could solve my problem because for me RTH navigation works great but plane always looses height until I have to pull elevator otherwise it would crash.
Patrik, can you please review for me height management algorithm during RTH when I have this settings:

Code: Select all

#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 220   //I set so much but still I'm loosing height

When I activate RTH by switch e.g. in 60m (while safe height is set to 50m), what height is actively maintained during flying home? 60m, 50m or no control after first check that we are high enough? What after home is reached?
What is behaviour when RTH is activated by failsafe routine?
Sorry to ask all the time round but last months I made maybe 10 changes in code and tests but still I can't make height control working .
Thanks!
Roman

[PatrikE]

Hi Roman,

When RTH is enabled.
#.Check altitude.
#.Check Distance to home.

if RTH_BAILOUT true
-Climb with level wings until set rthAlt is reached

If dist is >100 meters and altitude is more than set rthAlt.
-only use Roll Angel=>elevator compensation.(Cruise)
if Alt is lower compensate with elevator up and add throttle.(Climb)

if Dist home is <100m descend to set rthAlt using elevator.
This Zone should maybe be smaller. 100 meter radius is quite large area.

If FAILSAFE_RTH true and set rthAlt is OK
- After first pass within 5 meter from home autoland is enabled.
- (Cut throttle and soar using only Roll Angel=>elevator compensation)

I have not tested the baro Gps is sufficient on my plane.

[crashlander]

...
If dist is >100 meters and altitude is more than set rthAlt.
-only use Roll Angel=>elevator compensation.(Cruise)
...
.

Would it be possible to redefine code in a way that in that case current ALT would be set as target? Because without that there is good chance that the plane will still lose altitude on its way home especially on longer distance fly.

Regards
Andrej

BTW: Today I was able to successfully "maiden" another GPS controlled wing.

[rbirdie001]

Hi,
thanks for both oppinions. Next week I'll be on bussiness trip so I hope on evenings at the hotel I'll look again at the RTH code and understand more if it .
Also I took today one of my wings with me to family walk (Drenalyn - no computers, no GPS, no gyros, everything 100% manual) and whole family withstanded watching whole battery of crazy twisting (they are generally bored of my flying ).
Just to ensure I understand well:

if Dist home is <100m descend to set rthAlt using elevator.

When RTH is activated by switch, plane gets home, starts circling and reaches (from top) minimum safe altitude, should it then keep safe altitude until the battery is flat or descends further?
On my plane in this situation the motor is still running and throttle is automatically changing (so it remains armed), but elevator doesn't go up so plane descends and speeds up by increasing throttle and lovering height.
When I set higher P than approx. 4 for alt. control, plane when climbing reaches safe altitude then start jumping and wings are sometimes breaking...
I already changed Mediatek GPS for Ublox Neo6M which improved height control in 130322 but now in the new version I'm again unable to tune it up.
I'm afraid that anyway this was one of last nice weekends, winter is coming...
Have a nice days.
Roman

[crashlander]

Hi,
...
When RTH is activated by switch, plane gets home, starts circling and reaches (from top) minimum safe altitude, should it then keep safe altitude until the battery is flat or descends further?...

In previous versions when

Code: Select all

#define FAILSAFE_RTH true

was selected my wing disarmed at home point and start to glide/descend.
But in current version it seems that option is not working, plane is just circling around home point and adding TH to maintain height.

@PatrikE
in GPS.h you/I define

Code: Select all

#define FAILSAFE_RTH true

in def.h there is only deffinition for

Code: Select all

#if FAILSAFE_RTH  && !defined (FAILSAFE)
    #define FAILSAFE
  #endif

but in GPS.c you are looking for

Code: Select all

#if FAILSAFE_RTH_ENABLE

I'm afraid that anyway this was one of last nice weekends, winter is coming...
Have a nice days.
Roman

The winter is just another flying season!

Regards
Andrej

[crashlander]

Another idee from one of earlies rbirdie001 posts is to disable I term zeroing for MINTH and thus enable proper glide with motor off (disarm):
in MultiWii.cpp add define for fixedwing around I term zeroing code!

Code: Select all

#if !defined(FIXEDWING) //crashlander test for glider FIXEDWINGS=====START
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0;
    
      #if PID_CONTROLLER == 1
        errorGyroI_YAW = 0;
      #elif PID_CONTROLLER == 2
        errorGyroI[YAW] = 0;
      #endif
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
     #endif //crashlander test for glider FIXEDWINGS=====STOP

Not yet tested code of-course...
Any obvious drawbacks?

Regards
Andrej

[rbirdie001]

Hi Andrej,
I'd be caredul with this. I have feeling, that I term should be sometimes reset. Imagine, that your wing is waiting for GPS fix or you just hold it with one hand longer time so I term accumulates until is full an then you throw the plane into the air. Due to I term influence it could make an unepected turn and crash. If disable reseting, then I'd make at least one reset e.g. when changing fom MINTHROTTLE to some significant TH. (Lets say do reset when last TH value was under 1300 and current TH is over 1300.) Just for an idea.
Anyway I have to say, that even removing I term resetting wich I already tested didn't solve my problem with height control so if your wing performs well with the current code, I'd apply old but smart saying "Don't touch what works well!"

BTW: Now I'm on the training in middle of Italy and I'm starting to understand your notice that

The winter is just another flying season!

Here, 1000km south from my home I'm walking in T-shirt and buy ice cream while at home I was two days ago walking in a sweater, jacket, cap and warmed my hands on a cup of hot tea...
You are not that far from me, but anyway it is some difference.
Regards
Roman

[rbirdie001]

Hi Patrik,
I'm now trying to understand at least a little of RTH code, namely the height control and I'm still wonder about some lines in last FW_NAV_PID version GPS.cpp. In lines 1493 and 1500 I see that GPS_AltErr - means I am low and + means I am high, right?:

Code: Select all

GPS_AltErr = GPS_altitude - GPS_hold[ALT]; // Altitude error - means your'e to low
...
if(GPS_AltErr >=0) GPS_angle[PITCH] = GPS_angle[PITCH]/3;         // Limit throw for descending.

Now why on line 1523 we are proceeding "we are higher" code when GPS_AltErr <=0, which should mean that we are low or on the level?

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 >100){ GPS_angle[PITCH]=0 ;}             // RTH Nav Stage Use only ACC to maintain altitude

This is the strange thing I noticed but this seems not to be cause of my troubles because my plane is lowering even while it's circling around home so it's less than 100m far from home and in that case value calculated in the line 1499 should bypass all successive lines unmodified and be used as is for the elevator compensation. Right?

Code: Select all

GPS_angle[PITCH]= GPS_AltErr * GPS_ALTCORR ;                      // Calculate Elevator compensation.

I will be glad if you can answer me and possibly review one more time this part of the code, where GPS_angle[PITCH] is calculated and modified, if there isn't any hidden error.
Thanks!
Roman

[crashlander]

Code: Select all

GPS_AltErr = GPS_altitude - GPS_hold[ALT];

GPS_hold[ALT] -> where I wanna be
GPS_altitude -> where I'm
So + means I'm higher and - means I'm too low.
And that works O.K. whene used here

Code: Select all

// Climb out before RTH
if(GPS_AltErr < 0 && f.CLIMBOUT_FW && f.GPS_HOME_MODE ){

But you are right that one is sure strange

Code: Select all

if (f.GPS_HOME_MODE && !f.CLIMBOUT_FW && GPS_AltErr <=0 ){        // While we are higher than RTH alt.

Because that activates active dive if we are higher. And that is probably what I observed but believed that I have ELEVATORCOMPENSATION issue (Patrik?!).

In the moment that plane passes that home zone mark (20m in my case) (and it is not in CLIMBOUT_FW and it is lower than target (in original, probably wrong code)) it will no longer use

Code: Select all

GPS_angle[PITCH]= GPS_AltErr * GPS_ALTCORR ;                      // Calculate Elevator compensation.

because of

Code: Select all

if (GPS_distanceToHome >20){ GPS_angle[PITCH]=0 ;} 

so the only active ALT control will be

Code: Select all

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

Regards
Andrej

[crashlander]

I've just flight tested all my mods from above (including disable I zeroing with min TH) and they works as expected!
I had to increase home zone to 100m otherwise my (quite)fast wing would hold altitude, circling with radius biger than small 20m zone.
I also increased DISARM zone to 30m since 5m was hard to hit.
I also suggest to remove alt checking in last DISARM step since it can be hard to please. My wing during circeling around home point loses height and when reaching disarm zone it is too low to disarm so it overflies it and when is out it starts to climb to safe height, and again upon return it is too low (so this continues for a while until luck strikes that both params are true).
I'm attaching changed files for reference.

Regards
Andrej

[crashlander]

Hi Andrej,
I'd be caredul with this. I have feeling, that I term should be sometimes reset. Imagine, that your wing is waiting for GPS fix or you just hold it with one hand longer time so I ...

Hand launching the plane will produce more than enough disturbances to zero out I couple of times.

Regards
Andrej

[Chriss]

Hello,

I am impressd of the good work! Thanks for that!

I orderd Crius MWC SE v2.5 and want to install FC, GPS in my Bixler2 (Crius doesn't arrived yet). For testing I use a Arduino Pro Mini (only for testing compiling e.g.). When I want to compile it with I2C_GPS, there is an error in GPS.cpp (FW_nav()).

Code: Select all

/******************************  
  PID Test for Navigating planes.
  ******************************/
    static int16_t oldif;
    
    naverrorI += (dif * (navPID_PARAM.kI)) *gpsFreq;
    naverrorI =constrain(naverrorI,-MAX_I,MAX_I);
    
    naverrorD += ((dif - oldif) *navPID_PARAM.kD) * gpsFreq;
    naverrorD =constrain(naverrorD,-MAX_D,MAX_D);
    oldif = dif;
    dif *= navPID_PARAM.kP;

    dif += naverrorI/100-naverrorD/100;
 //******************************

navPID_PARAM ist not defined when GPS_SERIAL is not set.

Is it the right way to configure it?

Connection is: Crius => [I2C] => NAV Modul => [UART] => GPS

Have I forgot something in config.h?

Code: Select all

see attachment :)

I use the latest NAV_PID_130909

Regards from Germany,
Chriss

[PatrikE]

Hi chriss,

You're right.
It's missed when implementing PID's for navigation.
When using I2C gps only the PID's inside the I2C unit is used.

At ~row 56 in gps.cpp.

Code: Select all

#if defined(GPS_SERIAL) || defined(GPS_FROM_OSD) || defined(TINY_GPS)

Change to

Code: Select all

#if defined(GPS_SERIAL) || defined(GPS_FROM_OSD) || defined(TINY_GPS) || ( defined(FIXEDWING) && defined(I2C_GPS))

Then it will compile.

[rbirdie001]

Hi Patrik,
I see you are back!
Because I'm preparing another attempt to make running well new vesion FW_NAV_PID, I want to ask you if you can confirm my observations here: viewtopic.php?f=7&t=2456&start=330#p42370
This weekend we should have nice weather here so I want to finally move on!
Thanks Roman

[bigcheese]

Hi,

have anyone an idea how can I debug or dig down the problem I have?
In the GUI I can see throttle, arm and pitch/roll when moving sticks on my control.

but i never get the final accoustic signal from the BEC that everything is fine... even in passthrough mode...
I can't find the right pin on my MEGA board (looks like)

Code: Select all

/***********************             HW PWM Servos             ***********************/ 
    /* HW PWM Servo outputs for Arduino Mega.. moves:
      Pitch   = pin 44
      Roll    = pin 45
      CamTrig = pin 46
      SERVO4  = pin 11 (aileron left for fixed wing or TRI YAW SERVO)
      SERVO5  = pin 12 (aileron right for fixed wing)
      SERVO6  = pin 6   (rudder for fixed wing)
      SERVO7  = pin 7   (elevator for fixed wing)
      SERVO8  = pin 8   (motor for fixed wing)       */ 

    #define MEGA_HW_PWM_SERVOS

I assume pin 8 for motor and 6 and 7 for left and right wing (have a fixed wing, but there are only 10 pins on my board!!)
how can I clarify if the board have a problem or the software or my wiring?
Having this board: http://www.hobbyking.com/hobbyking/store/__26588__multiwii_pro_flight_controller_w_mtk_gps_module.html

thanks for any help

[Chriss]

Hi chriss,

You're right.
It's missed when implementing PID's for navigation.
When using I2C gps only the PID's inside the I2C unit is used.

At ~row 56 in gps.cpp.

Code: Select all

#if defined(GPS_SERIAL) || defined(GPS_FROM_OSD) || defined(TINY_GPS)

Change to

Code: Select all

#if defined(GPS_SERIAL) || defined(GPS_FROM_OSD) || defined(TINY_GPS) || ( defined(FIXEDWING) && defined(I2C_GPS))

Then it will compile.

Hi Patrik,

thanks for your reply! Now it semms to work (on Arduino Pro Mini without sensors, only for upload testing).
Just waiting for the Crius SE v2.5...

Is NAV_PID_130909 the latest version?

Regards from Germany,
Chriss

[PatrikE]

@Bigcheese.
The servo order is somewhat a mes since the servocode was rewritten.
This is the pins that works on mu Crius AIO.

// With MEGA_HW_PWM_SERVOS enabled
servo[3] D11 wing 1
servo[4] D12 Wing 2
servo[5] D7 Elevator
servo[6] D6 Rudder
servo[7] D3 ESC

// Without MEGA_HW_PWM_SERVOS enabled
servo[0] Pin D34 & Pin D44 //
servo[1] Pin D35 & Pin D45; //
servo[2] Pin D33 & Pin D46; //
servo[3] Pin D37; // Wing 1 Pin D7 with hack
servo[4] Pin D6; // Wing 2
servo[5] Pin D2; // Rudder
servo[6] Pin D5; // Elevator
servo[7] Pin D3; // Throttle

With a hack it's possible to move Wing 1 servo to Pin D7
In def.h
Servo pinmodes for Mega boards, Replace SERVO_4 defs with this code.

Code: Select all

  #define SERVO_4_PINMODE            pinMode (37, OUTPUT); pinMode (7, OUTPUT);  // new       - alt TILT_ROLL
  #define SERVO_4_PIN_HIGH           PORTC |= 1<<0;PORTH |= 1<<4;
  #define SERVO_4_PIN_LOW            PORTC &= ~(1<<0);PORTH &= ~(1<<4);

My advice is disable MEGA_HW_PWM_SERVOS and add Pin D7 as servo output in def.

It's a Mod that should be implemented to public code.
Many boards don't have all pins.

/PatrikE

[PatrikE]

Hi Patrik,
I see you are back!
Because I'm preparing another attempt to make running well new vesion FW_NAV_PID, I want to ask you if you can confirm my observations here: viewtopic.php?f=7&t=2456&start=330#p42370
Thanks Roman

Yes It seems like its inverted.
Test to use (>= radius) .
I think it will work better..

/Patrik

[PatrikE]

Is NAV_PID_130909 the latest version?

Regards from Germany,
Chriss

Yes but it's time to make a corrected update.
Probably tomorrow.

[crashlander]

@PatrikE
I have changed and tested some more lines of your code. You can check it here (if I remember correctly diff between r3 and r4 will show most of them).
https://code.google.com/p/crashlander-m ... 253Dclosed

Regards
Andrej

[rbirdie001]

Yes but it's time to make a corrected update.
Probably tomorrow.

Sound great!
Weather forecast still say it should be here good weather this weekend so I'll take new version (if ready ) and hopefully make the RTH code finally working also for me .
Patrik, I told you that I'm natural beta tester. If there is a bug, it will show up to me and if something works for me, then for everyone.
Roman

[PatrikE]

A updated version with corrections and some renaming in gps.h
Code also updated with latest changes in official branch.

FW_Nav_131024.rar

Dev-Branch for comparing.
https://code.google.com/p/multiwii/source/browse/branches/PatrikE/FixedWingNav_Dev/#FixedWingNav_Dev

/Patrik

[crashlander]

Thank you Patrik!
One question:
Why are you checking height before DISARM (why wait/aim for 5m before disarming)? I have tested disarm on whatever height the wing returns and I did not find any issues.

Code: Select all

if( f.FAILSAFE_RTH_ENABLE){
if (GPS_distanceToHome <20  && GPS_AltErr <=5 ){f.ARMED = 0;} 
}

In new release you doubled value for GPS_MAXCORR and GPS_MAXCLIMB! Now I had 15 for both and would say it was enough (maybe slightly more for climb but not for roll).

Regards
Andrej