Altitude Hold improvement solution

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

Re: Altitude Hold improvement solution

Postby nhadrian » Sat Dec 29, 2012 9:08 pm

Hi Dramida.

I'm not a coder too... only a mechanical engineer.
To understand better, these correction values are added to default PID values, so if you set 0 for all, it means that the code uses the same PIDs for rising than for hovering (default by EEPROM).
Till now I don't have any guide lines, I have to test a lot to figure out the influences of the corection values. But, you can set even negative numbers which mean you reduce the default PIDs. (But don't set higner values in negative than values in EEPROM!!!)
I made these values because I'm sure the perceft PID for HOVERING is not good for rising. And values for rising is not good for descending... (I already handle this difference in code, that's why we have only 3 corrections).

I hope I could help a bit.

BR
Adrian

ps.: once I finished the code itself I'll start to test out the perfect corrections. Or at least some guidelines.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby dramida » Sat Dec 29, 2012 10:55 pm

I don't belive in magic :)
To further test your code, i need to understand how it works, as a principle.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby nhadrian » Sun Dec 30, 2012 7:31 am

Generally, you should understand what PID control loop itself makes in case of baroPID regulation.

1) P value is a proportional value, generally spoken, the far the copter is from target alt the more correction in throttle applied.
2) I value is an integrator. That means if copter can't reach target, the I value gets bigger and bigger, because integrates the proportional part.
3) D is not a real derivative part in case of baro!!! Instead it calculates a velocity based on baro/acc sensors. And than corrects the BaroPID according to velocity (that's why I inserted here a correction according to target vario!).
-----so when you start to fine-tune basic BaroPID for hovering, you should understand these first.--------

4)In my code, when target vario is applied (not hovering), it means that code increase/reduce AltHold value in neccessary extent. AltHold value is the input for BaroPID regulation (target for regulation). And the BaroPID regulation starts to follow the changes. At this point I'm not sure where to start tune corrections, in the morning I had the idea of raising I instead of P. I'll try that too.
But first of all I want to finish the base code with working failsafe!!!

I hope my description is clear (at least for me it is... :P).
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby dramida » Sun Dec 30, 2012 9:48 am

Thanks Adrian
You wrote that between ALT p and PIDALTP and consequently I and D, there is a corelation that in my mind shouldn't be as there are two different loops:
Inner P-I-D loop controls altitude through Baro and AccZ as inputs
Outer P-I-D loop regulating speed of altitude variation corelated to throttle stick position as input.

how far apart from your code am i?
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby nhadrian » Sun Dec 30, 2012 10:26 am

Hi,

no you are wrong. There is only one loop! The BaroPID regulates according to AltHold value, it alwasy would stay in there.
The difference in hover and descending/rising is that the target of AltHold number is changing according to desired vario (this is not a PID loo, it is simple relation between throttle stick position and the AltHold changing). Because PID regulation would keep the AltHold altitude, it'll follow the changes, causing copter to rise/descend.
And since I'm using a 25Hz calculation for AltHold changing, it is accurate enough. Clearly spoken if I want 150 cm/s (ie. full throttle and max vario is set to 150 cm/s), than AltHold value will change with 150 in every second.

is it clearer now?

BR
Adrian

ps.: the reason I think it is neccessary to use the compensations is that when not hovering, the regulation should work like a "follow mode" because the target is always changing (AltHold number).

Otherwise, I handled all situations like switch between hovering/rising, etc... by code, to have smooth transition as possible.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby nhadrian » Sun Dec 30, 2012 1:04 pm

Hi,

I have finished work on advanced Failsafe routine with RTH!!!
Here is the result:
http://www.youtube.com/watch?v=C06iXXJfrDo

I attached the code. Please note that this is fully experimental!!!! TRY IT ON YOUR OWN RISK, IN A SECURE ENVIROMENT!!! Also the define for Dramida is included, when copter is higher than RTH it maintains that altitude instead of descending to altitude. If commented RTH works as previously.(RTH_KEEP_ALT)

Here is how it works:
--- if defined the FAILSAFE_RTH, there are two possibilities:
--------1) if the GPS signal is good (is GPS fix and more than 5 satellites), when failsafe, copter starts to come home with the defined options (vario, altitudes) and when reach home, descends to defined altitude and stay there
--------2) if there is no good GPS signal, it starts to descend slowly (according to Failsafe vario defined), and when reaches ground or defined period ends, motor stops (go disarm).

according to these functions I RECOMMEND this small test before try it in air:

