Airplane mode RTH

PatrikE · Post by **PatrikE** » Sun Mar 03, 2013 5:08 pm

Hi Roman,

I found the cause of the glitches.
I'we missed a change in struture in the code when i merged it... :shock:

Thats the risk when it's not meged to the project!

This is the changes i tested.

A warning about FAILSAFE..
Make shure all channels on TX keeps wihin normal range. 1000 - 2000.
Otherwise FAILSAFE will be activated. ex. If throttle is to low on "idle"

It Puzzeld me for a while. :roll:

dr.tom · Post by **dr.tom** » Tue Mar 05, 2013 6:31 am

Does this RTH have any limitations,
I mean can it work(with well dampened PIDs ) on some really fast planes?
because other OSD's with rth just can't take speed into account and would make too sharp turn back in rth.

I have some birds that go over 300...
if they could be fitted with rth it would be great

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

rbirdie001 · Post by **rbirdie001** » Tue Mar 05, 2013 9:44 pm

PatrikE wrote:Hi Roman,

I found the cause of the glitches.
I'we missed a change in struture in the code when i merged it...
Thats the risk when it's not meged to the project!
...
A warning about FAILSAFE..
Make shure all channels on TX keeps wihin normal range. 1000 - 2000.
Otherwise FAILSAFE will be activated. ex. If throttle is to low on "idle"

It Puzzeld me for a while.

Hi Patrik,
thanks for the correction, now RC read is OK!
Is there any reason why this your work isn't merged in the project? (I noticed that otherwise you have in Multiwii many pieces of the code :?:

)

I already tested version above (3.3.2013) in flight on Multiplex Easystar II with MPU6050 - in that first step WITHOUT GPS just for stabilization and it works very well!
Now I'm going to connect GPS and hopefully this weekend will test with GPS.
Sorry, again I have some questions:
-I suppose that main goal of RTH function is to save plane which lost RC link (at least I'd like it work this way

). I'm not sure if it's already implemented or at least planned to allow initialize RTH when failsafe is activated. If yes, how?
BTW: I already experienced confusion after failsafe routine change in last dev's but now I readjusted enpoints on my TX and think it was a good change. This was the reason why I don't use SUM PPM yet. I made SUM PPM output on my RX but when signal is lost, there are crazy pulses. I tested it with the old FS routine, but when I disconnected TX, it didn't activate and plane got completely crazy. Now it should be better but I yet didn't verify it.

-Can you advice me how to deactivate Wing2 output on D12 and use it for AUX2? I don't need Wing2 out but I'd like to use BUZZER. (Even better would be to move Wing2 out, BUZZER out or AUX2 IN somewhere else - e.g. to A6 or A7.) I'm not good enough in programming to be able to do it but I'm still not decided to rely on my home made SUM PPM out.

-Stabilization of the plane generally works great on PITCH and YAW but I'm not 100% happy with my settings on the ROLL. When my plane gets some influence from a wind or thermals and starts (even slowly) move in ROLL axis, for a while is nothing happenning and then sudendly very strong correction comes by the ailerons and plane returns to level. This is unpleasant in recorded video because it looks like taken from the cart on stony road while I prefer it smooth. I'm not sure what direction to move PIDs and averaging filtering factor. I want to lower P and increase I and D. Whant do you think? Any ideas wellcome.
Again thank you for your work, I'll let you know how was the result of the tests...
We already had few nice days and I'm looking forward for another. In Sweden you probably will have to wait longer...

Roman

PatrikE · Post by **PatrikE** » Wed Mar 06, 2013 8:51 am

Is there any reason why this your work isn't merged in the project?

Mainly because it's not verified as working code yet.

Main goal of RTH function is to save plane which lost RC link

Currant Failsafe in MWii only Controlls Throttle and force AngleMode.
It need to be modified to enable RTH, Also for Multirotors.

I use a FRsky ppmsum and the programmable failsafe in it.

The Roll issue you see is the same LevelDrift you can see in Multirotors.
It's the I part in the PID's that builds up a errorangle.
Try with really low I value.
If you decreese P the Total servoThrows will be limited.

Even here in Sweden The sun is returning and warms up a little

PatrikE · Post by **PatrikE** » Wed Mar 06, 2013 11:54 am

Hi Roman,
If you modify row 1132 in multiwii.ino to..

Code: Select all