1) turn on the copter in a room or with GPS disconnected. Hold the copter on the ground strongly and activate it. Apply at least hovering throttle or even more a bit, and turn off the TX. PLEASE BE PREPARED TO DISCONNECT the battery once problem occures!!!!
If everything works well you should hear that RPM decreases, and motors stops after a while. Turn on the TX again, and while still holding the copter on the ground, arm it again. If everything works, after second try it should arm again and work as it should.

2) now go outside. Turn on copter and wait for good GPS signal. Hold the copter again to the ground strongly and arm it. Apply hovering throttle again, and turn off the TX. PLEASE BE PREPARED TO DISCONNECT the battery once problem occures!!!
If everything works well you should hear changing in RPM, a bit more throttle. That means copter tries to reach RTH altitude and function is active. Now, turn on TX again! Depending on the TX switch-back time, after 2-3 s you MUST HAVE full control again. Otherwise something went wrong, DO NOT TAKE OFF!!!!!!!! If you have control again, try this tests at least 2-3 times. Than you can have a big breath and take off..... GOOD LUCK!!!

Please note the followings:
--I tested it on a CRIUS AIO Pro with extension board (UBLOX GPS). but should work with I2C receivers too. I donn't have any to test... :( Could somebody check the code and confirm it works???
--I always tested in ANGLE mode. It should work in ACRO mode too (there is a switch to ANGLE mode when failsafe), but could somebody confirm? My copter is too fast and agile to fly in ACRO mode when higher distances...
--since I tested with only one type of configuration, there could be still some BUGs in code. PLEASE BE EXTREMELY CAREFUL for the first few times!!! ALWASY BE PREPARED for malfunction and before take-off, think through the different possible outcomes!!! That helps a lot solving dangerous situations!!!! (I'm always do so even if I flown my copter hundred times...)

If you have any suggestions, questions, problems, contact me.

BR
Adrian
Attachments
Multiwii dev_r1282_NHA_r8_FINAL.zip
(141.06 KiB) Downloaded 994 times
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby subaru4wd » Tue Jan 01, 2013 7:46 pm

I know the filename says r1282, but is that the Dev version your R8 is built off of?

just curious, i wanted to check the changelog. Thanks.
subaru4wd
 
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Altitude Hold improvement solution

Postby nhadrian » Tue Jan 01, 2013 9:22 pm

Hi,

It is based on the r1282 indeed (I used the files of Multiwii_shared in r1282 state. And then included my changes.) The following r8 means it is the 8th change by me.

BTW I have already merged with the latest r1303. I also included some LED_PATTERN to VBAT/FAILSAFE additions in it, and tried to make all my changes even clearer and add more detailed descriptions.
Unfortunatelly today there was terrible weather in Hungary, so couldn't test if all functions works properly (theoretically it should since there weren't any major changes between r1282 and r1303...). If you have some patience, I'll upload once I tried in the air (just to be sure there isn't any major BUGs...). Or if you send me a PM I'll send it to you to let you check what's changed.

I'm planning to write a detailed changelog about my additions, but it takes a lot of time, for me the working code was the primary objective.

BR
Adrian

ps.: if anybody is interrested, I have found a nice program to MAC OS X , called DiffMerge. It's free and really simple to use app for merging codes on MAC OS... :D
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby Eric » Wed Jan 02, 2013 10:28 am

Adrian, thanks for your amazing code on alt hold!
I have a few comments about the failsafe handing.
As failsafe should be simple and robust. with a pre defined FAILSAFE_VARIO and FAILSAFE_OFF_DELAY will be very danger if the quad is at a very high altitude, say 3000cm. normally 50cm/s * 20 = 1000cm.
Someone would suggest to change the failsafe off delay to a big value, that is not wise when low battery case happen. If we increase the failsafe vario, that will break your quad when it kiss the ground.

My solution would be like this:
    split the alt into high an speed part and a low speed part
    each part spends 50% of the failsafe off delay
    first descends with a high speed to a safe alt within 50% of the fail safe delay
    then switch to a lower speed and land

failsafe starts:
Code: Select all
                    int32_t safeAlt = FAILSAFE_VARIO * FAILSAFE_OFF_DELAY / 10 / 2;
                    safeAlt /= 2;           // assure the quad can land in time
                    int32_t highSpeedAlt = (failsafeAlt - safeAlt)/(FAILSAFE_OFF_DELAY / 10 / 2);
                    if (highSpeedAlt > FAILSAFE_VARIO)
                        failsafeVario = highSpeedAlt;
                    else
                        failsafeVario = FAILSAFE_VARIO;