if (rcOptions[BOXGPSHOME]  || (failsafeCnt > 5*FAILSAFE_DELAY) {

It should activate GPS_HOME_MODE when failsafe is active.
Failsafe will cut throttle after FAILSAFE_OFF_DELAY.(Needs to be modified to use distance to home function)

rbirdie001 · Post by **rbirdie001** » Wed Mar 06, 2013 9:46 pm

Thanks, I'll step by step try things above.
I'm curious how will RTH work.

Problem which I have with ROLL isn't typical I term wind up, it's different:
If there is outside influence (wind, thermals) to ROLL axis causing unballancing and tilting the plane, for some time e.g. 0.5 sec nothing happens -> side tilt is increasing ... and then at once Multiwii makes fast and strong correction and returns plane back to level. It's nothing wrong on it for fun flying but it's bad for video recording. It's similar to how Formule 1 drivers control driving wheel by short correcting pulses compared to slow and fluent driving of a limousine driver. I think, that for the fluent control I probably need to increase and not to decrease I term and probably decrease filtering (i.e. delay) on the axis...
If I won't succeed next time, I'll make some explaining video.

Please let me ask once more if there is any easy way how to remap either Wing2 output, BUZZER output or AUX2 input to some unused pin like A6 or A7?

I'm conscious that FAILSAFE_OFF_DELAY is still active - fortunately with the plane is the situation anyway better than with a copter becaue it can glide

During testing I'm not going to go too far and when it's thoroughly verified, this time can be set long enough.
Roman

PatrikE · Post by **PatrikE** » Wed Mar 06, 2013 11:28 pm

Hi.

My Theory of how Rth for plane should work.
Stage 1
Start to navigate.
CLIMBTHROTTLE & GPS_MAXCLIMB untill plane reached GPS_ALT_HOLD

Stage 2
Navigate to home
CRUICETHROTTLE, Maintain GPS_ALT_HOLD .

Stage 3
CRUICETHROTTLE, Maintain GPS_ALT_HOLD and Cirkulate around homepos until
RTH id disabled or FAILSAFE_OFF_DELAY

You can remove the pindefines for SERVO_4_PINMODE. (row347.... in def)

Code: Select all

  #if !defined(MONGOOSE1_0) 
    #define SERVO_4_PINMODE        //  pinMode(12,OUTPUT);
    #define SERVO_4_PIN_HIGH       //  PORTB |= 1<<4;
    #define SERVO_4_PIN_LOW        //  PORTB &= ~(1<<4);
  #endif

Or change row 347 to

Code: Select all

#if !defined(MONGOOSE1_0) && !defined(RCAUXPIN12)

It will free D12 from servo.
Makes RCAUXPIN12 will be possible to use.

Sebbi · Post by **Sebbi** » Thu Mar 07, 2013 3:08 am

rbirdie001 wrote:Hi Patrik,
thanks for the correction, now RC read is OK!
Is there any reason why this your work isn't merged in the project? (I noticed that otherwise you have in Multiwii many pieces of the code )

I also hope this can be part of the normal code soon and the zip file trading stops. Maybe in the development version for 2.3 protected with a default off config-define-switch?

rbirdie001 wrote:I already tested version above (3.3.2013) in flight on Multiplex Easystar II with MPU6050 - in that first step WITHOUT GPS just for stabilization and it works very well!
Now I'm going to connect GPS and hopefully this weekend will test with GPS.
Sorry, again I have some questions:
-I suppose that main goal of RTH function is to save plane which lost RC link (at least I'd like it work this way ). I'm not sure if it's already implemented or at least planned to allow initialize RTH when failsafe is activated. If yes, how?
BTW: I already experienced confusion after failsafe routine change in last dev's but now I readjusted enpoints on my TX and think it was a good change. This was the reason why I don't use SUM PPM yet. I made SUM PPM output on my RX but when signal is lost, there are crazy pulses. I tested it with the old FS routine, but when I disconnected TX, it didn't activate and plane got completely crazy. Now it should be better but I yet didn't verify it.

I am using it in the same way as you do. Easystar II with NanoWii (mpu6050) + I2C GPS. For failsafe I use FrSky (and also for telemetry) which should sometimes in the future enable a switchable RTH function. The normal failsafe just isn't optimal for airplanes (that's why I set it via the FrSky receiver). It should at least circle around slowly decending or ideally come back and do that at the home position when the signal is lost.

rbirdie001 wrote:-Stabilization of the plane generally works great on PITCH and YAW but I'm not 100% happy with my settings on the ROLL. When my plane gets some influence from a wind or thermals and starts (even slowly) move in ROLL axis, for a while is nothing happenning and then sudendly very strong correction comes by the ailerons and plane returns to level. This is unpleasant in recorded video because it looks like taken from the cart on stony road while I prefer it smooth. I'm not sure what direction to move PIDs and averaging filtering factor. I want to lower P and increase I and D. Whant do you think? Any ideas wellcome.
Again thank you for your work, I'll let you know how was the result of the tests...
We already had few nice days and I'm looking forward for another. In Sweden you probably will have to wait longer...
Roman

While my Easystar seems to be pretty stable with the default, I'd like to know what the procedure for PID tuning looks like for an airplane. The other thing is the acc calibration for angle mode ... I calibrated it so it looks level and that's enough to "safe" it from hairy maneuvers, but it's certainly not the same as "fly level at current throttle" (more like altitude hold I guess). So there is still a lot that can be done for airplane support (especially when GPS is available) in MultiWii. Looking forward to gettings things done this season ;-)

rbirdie001 · Post by **rbirdie001** » Mon Mar 11, 2013 12:16 am

Hi Patrik,
I noticed that you noticed

that GPS_PROMINI_SERIAL is some way not working or at least not signalling properly in MWC 2.2 and related builds.
I just tested fresh 2.2 and it still not work, unfortunately your last fixed wing nav. build from 3.3.2013 is based on MWC 2.2 so it doesn't work neither.
I'm now stuck on it with testing FW navigation, because I'm still waiting either for postman to carry me arduino for I2c GPS connection (but anyway in the plane I'd like to use rather serial GPS and GPS_PROMINI_SERIAL although in my tricopter I'm using I2C) or for correction of this bug in 2.2.
Have you done any further tests or discovering what's wrong with the serial GPS? Sorry, I don't have chance to find it myself.

@Sebbi:
I was also curious about proper accelerometer calibration for different flying speeds of a plane but some way it's not so critical. I calibrated with my Easystar lying on the floor at home and with this calibration I fly both slow and fast - both is quite OK. In fact if I let my Easystar glide with ACC active, it flies very slow - much slower than I'd be able to control it without stabilization and I never experienced any unpleasant behaviour.
Roman
P.S. I think that in real English is a plane "she" but in my language "it" so I'm bit confused about it.

PatrikE · Post by **PatrikE** » Mon Mar 11, 2013 2:00 am

Hi Roman,

Last time i tested The serial gps on ProMini worked.
It was only the Led who dosn't show status.

On the plane it's easy to check.
If you enable RTH, stage #1 is to climb to RTH altitude.

If elevator goes up in RTH mode you have GPS fix and home position is set.
Ready to take of.
That's how iw'e been doing.

Serial Gps is #¤%E#&/¤ hard to debug on a 328 because serial port is ocupied!....
I have bougt a minim osd to be able to see whats happening in air.

PatrikE · Post by **PatrikE** » Mon Mar 11, 2013 3:36 am

After a quick check...
#define GPS_LED_INDICATOR
Uses in multiwii.ino {STABLEPIN_ON;} else {STABLEPIN_OFF;}

And in def.h in ProMini section.

Code: Select all

#if !defined(MONGOOSE1_0)
    #define PINMODE_LCD                pinMode(0, OUTPUT);
    #define LCDPIN_OFF                 PORTD &= ~1; //switch OFF digital PIN 0
    #define LCDPIN_ON                  PORTD |= 1;
    #define STABLEPIN_PINMODE          ;
    #define STABLEPIN_ON               ;
    #define STABLEPIN_OFF              ;
  #endif

Means Promini can't use GPS_LED_INDICATOR.
Same goes for atmega32u4 (Promicro)

To use A2 as GPS_LED_INDICATOR You can insert this in your def..

Code: Select all

  #define STABLEPIN_PINMODE pinMode (A2, OUTPUT);
  #define STABLEPIN_ON PORTC |= (1<<2);
  #define STABLEPIN_OFF PORTC &= ~(1<<2);

Or for D13.

Code: Select all

       #define STABLEPIN_PINMODE          pinMode (13, OUTPUT);
    #define STABLEPIN_ON                   PORTB |= (1<<5);
    #define STABLEPIN_OFF                 PORTB &= ~(1<<5);

In V2.1 LEDPIN was used instead.

rbirdie001 · Post by **rbirdie001** » Mon Mar 11, 2013 10:31 pm

PatrikE wrote:To use A2 as GPS_LED_INDICATOR You can insert this in your def..
Code: Select all
  #define STABLEPIN_PINMODE pinMode (A2, OUTPUT);
  #define STABLEPIN_ON PORTC |= (1<<2);
  #define STABLEPIN_OFF PORTC &= ~(1<<2);

Patrik, thanks for explaining, I tested this and it works so I hope that my plane soon will be "RTF" for a better weather.

To cover all my needs I need to do more pin "manipulations" but this my "amateur" modification doesn't work, I don't know why:

Code: Select all

  #define STABLEPIN_PINMODE pinMode (A6, OUTPUT);
  #define STABLEPIN_ON PORTC |= (1<<6);
  #define STABLEPIN_OFF PORTC &= ~(1<<6);

I know, that it's probably arduino basic but unfortunately I miss those basics

.
I'll try to google little but short explanation could help a lot!
Thanks for understandig!
Roman

Sebbi · Post by **Sebbi** » Mon Mar 11, 2013 11:31 pm

You seem to use a Leonardo (32u4) Arduino, correct? From the documentation (http://arduino.cc/en/Main/arduinoBoardLeonardo) A6 - A11 correspond to digital pins 4,6,8,9,10 and 12 which are on PORTB and PORTD (see http://arduino.cc/en/Hacking/PinMapping32u4).

A working, but slower way to switch on/off Arduino pins is by using the Arduino functions. So the code would become:

Code: Select all

  #define STABLEPIN_PINMODE pinMode (A6, OUTPUT);
  #define STABLEPIN_ON digitalWrite(A6, HIGH);
  #define STABLEPIN_OFF digitalWrite(A6, LOW);

Should be fine with LED switching as this doesn't require high speed.

rbirdie001 · Post by **rbirdie001** » Tue Mar 12, 2013 12:38 am

Sebbi wrote:You seem to use a Leonardo (32u4) Arduino, correct? From the documentation (http://arduino.cc/en/Main/arduinoBoardLeonardo) A6 - A11 correspond to digital pins 4,6,8,9,10 and 12 which are on PORTB and PORTD (see http://arduino.cc/en/Hacking/PinMapping32u4).

A working, but slower way to switch on/off Arduino pins is by using the Arduino functions. So the code would become:
Code: Select all
  #define STABLEPIN_PINMODE pinMode (A6, OUTPUT);
  #define STABLEPIN_ON digitalWrite(A6, HIGH);
  #define STABLEPIN_OFF digitalWrite(A6, LOW);
Should be fine with LED switching as this doesn't require high speed.

No, no Leonardo, I'm using Crius SE and Crius LE boards which are equipped witn normal 328P processor. I just didn't catch why the same line works for A0, A1 and A2 with corresponding numbers but not for A6 and A7?

I'll try HIGH and LOW functions, for LED it's really not a problem but won't it "eat" cycle time for other computing?
Roman

rbirdie001 · Post by **rbirdie001** » Tue Mar 12, 2013 9:52 am

Because after a "demo" spring day on this Sunday again came freeze and snow

I keep on with "theoretical" preparations about RTH testing so here is few of my thoughts and also questions:

PatrikE wrote:Hi.

My Theory of how Rth for plane should work.
Stage 1
Start to navigate.
CLIMBTHROTTLE & GPS_MAXCLIMB untill plane reached GPS_ALT_HOLD

I suppose that if current altitude at the time of RTH activation is higher than GPS_ALT_HOLD, plane will not descent to it and commit directly Stage 2 at current altitude. Right?

Stage 2
Navigate to home
CRUICETHROTTLE, Maintain GPS_ALT_HOLD .

Stage 3
CRUICETHROTTLE, Maintain GPS_ALT_HOLD and Cirkulate around homepos until
RTH id disabled or FAILSAFE_OFF_DELAY

I suppose that circling diameter will be defined by GPS_MAXCORR, right?

If the plane won't descent to GPS_ALT_HOLD at Stage 1 (I think it shouldn't - there can be some hill or high building), isn't there at Stage 3 good time for descending? This can help to find the plane when control is lost at high altitude and you are trying to find it after RTH visually. Also beeper should beep at this time.
If the CRUICETHROTTLE is applied unconditionally and at the same time descending to GPS_ALT_HOLD, plane can experience stress from too high speed. What about cutting engine during descent and resetting CRUICETHROTTLE when GPS_ALT_HOLD is reached?

What will happen after FAILSAFE_OFF_DELAY ? The motor should stop but will the navigation control and circling continue while gliding or will servos just go to center and "let happen the will of god"?
If the navigation continues, there is good chance that plane can more-less "autoland" at home site - maybe not perfectly but it can minimize damage and risk of loosing it...
It's not necessary to answer all now, just to bring ideas. (But answers would be also nice

)

Roman

PatrikE · Post by **PatrikE** » Tue Mar 12, 2013 5:01 pm

I suppose that circling diameter will be defined by GPS_MAXCORR, right?

Correct!..

And with this addition it will kill motor when it reached home.
And return to home repetedly until.........

Code: Select all

     }else{ // Reset Climbout Flag Ready to Navigate
        if (f.CLIMBOUT_FW && GPS_AltCorr > 0 )f.CLIMBOUT_FW=0;
        
        if (f.GPS_HOME_MODE && !f.CLIMBOUT_FW && GPS_AltCorr <=0 ){ //If we are higher than RTH alt.
          if (GPS_distanceToHome >100){ GPS_angle[PITCH]=0 ;}       // RTH Nav Stage, No altitude correction
          if (GPS_distanceToHome <100){ rcData[THROTTLE]= 1200;}    // RTH Decend only within 100 meters
          if (GPS_distanceToHome <5 && GPS_AltCorr >=-5 ){f.ARMED = 0;} // Home is within 5 meters Kill motor and glide.
        } 
     }

Actually Testing weather today.. 8-)