failsafe running:
Code: Select all
            if (f.FAILSAFE_RUNNING)
            {       
                if (f.FAILSAFE_ALTHOLD_RESET)
                {   
                    if (EstAlt < (FAILSAFE_VARIO * FAILSAFE_OFF_DELAY / 10 / 2))
                        failsafeVario = FAILSAFE_VARIO;
           
                    AltHold -= failsafeVario / 25;
                    dynPidAltPLimit = ALT_HOLD_VARIO_MAX * 3;
                    dynPidAltP = conf.P8[PIDALT];                    dynPidAltI = conf.I8[PIDALT];
                    dynPidAltD = conf.D8[PIDALT] + (ALT_HOLD_VARIO_D_CORR);
                    BaroState = BARO_STATE_HOVERING;
                }       
                else
                {
                    RESET_ALT_HOLD();
                    f.FAILSAFE_ALTHOLD_RESET = 1;
                }

                f.ALT_VARIO_CHANGED = 1;
            }

eg. if the quad is at 3000cm height, it drop to 2500cm height with speed of 250cm/s in 10 seconds. And then if drops to the ground with a speed of 50cm/s.

Can you please explain this line?

Code: Select all
if (BaroPID < -200) // reach the ground.


And if the quad is descending with a high speed, will this value be reached in the air and it disarm?
BTW, why it is -200 here? ;-)
Can you please help me to calculate a safe BaroPID value to used here? I do not want the quad to disarm in the air.
Eric
 
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold improvement solution

Postby Eric » Wed Jan 02, 2013 10:48 am

Btw, this is my ground checking code:
Code: Select all
                    if (
                        // the sonar said we are on the ground
                        (SonarErrors < SONAR_ERROR_MAX && SonarAlt <= FAILSAFE_SONAR_ALT)
                        // BaroPID is very small, can not reach a lower alt in 5 seconds
                        || (BaroPID < -(FAILSAFE_VARIO * 5) && failsafeVario == FAILSAFE_VARIO)
                         // timeout failsafe landing
                        || (failsafeCnt > (5 * FAILSAFE_OFF_DELAY) )
                        // something really bad happen, drops like a rock to avoid worse result
                        || (failsafeAlt + FAILSAFE_MAX_RISING_ALT < EstAlt)     
                    )   
                    {   
                        //if we cannot reach target altitude , or landed
                        // maybe initial throttle was too high, time to stop anyway
                        f.ARMED = 0;
                        f.OK_TO_ARM = 0;
                        RESET_FAILSAFE_FLAGS();
                    }
Eric
 
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold improvement solution

Postby nhadrian » Wed Jan 02, 2013 11:59 am

Hi,

I started a dedicated topic to advanced failsafe solutions, I suggest let this topic stay for alt hold.
My reply is also there.

viewtopic.php?f=8&t=2893

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby nhadrian » Wed Jan 02, 2013 12:11 pm

Hi Eric,

using Flags for barostate, failsafe is a good idea, I'll add them to my next release!!!

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby shikra » Wed Jan 02, 2013 12:21 pm

Adrian - the developments look fantastic. Look forward to trying out when the weather gives us a chance. maybe a coupe of weeks... (
User avatar
shikra
 
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Altitude Hold improvement solution

Postby mbrak » Wed Jan 02, 2013 1:02 pm

hi adrian

ps.: if anybody is interrested, I have found a nice program to MAC OS X , called DiffMerge. It's free and really simple to use app for merging codes on MAC OS...


diffmerge also exists for windows and linux systems :)

http://www.sourcegear.com/diffmerge/downloads.php
User avatar
mbrak
 
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: Altitude Hold improvement solution

Postby nhadrian » Wed Jan 02, 2013 1:50 pm

mbrak wrote:hi adrian

ps.: if anybody is interrested, I have found a nice program to MAC OS X , called DiffMerge. It's free and really simple to use app for merging codes on MAC OS...


diffmerge also exists for windows and linux systems :)

http://www.sourcegear.com/diffmerge/downloads.php


Hi Mbrak,

thanks for addition!!! I was looking for something really simple only under OSX...

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby nhadrian » Wed Jan 02, 2013 5:07 pm

Hi,

I have attached my latest code, I inserted this two-step failsafe vario.
It is fully merged with r1303, and tried to make bnetter descriptions in config.h (sorry for my bad english... ;) )
Please note that since my copter would probably damaged due to a 50 cm/s auto lading (mini Y6 copter...) I didn't tested the failsafe vario mode, only the failsafe rth mode (because in failsafe RTH mode it stays in hovering over home on defined home altitude). I tested all other functions in the air (although there was icy wind outside... :S )
Also please note that I have tested with serial GPS, but I implemented the I2C_GPS, should work also.

Other changes:
- different patterns in LED_PATTERN for VBAT alarms/failsafe mode
- LED_PATTERN is now set for CRIUS AIO PRO pin33
- VBAT pin is set to A1