And i'm satisfied.
My computer is working on a video atm.
Will upload it later tonight if the computer don't take fire first!...
Will also update and upload the code later.

PatrikE · Post by **PatrikE** » Tue Mar 12, 2013 5:20 pm

The computer survived...

http://youtu.be/tgVza2NYfb4

Kayle · Post by **Kayle** » Tue Mar 12, 2013 5:51 pm

Hi Patrik,

thats looking fantastic. Thanks for your work on RTH for Planes.

Kayle

rbirdie001 · Post by **rbirdie001** » Tue Mar 12, 2013 9:08 pm

Hi!
Thanks for your work, the video really looks great!

I'm really curious when the weather (and family

) allows me to do some testing.
Tell me how is possible that in Sweden you had so nice day when I had here about a thousand kilometers south icy wind and snowing

.
Anyway I'm still fidling with LED indicator on A6

.
Good luck with the new version, I'll load the recent available at the time of testing and of course let you know about the result.
Roman
P.S. Just a little ask: As I'm coping with arduino code really hardly (probably I'm not the only one

) I'm interceding to make the code as much as possible "dumb resistant" so changing options by #DEFINEs in config.h. When are people like me patching the code, it's very risky!

Thanks!
Roman

crashlander · Post by **crashlander** » Tue Mar 12, 2013 9:43 pm