I'd like to ask you to confirm the followings:
- FAILSAFE_VARIO_MODE works (please be careful and first test according to my previous post!!!, and set high value enough for FAILSAFE_OFF_DELAY!!!)
- I2C GPS FAILSAFE_RTH_MODE works
- My whole code with different boards (differ from CRIUS AIP PRO + EXTENSION BOARD)

Till now I left //NHADRIAN comments after each modified line/part for easier identification, but I'll remove in r10 finally.

BR
Adrian

PS.: mode infos about ALT hold mode in the other topic...
Attachments
Multiwii dev_r1303_NHA_r9.zip
(141.4 KiB) Downloaded 925 times
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby dramida » Wed Jan 02, 2013 11:04 pm

I don't know how to test failsafe as my FrSky PPM receiver sends PPM even with transmitter stopped. I set it to RTH and Alt Hold when receiver is in failsafe. Also i am not using I2C GPS.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby vpb » Thu Jan 03, 2013 3:48 am

Hi Dramida, if you meant RX failsafe, you can disable Frsky RX failsafe by rebinding the receiver (from frsky user guide).
vpb
 
Posts: 231
Joined: Mon Jul 23, 2012 4:09 pm

Re: Altitude Hold improvement solution

Postby nhadrian » Thu Jan 03, 2013 6:48 am

Hi all, the trigger for RX failsafe in Multiwii is that one of the first four channel (throttle, roll, yaw, pitch) gets lower than 985us signal.
So it doesn't matter if you use PPM or PWM signals, the only important is that your receiver should be programmed for failsafe function.

I'm using Futaba FASST transmitter with FRSKY TFR4 fasst compatible receiwer in PPM mode. The receiwer can be forgrammed for failsafe. The method is that switch on the transmitter, raise the low-point throttle EPA to maximum, then turn on the receiver and press the button. (this method depends on your receiver type) Then set back the throttle EPA to my default value. Now, once TX signal is lost, the receiver sends a 965 us signal on throttle channel, that triggers the failsafe in Multiwii.

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby wilco1967 » Thu Jan 03, 2013 3:54 pm

Hi Adrian

flew your code on my tricopter....
RTH, althold, climbing to RTH height, and lowering on reaching home all seems to work fine.

however, I could not get it to auto land on fail-safe. It returns home alright, but then keeps hovering at 5 meters (that's how I've set it).... it does not land....

not sure if I got the fail-safe properly set in the receiver.... got a frsky receiver. initially just re-bound it, so all failsafe settings are gone, but then it seems to keep sending last value. the copter would just float around as I left it.
Then I set the failsafe settings in the receiver to -125% throttle (GUI does not show anything below 990ish), and aux channels all set to RTH.... Now it would come back, but still no landing.... no different than RTH with transmitter on.

anyway.... cannot test anymore today.... some electrical fault caused a motor to stutter, and it crashed into a puddle :shock: .... have to dry all the electronics first.... :roll:

BTW. when in alt holt, and throttle at minimum, the tricopter starts to slowly yaw.... this is some feature build in long time ago to stop the yaw servo from moving, causing the prop to hit the ground. perhaps this feature should be de-activated when the copter is in alt-hold mode....

Thanks a lot for yet another great addition !

Wilco
wilco1967
 
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Postby nhadrian » Thu Jan 03, 2013 4:01 pm

Hi,

regarding your experiences:

1) when using RTH_FAILSAFE, it will NOT autoland, since I expect when copter arrives home, it will be in TX range again... (will autoland in its position only if GPS signal is weak or function not uncommented). Because if for example failsafe vario is 50 cm/s it is still hard touchdown enough to crash most of out copters.

2) I'll look after the tricopter code to check this feature at the weekend.

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby wilco1967 » Thu Jan 03, 2013 4:38 pm

Aha.... so then that was my misunderstanding....
I assumed it would autoland if still in failsafe by the time it arrived home, and risk it, rather then floating around until the battery dies
(which is also some kind of auto land).

So everything seems to work as designed then.... :)

My beaten up tricopter would most likely survive a 50 cm/s landing..... many of my 'normal' landings are worse.... 8-)
Not saying i would prefer an autoland.... the current implentation is perfect..... would just be interesting to watch.... :roll:

one other thing, which i was not able to test yet.... would it disarm when flying in alt-hold with throttle stick at minumum, and I would give full yaw left, or full roll left ?
wilco1967
 
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Postby copterrichie » Thu Jan 03, 2013 4:42 pm

HOWEVER, Auto-landing seems to be the next logical step. Hooray!!!
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Altitude Hold improvement solution