Hello,
promising video!
Patrik:
- Should I set #define GPS_RUDDCORR to 0 for Flying Wing (since it has no rudder)?
- I have not yet tested current (before today) version, but with version from the end of the last year my wing often went into spiral turn (uncoordinated turn with losing lot of alt.) when enabling RTH (turn to home).
- the code above will actually disarm (and not only kill TH)!? What will than be necessary to arm it again and take full control?

Code: Select all

if (GPS_distanceToHome <5 && GPS_AltCorr >=-5 ){f.ARMED = 0;} // Home is within 5 meters Kill motor and glide.

I will definitely test your latest version when weather permits (hope this weekend).

Best regards
Andrej

Sebbi · Post by **Sebbi** » Tue Mar 12, 2013 10:07 pm

PatrikE wrote:The computer survived...
http://youtu.be/tgVza2NYfb4

Nice work! From the video it doesn't look like the plane is able to circle above the home point yet. It's just passing through, decending, returning and on second home-pass-through it disarms. Right?

May I also suggest that it would be nice if we had some kind of loiter mode where the plane would circle above a point (=HOME) and then slowly decents? For when you "lose" visual contact to your plane due to extreme height and want to have it back ;-)

PatrikE · Post by **PatrikE** » Wed Mar 13, 2013 12:40 am