Postby wilco1967 » Thu Jan 03, 2013 4:54 pm

copterrichie wrote:HOWEVER, Auto-landing seems to be the next logical step. Hooray!!!


I could think of:
- RTH and keep flying if commanded to come home (no failsafe activated)
- RTH and auto land when home upon failsafe, if fail-safe is still active when it reaches home
- Auto land on the spot when failsafe and no GPS.

if my Transmitter comes back, I can always interrupt an autoland before it happens. if my Tx is no longer working (because I 'forgot' to charge the Tx battery, or some real problem exists), it would try to autoland.
If autoland would possibly cause damage, I could just hand-catch it when it comes down.
If it stays floating, just out of my reach, and I cannot get the Tx back up again, it's not very helpful as well....

just thinking out loudly.... ;)
I like already what it does now.....

Let's hope this makes it into the _shared branch !
wilco1967
 
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Postby nhadrian » Thu Jan 03, 2013 5:33 pm

Hi,

- I'll make a definable timer for autoland if still no TX after reaching HOME latitude.
- About autolanding, it is really hard to slow down before touchdown without a working sonar...how to determine the ground is close enough?! (waiting for ideas... :D !!!) :(
- if you have a big copter or ie. Y6, it is hard to catch by hand... :D

- about shared branch, my code is FAR AWAY to be clean and safe enough to put in _shared, it is really in testing/development phase!!!
Alexinparis pointed on lot of redundances and other weak points (many thanks to his kind reply!!!), which are caused because I tried to make as safe as I could (so many repeated variable resets, etc...). And also a detailed changelog will be neccessary to understand all changes clearly in code itself.

I'll try to overcome on all of this at weekend, I have already cleaned a lot.

BR
Adrian

ps.: I merged with r1306 already and will include in my next release, I really like to handle all GPS types in one way... ;)
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby wilco1967 » Thu Jan 03, 2013 6:11 pm

Is it possible to publish your code in a separate branch on google code SVN ?
I mean, here: http://code.google.com/p/multiwii/source/browse/#svn%2Fbranches
it's a lot easier to keep track of your changes (also for us)....
wilco1967
 
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: Altitude Hold improvement solution

Postby dramida » Thu Jan 03, 2013 6:44 pm

nhadrian wrote:Hi,

...............
- About autolanding, it is really hard to slow down before touchdown without a working sonar...how to determine the ground is close enough?! (waiting for ideas... :D !!!) :(

Alexinparis pointed on lot of redundances and other weak points (many thanks to his kind reply!!!), which are caused because I tried to make as safe as I could (so many repeated variable resets, etc...). And also a detailed changelog will be neccessary to understand all changes clearly in code itself.

..............

BR
Adrian

ps.: I merged with r1306 already and will include in my next release, I really like to handle all GPS types in one way... ;)


I am glad Alex is keeping an eye on this project.
Keep up the good work Adrian.
About auto-landing, i would make a procedure that try to decrease the speed as copter approach to ground, let's say below 2m the rate of descend is only 20 cm/s. The ground efect will step in at about 20-30 cm cushioning the 20 cm/s impact. Now the copter wants to go below 0m, let-s say it tries to go as far as -2 m or more ( in case of baro presure change). The Alt-Hold PID Algorithm would sense this situation (this check shoud be made only in final landing procedure ) as the error gets bigger and bigger.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby copterrichie » Thu Jan 03, 2013 7:19 pm

If there were enough memory on the ATMega328, the old computer game Lunar Lander would serve as a perfect example and would not require sonar.

http://lander.dunnbypaul.net/
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Altitude Hold improvement solution

Postby nhadrian » Thu Jan 03, 2013 7:37 pm

In order you have perfect level ground and accurate altitude reading, is OK.
But once you get 1-2 m drift in baro reading (ie. for temperature change, etc.) during flight, or there is 1-2 m difference in level between takeoff and landing place that's enough to crash the copter... :(
So hard to figure out. BTW, I'll include automatic descending after defined period in home point failsafe...

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby mahowik » Thu Jan 03, 2013 9:35 pm

nhadrian wrote:So hard to figure out.

you can check the averaged vario for this ;)
e.g. descending is set to -50cm/s... you average the vario by hard LPF (with big factor)... and when averaged speed about zero (~5..10cm/s) it means that you are landed... ;)
mahowik
 
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Altitude Hold improvement solution

Postby jpeti29 » Fri Jan 04, 2013 12:57 am

Why should the copter descend so quick (50cm/s)? DJI Naza only descend about 20-25cm/s. I thing, it will be good for us too at first time.
jpeti29
 
Posts: 22
Joined: Wed Mar 07, 2012 9:19 am
Location: Hungary

Altitude Hold improvement solution

Postby Eric » Fri Jan 04, 2013 4:16 am

Is it possible to check the if the BaroPID is always very small, say -200 in 5 seconds?
Eric
 
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold improvement solution

Postby nhadrian » Fri Jan 04, 2013 5:50 am

Eric wrote:Is it possible to check the if the BaroPID is always very small, say -200 in 5 seconds?


Hi. It is possible, but I found an interresting phenomenon, if BaroPIB reach small enough parameter (around -250), it resets, and gets 0 again. Till now I couldn't find the origin of this. BTW, -200 is small enough as I described in the previous posts, to disarm.
Also, I'd like to let the Failsafe as simple as it can be, since it is not a pleasure function but an EMERGENCY solution, not a controlled autolanding!!!!!
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby nhadrian » Fri Jan 04, 2013 5:52 am

jpeti29 wrote:Why should the copter descend so quick (50cm/s)? DJI Naza only descend about 20-25cm/s. I thing, it will be good for us too at first time.


FAILSAFE_VARIO is a user-definable parameter in config.h ... ;) ... You can set what you want, the lower limit is 25 cm/s.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby dramida » Fri Jan 04, 2013 12:11 pm

About a long range digital PAL video link in 433 Mhz open source project

viewtopic.php?f=7&t=2903&p=28701#p28701
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby dramida » Wed Jan 09, 2013 9:00 pm

Hi Adrian, any news about vario altitude mode and auto-landing? Can we put a new release based on your work? I built a new dji style quad and i am ready test some landings :)
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby nhadrian » Thu Jan 10, 2013 6:06 am

I'm ready with new release, only some final tests are pending....
And yes, the autolanding in failsafe_RTH and also a 2-step descending in failsafe_ALT is ready. And, other small improvements...
Also I made several major changes in code structure to be more clear and universal. Please be patient for 2-3 more days.

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby subaru4wd » Fri Jan 11, 2013 7:40 am

I cant wait to see what you come up with next Adrian :)

I have a problem though. I am trying to use your R9 and when I load it on my flight controller, my GUI (and i assume the board as well) does not see any RX input. My Transmitter has no effect on the board and the GUI shows all channels at 1500 as if the TX was turned off. I am not able to arm the board or anything :(

When I load 2.1 everything works as normal. Is there something I am overlooking in the code?

Thanks :)
subaru4wd
 
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Altitude Hold improvement solution

Postby Leon11t » Fri Jan 11, 2013 10:30 am

What's your transmitter?
If the transmitter type like Turnigy 9x, then leave all defines in "PPM Sum Reciver" commented. For example: //#define SERIAL_SUM_PPM

Code: Select all
/****************************    PPM Sum Reciver    ***********************************/
      /* The following lines apply only for specific receiver with only one PPM sum signal, on digital PIN 2
         Select the right line depending on your radio brand. Feel free to modify the order in your PPM order is different */
      //#define SERIAL_SUM_PPM         PITCH,YAW,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Graupner/Spektrum
      #define SERIAL_SUM_PPM         ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Robe/Hitec/Futaba
      //#define SERIAL_SUM_PPM         ROLL,PITCH,YAW,THROTTLE,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Multiplex
      //#define SERIAL_SUM_PPM         PITCH,ROLL,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For some Hitec/Sanwa/Others

      // Uncommenting following line allow to connect PPM_SUM receiver to standard THROTTLE PIN on MEGA boards (eg. A8 in CRIUS AIO)
      #define PPM_ON_THROTTLE
User avatar
Leon11t
 
Posts: 38
Joined: Thu Sep 27, 2012 12:24 pm

Re: Altitude Hold improvement solution

Postby subaru4wd » Fri Jan 11, 2013 5:07 pm

thank you, i will try that. I am using a Turnigy9X TX with a FrSky DHT module & RX.
subaru4wd
 
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Altitude Hold improvement solution

Postby nhadrian » Fri Jan 11, 2013 7:42 pm

Hi all,

********UPDATE**********
A have just noticed that an official r1311 is released. I checked and there were some small changes (ie. log values or governor or LCD changes) wich were not included in my r12 since I made my merge from _shared previously.
So I merged my code with the official r1311 now, and replaced the attachments!!!!
**********END*************

it's time to introduce my r12 code, based on r1311 Multiwii release!
I have included the autoland in Failsafe_RTH mode too, I even tested it! After landing, RPM will decrease than motors stops.

I completelly reworked the code, removed many redundant parts and also solved some major problems (many thanks to Alexinparis for pointing on them), now all my mods can be used independently too!!!