@Sebbi

Nice work! From the video it doesn't look like the plane is able to circle above the home point yet. It's just passing through, decending, returning and on second home-pass-through it disarms. Right?

With the latest added If's it behaves like that.
Without them it will cirkle at home..
Different methods should maby be used for FailsafeRTH and RTH enabled by user .
For FailsafeRTH you probably want the plane to come down if you can't controll it!

PosHold will send the plane to a lotier and pass thru the set point repetetly.(Maintainng same altitude)

A higher GPS_MAXCORR will send it to a harder Banking turn.
It is set very moderat as default.

PatrikE · Post by **PatrikE** » Wed Mar 13, 2013 12:57 am

@crashlander

If the plane dont have a rudder to controll It doesn't mather what you set GPS_RUDDCORR to.
Just leave it as it is.
I use a ailerion/elevator setup and GPS_RUDDCORR has no impact then.

after passing home and moror is disarmed you can reArm it again.
If it comes within 5 meters from home it will be disarmed again.

I always use AUX Arm switch on my plane.
Then i only need to lower throttle to Minthrottle to rearm.
And disable RTH to take over.

To low speed and to High GPS_NAVCORR Can send it to a diving spiral.
Elevator dont have enogh Punch to keep it up!.

PatrikE · Post by **PatrikE** » Wed Mar 13, 2013 1:00 am

@Roman,

Maby it could look like this for ProMini in config?.

#define GPS_LED_INDICATOR A6

I can add it in my Beta version.

PatrikE · Post by **PatrikE** » Wed Mar 13, 2013 6:53 pm

branches/PatrikE/MultiWii%20Plane%20GPS.rar
Latest version with Gui.

Settings from Gui.
Magdecl
Set Minthrottle to 1000
and Max throttle to 2000.

!!! A Warning !!!
If you dont use #define SAFETY_SWITCH
And enable RTH The engine will Start with
#define CLIMBTHROTTLE 1800 // Max allowed throttle in GPS modes .
So keep sensitive bodyparts away from Prop!!!!.

rbirdie001 · Post by **rbirdie001** » Thu Mar 14, 2013 11:35 am

PatrikE wrote:@Roman,

Maby it could look like this for ProMini in config?.

#define GPS_LED_INDICATOR A6

I can add it in my Beta version.

Hi Patrik,
you are so nice that you think of me

but I ment little more serious things than LED (even despite all advices from you and Sebbi this indicator doesn't work on A6,A7 and I don't understand why).
I ment that it would be nice to set in config.h whether we want #DEFINE ACTIVATE_RTH_WHEN_FAILSAFE or #DEFINE DISARM_WHEN_HOME_REACHED etc. This options now available via patches you kindly posted can be very useful for many people not so familiar with the code...
Let me please explain one more thing maybe problematic for some users:
As you probably have enough AUX channels available, you prefer arming via AUX switch so it's not a problem for you when the plane disarm e.g. when home is reached. Unfortunately some people (like me

) have only 6 channel radio so they can have only 2 switches. I have only AUX1 with ON/OFF - this I use for passthru mode and AUX2 with 3 states and this I have reserved for ACCELEROMETER and RTH activation. This means that for arming I have to use YAW or ROLL stick but because I have both ailerons and rudder, I can't do it because fulll stick command could make my plane fall into spiral. I could maybe use for arming the same switch as for passthru mode, but I foresee possible problems when I get confused and forget something. I'd more prefer that after reaching home would automatic only kill the throttle but keep armed. This is just my oppinion, other can also comment it!
Thank you for hearing us!
Hopefuly I'll test it this wekend!
Roman

PatrikE · Post by **PatrikE** » Thu Mar 14, 2013 1:02 pm

Hi Roman,

First goal is to get a Confirmed workin RTH.
Atm i only know about 1 more person besides me who have tested it.

When we have a stable RTH function we can add functions.

DISARM_WHEN_HOME_REACHED Should alredy be added will come in next ver.

You can find and Comment this code in MultiWii.ino as a start.
if (GPS_distanceToHome <5 && GPS_AltCorr >=-5 ){f.ARMED = 0;} // Home is within 5 meters Kill motor and glide.

Normally i have all flightmodes on AUX2.
Passthru | Gyro or ACC | ACC/RTH
and on AUX1 ARM/DisARM

My TX looks like a Hedgehog
BUT!!!!
I don't like flipping a dozen of swithes :roll:

crashlander · Post by **crashlander** » Thu Mar 14, 2013 1:33 pm

@Roman: I still have pass-thru enabled on my TX but in my case it is not really useful (never used) since my FW is now FrankenWing and it is not joy to fly it without gyro/acc support and specially hand-launch is (nearly)impossible without gyro support so after first starts/PID tuning you can remove that mode.
And secondly I also use HK Orange receiver with only 6 channels but have TX programed so that I get two three position aux channels.

Regards
Andrej

rbirdie001 · Post by **rbirdie001** » Thu Mar 14, 2013 2:16 pm

PatrikE wrote:Hi Roman,

First goal is to get a Confirmed workin RTH.
Atm i only know about 1 more person besides me who have tested it.

If the Norwegian metheorologists are right you should have after this weekend another report...

You can find and Comment this code in MultiWii.ino as a start.
if (GPS_distanceToHome <5 && GPS_AltCorr >=-5 ){f.ARMED = 0;} // Home is within 5 meters Kill motor and glide.

I suppose that in that line can be {f.ARMED = 0;} replaced with something else which just set throttle pulse to MINCOMMAND and keep armed.
After signal recovery or switch off the RTH would engine again follow the throttle stick.

Another idea (not for now, but for the future!):
It would be nice if BEEPER confirms saving the valid home by special sound. This will prevent people to rely on RTH which actually can't be used because of disconnected gps, bad fix at saving home or simply not recognized stick combination to save home.

BTW: I really don't know why but A6,A7 DON'T work as an LED output. I tested everything , but NO! (Maybe because older DIL Atmel processors in UNO boards didn't have those pins at all, or there is some hidden code causing conflict, but NO NO NO, it doesn's work!

Roman

rbirdie001 · Post by **rbirdie001** » Thu Mar 14, 2013 10:51 pm

Hi Patrik,
just loaded newest version into my plane, GPS blinking (on A2

) OK, after setting home and activating RTH motor started so everything looks ready, but tomorrow we should have -6 degrees and 7m/s wind. I'm very keen for flying, but probably I'll wait for this weekend - should be warmer and less wind.
Simple question:
Should be for RTH activated also ACC checkbox, or not?
Thanks!
Roman

PatrikE · Post by **PatrikE** » Fri Mar 15, 2013 8:09 am

Acc must be activated for GpsCode to be active.
Only throttle works without Acc and that's a "Feature Speciale " Read Bug....

I prefer Horizon before Angle mode.

Lucky you...
My thermometer showed -24.3 this morning!..
Where did the spring go?..
Must be a new record for March 15:e

But the sun warms up to almost zero in the afternoon.

Mis · Post by **Mis** » Fri Mar 15, 2013 4:06 pm

I really don't know why but A6,A7 DON'T work as an LED output.

The A6 and A7 pins on ALL mega328 based boards is ANALOG INPUT ONLY. You cant use these pins for any digital input or output. This is a CPU specific, and can't be ovreeiden.

Kayle · Post by **Kayle** » Fri Mar 15, 2013 4:52 pm

Mis wrote:
I really don't know why but A6,A7 DON'T work as an LED output.

The A6 and A7 pins on ALL mega328 based boards is ANALOG INPUT ONLY. You cant use these pins for any digital input or output. This is a CPU specific, and can't be ovreeiden.

Sure. You can use analog Pins as digital input and output. Read the mega328 Datasheet.

Kayle

crashlander · Post by **crashlander** » Fri Mar 15, 2013 8:16 pm

Before we lose the subject of this thread...
Today I successfully tested Patrik's latest RTH code on my Flying Wing!
The wing returned successfully every time (at least 5 times) from 100 to 150m from home and started to circle around home point.
I did my tests into couple directions (into the wind and with wind direction).

Tomorrow I will try to move further from home point and repeat the test.

Best Regards
Andrej

BTW: AFAIK you can use any port on atmega328 as digital I/O, but only some as analog input and only some as analog output (PWM), and only a few (2?) can be interrupt driven inputs

PatrikE · Post by **PatrikE** » Fri Mar 15, 2013 8:32 pm

crashlander wrote:Today I successfully tested Patrik's latest RTH code on my Flying Wing!
I did my tests into couple directions (into the wind and with wind direction).

This makes me glad to hear.

gena_g · Post by **gena_g** » Sat Mar 16, 2013 10:32 am

Hello Patrik's. Will work on the RTH flywing?

PatrikE · Post by **PatrikE** » Sat Mar 16, 2013 11:50 am

Check crashlanders post 2 posts earlier.
He use a Flying Wing!

The code works on.
Normal Airplanes Both Ailerion and rudder controlled planes is confirmed working.
Flying Wing is confirmed by crashlander without crashlanding;)