I have attached two zip files:
1) the COMPLETE code contains all my mods and should be used.
2) 5 more files for developers, with independent functions it is more easy to understand my changes and codes:
- BASIC - only minor changes but nothing new functions (only some led-flasher addons)
- FAILSAFE_ALT - only this function is included
- FAILSAFE_RTH - only this function is included
- VARIO_ALT_MODE - only this function is included
- RTH_ALT_MODE - only this function is included

I tried to explain all parametes correctly in config.h so please read carefully before use any of my mods.
Also please note that even if I made many-many flights during this period, hidden BUGs could be remained, especially with different setups (ie. I2C_GPS) so first test functions with EXTREME CAUTION!
For FAILSAFE functions please take time for previously described Failsafe testing procedure before first take-off!
Please keep in mind that all my functions assumes a well-tuned configuration with all important PIDs tuned (incl. GPS HOLD, BARO, ANGLE, etc...)

I hope you'll enjoy my code, I wish you all safe landings, and looking for any experiences!

BR
Adrian
Attachments
Multiwii_r1311_NHA_r13_VARIO_ALT_MODE.zip
(155.13 KiB) Downloaded 899 times
Multiwii_r1311_NHA_r13_RTH_ALT_MODE.zip
(155.34 KiB) Downloaded 923 times
Multiwii_r1311_NHA_r13_FAILSAFE_RTH.zip
(156.58 KiB) Downloaded 874 times
Multiwii_r1311_NHA_r13_FAILSAFE_ALT.zip
(155.2 KiB) Downloaded 903 times
Multiwii_r1311_NHA_r13_COMPLETE.zip
(159.16 KiB) Downloaded 992 times
Multiwii_r1311_NHA_r13_BASIC.zip
(153.9 KiB) Downloaded 901 times
Last edited by nhadrian on Sat Jan 12, 2013 8:56 am, edited 2 times in total.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Altitude Hold improvement solution

Postby Mystic3D » Sat Jan 12, 2013 7:15 am

Amazing work!
Please forgive a noob question.
How do code changes like this get into "official" releases from a process/approval perspective?
Mystic3D
 
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Re: Altitude Hold improvement solution

Postby nhadrian » Sat Jan 12, 2013 8:05 am

Hi,

************UPDATE**************
viewtopic.php?f=8&t=2371&p=29042#p29042
*************END*****************

It depends on the developers.
I sent all of these to Alexinparis, if he decides that any part of my job is stable/good/safety enough and also the resource consumption (memory/cycle time/etc) is good enough, he'll put it in.

BR
Adrian

ps.: since I'm not a qualified programmer, I'm sure some of my changes could be written on a more "elegant" way... but the idea itself looks like works!
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby dramida » Sat Jan 12, 2013 1:02 pm

Adrian, in latest MWC R13_complete, in config.h, confuses me:

I might be wrong, but i see two sets of configs regarding RTH:

firstly:

Code: Select all
    //#define FAILSAFE_RTH_MODE             // if GPS present and ready, copter starts RTH when signal lost. When signal is back, control is back again.
    #define FAILSAFE_RTH_VARIO    100     // in cm/s - vario for RTH function for failsafe 
    #define FAILSAFE_RTH_ALT      700     // in cm   - minimum RTH altitude for failsafe. If copter is higher than this, it will keep altitude.
    #define FAILSAFE_RTH_HOME     300     // in cm   - home altitude for RTH, copter will descend to this altitude and wait.
    #define FAILSAFE_RTH_DELAY    15      // in s    - safety delay, after reaching HOME altitude, it'll land in FAILSAFE_ALT_MODE when safety delay terminates.


and at the end

Code: Select all
 

    //#define RTH_ALT_MODE             // define RTH custom approach height 
    //#define RTH_KEEP_ALT             // if the altitude is higher than the RTH_ALT, copter maintains that altitude instead of descending to target - according to Dramida's request
    #define RTH_VARIO      100       // in cm/s  - vario used for reaching target altitudes during RTH - lower limit is 25 cm/s!
    #define RTH_ALT        700       // in cm    - altitude during approach
    #define HOME_ALT       350       // in cm    - altitude after reaching home position   
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold improvement solution

Postby nhadrian » Sat Jan 12, 2013 2:54 pm

Yes, because the failsafe rth can be set up independently...;)
Ie. You can set higher altitude for failsafe rth than for normal. Or different vario...

Br
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby subaru4wd » Sat Jan 12, 2013 9:53 pm

I downloaded and setup this build for my Board. I connected using the GUI & went to setup my flight modes and noticed there were already flight modes programmed. So I tried to clear them and it would not let me. I was able to add to the flight mode programming, but I could not remove what was originally there.