Sebbi · Post by **Sebbi** » Sat Mar 16, 2013 1:12 pm

Oh boy, the sun is shining, but I have other things to do ... WANT to finally try this ;-)

P.S.: I know MultiWii has no support for air speed sensors, but can/will the gps speed be used to influence throttle? Maybe a stall condition could also be detected automatically if the throttle is too low?

PatrikE · Post by **PatrikE** » Sat Mar 16, 2013 4:28 pm

Iw'e used Gps speed earlier to prevent stall.
But this is stripped down to verify the basics.

The small processors is getting really filled up.
9 Dof and gps don't fit toetger with airplane. (Ex. CRIUS SE)
Baro needs to be undefed . (Not used for FW Nav)
And then it's on the limit.

I saw someone implemented a airspeed sensor for a while ago.
Can be usefoul on planes.

But we wlll need to step up to Mega's to be able to add more advanced functions.
Waypoints etc...

Sebbi · Post by **Sebbi** » Sat Mar 16, 2013 5:58 pm

I am using an I2C GPS and there seems to be enough space left on the 32u4 (Leonardo) to do something. With serial GPS it barely fits ... I know :/

crashlander · Post by **crashlander** » Sat Mar 16, 2013 6:28 pm

Today I/we tested two FW one mine (same as yesterday) and another one.
While mine still works O.K., the other one has sometimes issues with too aggressive "vertical" turns.
Exact symptoms are: after RTH activation it starts to turn but it does not add enough elevator so it gains to much speed (it starts to flutter) and looses to much height for comfortable observers.

So the next time we must experiment with reducing GPS_MAXCORR and/or adding more ELEVATORCOMPENSATION or maybe change GPS_NAVCORR!?

What do you suggest?

Best Regards
Andrej

rbirdie001 · Post by **rbirdie001** » Sat Mar 16, 2013 7:25 pm

Hi guys!
also here was today good day for testing!
I finally tested my Easystar II with navigation (about 10 flights) and it quite WORKS!!! just there is a BUT:
I have problems with height/speed/engine control - maybe similar to Crashlander's friend plane.
After activating RTH plane makes always nice turn to my direction and flies towards me -that's great!- but when it reaches home and starts circling, it sets elevator down and descebding while circling, engine is strange way changing thrust but generally there is too much thrust and plane is fast descending so it's having too high forward speed, so wings are flattering and if I wouldn't passthru control, it would have hard crash.
I commented the line in the code which disarm motor when 5m from home is reached so motor is still controlled by automatics, but it changes thrust without obvious logic.
This "nose down" behaviour is very strange because when I let the plane fly in HORIZON, it flies perfectly in the level keeping the same height not much dependent on the engine thrust. It seems that "elevator down" is caused by navigation code... :?:

I recorded some videos so after I analyze them, I'll write more details but generally I think that direction navigation works very nice but height and the speed control needs some more work.

Once more: BIG THANKS TO PATRIK, NICE WORK!
Serial x I2C navigation: I use I2C for copters without problems. Here I liked that with serial GPS is electronic so compact but if the code doesn't fit memory anymore, I don't have problem with changing to I2C GPS. Generally it's easier and cheaper solution, than throw away all my 328P boards (Crius SE and LE) and buy MEGA ones for all my planes.
See you, guys!
Roman

crashlander · Post by **crashlander** » Sat Mar 16, 2013 7:50 pm

I agree that TH control when near home is funny but I had no issues with wing pitching down near home or after motor disarming.

Regards Andrej

rbirdie001 · Post by **rbirdie001** » Sun Mar 17, 2013 6:54 pm

Hi Guys,
as promised I posted short video showing results of RTH testing yesterday.
Here it is: http://www.youtube.com/watch?v=j015U0MTptE&
Hear also sound of engine, servos and the wind, it's interesting!
As I already wrote, RTH itself works fine, but when home is reached, for short time engine slows down, but then speeds up again and plane starts pitching down at high throttle so is gaining too high speed and loosing too much height. If I wouldn't save it manually, it would have crashed within few seconds.

In the software I commented the line which disarms when the home is reached, the rest is unmodified.
Accelerometer is calibrated on the ground such, that if I fly in ACC mode, plane flies perfectly without pitching down so this must be caused by influence of navigation code.
Maybe ACC calibration even more "nose up" can help but anyway I'd like to know the following:
Is threre in the current code active some control of height based on GPS data after home is reached?
Is there any control of speed? (OK, I know that we know nothing about the wind...

At least check for maximal safe speed.)
At least simple idea for possible "improvement" - what about controlling engine thrust depending on elevator position?
If elevator is "UP" throttle would proportionally grow, if it's "DOWN" engine would stop. This would so-so control the speed...

Elevator itself could be controlled via PID (maybe existing code for multicopters could be used)? from GPS height :?:

If my ideas are unusable, please excuse, I'm not coder... :mrgreen:

Anyway I'd say that RTH is a working code, Patrik, isn't it?

Regards
Roman

PatrikE · Post by **PatrikE** » Sun Mar 17, 2013 9:11 pm

Anyway I'd say that RTH is a working code, Patrik, isn't it?

I guess so

Ill look over the code and try to find out what goes wrong.
I have seen some some things that can be wrong.

I had a issues with my plane and broke some headers to the servos and must look over it to.
An Unsecured Lipo is Bad! I know!... :oops:

I compared I2CGPS vs Serial.
I2C save ~600b compared with Serial.

I2C it will be to get some free memory in the future.

Ps
Enable SAFETY_SWITCH AUX4 and run throttle in passthru.
If you dont have AUX4 It's probably outputting 1500µs and block will AutoThrottle.

Experiment with GPS_ALTCORR.
To remove Pitching.
It's simply a P factor.

I'll check the video when i get home from work.

rbirdie001 · Post by **rbirdie001** » Sun Mar 17, 2013 10:49 pm

Enable SAFETY_SWITCH AUX4 and run throttle in passthru.
If you dont have AUX4 It's probably outputting 1500µs and block will AutoThrottle.

Do I understand well, that I should use the same switch as for passthru (in my case AUX1)? Then if that switch is on HIGH and throttle in LOW, MWC will arm?

Experiment with GPS_ALTCORR.
To remove Pitching.
It's simply a P factor.

I will, but it would be helpfull to know algorithm what altitude is a "requested setpoint" in which RTH stage. I don't think that my pitching down is just bad "proportional factor", it more looks like "wrong requested altitude"

I'll check the video when i get home from work.

Poor you, you work on Sundays so late evening?

What's your occupation?
Regards
Roman

crashlander · Post by **crashlander** » Mon Mar 18, 2013 5:45 am

rbirdie001 wrote:
E
Poor you, you work on Sundays so late evening? What's your occupation?

SysAdmin?! It comes to mind.

Regards
Andrej

PatrikE · Post by **PatrikE** » Mon Mar 18, 2013 10:12 am

crashlander wrote:
rbirdie001 wrote:
E
Poor you, you work on Sundays so late evening? What's your occupation?

SysAdmin?! It comes to mind.

Regards
Andrej

Kind of..
I'm a
Babysitter/Programmer/Operator/Instructor.
Sercice a group of NC-controlled machines.

And this is my assistent.
ABB IRB 7600 (alias "Robert")

And when everything behaves i have time to do other things. 8-)

crashlander · Post by **crashlander** » Mon Mar 18, 2013 2:26 pm

Some of my saturdays tests on video with OSD (my FW).
First try aborted due to overspeed and flutter
I enabled RTH 100m high and the wing went down to 46m with a lot of TH...
-other tests went O.K.

Camera drop-outs due to electrical interference (but OSD stays O.K.)

http://www.youtube.com/watch?v=BKQHRYnw ... e=youtu.be

Regards
Andrej

EDIT: After watching that movie many times and "replaying" unrecorded video of friends wing

I would dare to say that Airplane RTH code is somehow aiming for 50m over home point and if the wing is much higher and close it will start to descend with sharp angle in which vertical speed can not be controlled with GPS lag?!

PatrikE · Post by **PatrikE** » Mon Mar 18, 2013 5:21 pm

Should use separate Max Angle for climb and descend.

Todays limit of angle

Code: Select all

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

Could test to change one of the limits.
GPS_MAXCLIMB*10 to GPS_MAXCLIMB*5
It will limit to Half throw in one direction.

Not shure if you need to change min or max in the constrain.
GPS Lag and lack of PID regulator + Low resolution of Altitude makes Perfect altitude difficult to achieve.

But limiting descend angle can make things better.

There is a error in throttleHandeling i have to check to.