I also had this issue when I flashed your R9, but I was able to resolve by just clearing EEPROM, reflashing R9, and the flight modes were gone... it let me load my custom configuration file & saved parameters to EEPROM. However flying with your R9 i noticed HeadFree mode did not work at all. I really did not have time to test anything else... after finding out about Heads Free I flashed my working copy of 2.1
subaru4wd
 
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Altitude Hold improvement solution

Postby nhadrian » Sun Jan 13, 2013 7:20 am

subaru4wd wrote:I downloaded and setup this build for my Board. I connected using the GUI & went to setup my flight modes and noticed there were already flight modes programmed. So I tried to clear them and it would not let me. I was able to add to the flight mode programming, but I could not remove what was originally there.

I also had this issue when I flashed your R9, but I was able to resolve by just clearing EEPROM, reflashing R9, and the flight modes were gone... it let me load my custom configuration file & saved parameters to EEPROM. However flying with your R9 i noticed HeadFree mode did not work at all. I really did not have time to test anything else... after finding out about Heads Free I flashed my working copy of 2.1


Hi,

could you please share a screenshot about these flight modes? I can't understand clearly what you are talking about. You mean BOX items are already checked?
also, please give me the type of your controller (MEGA, 328p), the copter type and the sensor board. I didn't modified any part of the EEPROM file, so it is really strange.

There is one more thing. If you power on multiwii only without RX, and connect to gui, and Failsafe is uncommented (enabled), the ANGLE and MAG will shown as active (green), that's because when in failsafe, these functions are enabled automatically. That is because there is no valid RX data. If you turn on RX too, they must disappear in case are not selected by BOXes.

Regarding ro r9, that was much less completed than r13, although the part of headfree was not touched in the code. You wrote it didn't worked at all, that means you couldn't activate the function, or activated but not worked as it should?

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold improvement solution

Postby subaru4wd » Sun Jan 13, 2013 6:29 pm

Sorry Adrian. I should have provided you with all the information :)

I am using this board here: http://witespyquad.gostorego.com/flight ... oller.html (easier than typing a list of spec's) flying on my X-Quad

I can't understand clearly what you are talking about. You mean BOX items are already checked?

Yes exactly. I should have got a screenshot, but the last 4 flight modes (BEEPER, LEDMAX, LANDLIGHT, HEADADJ) all had boxes marked at random. They all had multiple boxes checked for all 4 AUX channels too. I tried to uncheck them and write to the board, and the boxes remained marked. I could mark unmarked boxes, and successfully write to the board, but I could not remove the originally marked boxes.

This was all done with the board powered by a LiPo, so the RX was powered and my TX was active. And I have failsafe commented out in config.h, I am more interested in your improvements to AltHold right now, and not so much RTH.

With R9 & Heading Hold I was activating the function with my TX Switch but the aircraft did not act as if it were in headsfree mode. I Tried a couple times by orientating the board in different positions and booting it up. However I did not look at my 3DR telemetry while flying, so I am not 100% the board had activated HeadsFree mode.
subaru4wd
 
Posts: 316
Joined: Sat Dec 08, 2012 2:16 am

Re: Altitude Hold improvement solution

Postby nhadrian » Sun Jan 13, 2013 7:57 pm

Thanks for detailed description.

That's really interresting indeed. I never had anything like this. Today I tested my code on a small arduino nano board (328p) with a 10DOF panel attached temporarily.
I uploaded many variations and tested to write/read EEPROM many times but I still couldn't reproduce this issue.
And this also presents with my r13? If yes, could you please try the official r1311 from download page on MWI repo?
Also, could you send your config.h in PM? I'd check, maybe you use something which I never had uncommented before and there is something interference...

I had once a similar behaviour with my older config on a Quadrino board around MWI 1.9-2.0 long time go, I don't know the reason till now, but I made a full EEPROM reset with an EEPROM reset sketch and disappeared.

If you can disconnect ESCs, you can test hearfree in your hand, arm the copter, apply some throttle, push roll or pitch. So you will see the motor outputs on GUI like they're trying to moce copter (2 of 4 motors will increase other will decrease). Now rotate copter around z axis (yaw) by 90 degrees, apply the same stick movement, and if headfree is active indeed, you will see that different motor outputs will increase or decrease...

BR
Adrian
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Altitude Hold improvement solution

Postby Mystic3D » Sun Jan 13, 2013 10:23 pm

Tried 2.2 r1311 on a Avatar Tri., Alt Hold works great with default PID's. POS hold also works much better. High winds like 15 mph and held its own within a few meters
Mystic3D
 
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 1 guest