Altitude Hold/Advanced Failsafe solutions by NHA

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

Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sat Jan 19, 2013 6:31 am

Hi,

I started this topic because the Altitude Hold Improvement topic started to be a little messed up.
I would like to collect all infos, questions/answers/ideas regarding my "development". Which is more like a brainstorming, still needs some generic recompilation by a professional programmer.
Please try all my mods with extreme caution and on your own risk!!!

***********UPDATE**************
Latest revision is:

Multiwii r1411 NHA r23
viewtopic.php?f=8&t=2965&p=35281#p35281

**********************************

BR
Adrian
Last edited by nhadrian on Wed Apr 24, 2013 4:59 am, edited 4 times in total.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Multiwii_r1313_r13_NHA

Postby nhadrian » Sat Jan 19, 2013 6:39 am

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!!!!

PLEASE NOTE that i share all my develompent to let others think on it and give an idea, let try it and modify according to their ideas!!!
IT IS NOT AN OFFICIAL RELEASE so if you have an expensive setup and want something exact then DO NOT USE MY CODE, donwload the latest OFFICIAL release!!!!!!

ANY CRASHES ON EXPENSIVE COPTERS DESPITE MY ATTENTION IS CAUSED BY POSSIBLY CODE BUG OR OTHER SETUP PROBLEM IS THE RESPONSIBILITY OF THE END USER!!!

I Don't want to discuss this fact again and again, this is basically a topic for developers!!!!! Not for final users.....

**********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 399 times
Multiwii_r1311_NHA_r13_RTH_ALT_MODE.zip
(155.34 KiB) Downloaded 324 times
Multiwii_r1311_NHA_r13_FAILSAFE_RTH.zip
(156.64 KiB) Downloaded 407 times
Multiwii_r1311_NHA_r13_FAILSAFE_ALT.zip
(155.19 KiB) Downloaded 287 times
Multiwii_r1311_NHA_r13_COMPLETE.zip
(159.2 KiB) Downloaded 616 times
Multiwii_r1311_NHA_r13_BASIC.zip
(153.9 KiB) Downloaded 286 times
Last edited by nhadrian on Sat Jan 19, 2013 1:31 pm, edited 3 times in total.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

dramida's question

Postby nhadrian » Sat Jan 19, 2013 6:41 am

dramida wrote: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   


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
Last edited by nhadrian on Sat Jan 19, 2013 6:47 am, edited 1 time in total.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

wilco1967"s question and FAILSAFE_OFF_DELAY

Postby nhadrian » Sat Jan 19, 2013 6:42 am

wilco1967 wrote:Tried failsafe RTH with autoland with the 1311 R13 yesterday with my BMP085 equipped tricopter, with mixed results....

after turning off the transmitter, the copter started heading back... it went to RTH altitude correctly.
when it arrived at home, it started descending.... but after a few seconds, while still up at approx 10 meters, it decided, it had landed, and it disarmed.... :roll: :shock:

quite funny to see how it decided to quit, and it fell down like a brick..... :lol: however, I don't think this was intended behaviour...
only some props broken, and a stripped gear of the tail servo.... all repaired already... 8-)

I guess the issue could be my BMP-085 not being very acurate... alt holt works reasonable, but has always been a bit bumpy... when decending, it always overshoots, and climbs back up before making another drop that overshoots.....
I suspect the alt PID output reached -200 (or whatever it max value is), causing it to think it landed, thus causing the motors to disarm.... actual 'landing' then happened a few seconds later, but with slightly higher vertical velocity... :lol:

Perhaps adding a few seconds delay after reaching max alt PID output could prevent it from disarming while still in the air ?
tuning of the the alt PID controller could also be helpfull, but I don't want to risk it like this..... I only have limited supply of props :roll:

It did the same thing some time back with rev 9 (i think)... when decending after reaching home....

Anyone else using this with a BMP-085 baro ?

Overall it seems to work quite well..... just some minor 'tweaking' required
Thanks !


Hi,

I'm happy to hear that code works, and sad to hear your crash!!!
The BaroPID off-condition is raised to -250 in r13, so it can't be the reason.

BUT! For safety reasons, FAILSAFE_OFF_DELAY condition is still active in all my FAILSAFE modes, that means, once this time ends, it will disarm!!! (I mentioned somewhere earlier, maybe should highlihgt again...).
So, it must be set high enough to allow get home before this time ends. In my code it is 500 by default, it means only 50s. I suggest to raise this value to the neccessary extent!
I'll highlight this fact in my config.h, sorry for that!!!

Regarding to bumpy behaviour, first of all, you should fine-tune alt hold PIDs during hovering. If you have already stable and good enough hovering behaviour but still very bumpy in raising/descending, I'll think on how to setup the correction values.

BR
Adrian
Last edited by nhadrian on Sat Jan 19, 2013 6:48 am, edited 1 time in total.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

BaroPID and disarm...

Postby nhadrian » Sat Jan 19, 2013 6:42 am

The BaroPID is between +-80-100 during normal altitude working. Just test out what's happening when you reduce the throttle from hovering position by 250 during manual mode. It will fell down from the sky...
The drift in alt reading is not important unless it drifts 3m between two baro sensor readings. (Because drift is relative drift, so the only caused by sensor drift is that it will hover 2-3 m away from target altitude)

The reason why I dont have any timer after BaroPID gets under -250 is to aovid further damages when copter couldn't land perfectly. (Ie. Burning ESCs caused by stucked props, when landing in high grass)

Failsafe_off_delay can be set to high enough (ie. if you know your flight time is 8 min, set it to 8000).
Anyway, it must be kept in mind that Failsafe is a safety function, not a leisure one, the only function of faisafe rth is to bring the copter back if possible inside RC range or near take-off zone and prevent crashes from high altitude, not to make a perfect auto landing. (At least this is my oppinion).

Br Adrian
Last edited by nhadrian on Sat Jan 19, 2013 6:48 am, edited 1 time in total.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

dramida's flight

Postby nhadrian » Sat Jan 19, 2013 6:43 am

dramida wrote:Here is how it flies R13 with Crius AIOP

http://www.youtube.com/watch?v=BdaN-ddVmi8

Last edit:

I activated RTH function with altitude control during RTH. I found out that copter starts moving immediately twards home, even the RTH altitude is not achieved. Practically, before reaching RTH altitude, the copter makes about half of distance back. In this case trees and houses could not be avoided. A more healthy approach for failsafe RTH is when altitude is below RTH altitude, first position hold until safe altitude is reached, then continue with RTH and autoland...
Last edited by nhadrian on Sat Jan 19, 2013 6:49 am, edited 1 time in total.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Advanced Headfree mode

Postby nhadrian » Sat Jan 19, 2013 6:46 am

Hi,

Some development on headfree mode:

1) in multiwii.ino, modify this:
Code: Select all
     ...
      if (rcOptions[BOXHEADFREE]) {
        if (!f.HEADFREE_MODE) {
          f.HEADFREE_MODE = 1;
        }
      } else {
        f.HEADFREE_MODE = 0;
      }
      if (rcOptions[BOXHEADADJ]) {
        headFreeModeHold = heading; // acquire new heading
      }
    #endif


to this:
Code: Select all
     ...
      if (rcOptions[BOXHEADFREE]) {
        if (!f.HEADFREE_MODE) {
          f.HEADFREE_MODE = 1;
        }
        #if defined(ADV_HEADFREE)
          if ((f.GPS_FIX && GPS_numSat >= 5) && (GPS_distanceToHome > 15)
            #if defined(ADV_HEADFREE_RANGE)
              && (GPS_distanceToHome > (ADV_HEADFREE_RANGE))
            #endif
          ) {
            if (GPS_directionToHome < 180)  {headFreeModeHold = GPS_directionToHome + 180;} else {headFreeModeHold = GPS_directionToHome - 180;}
          }
        #endif             
      } else {
        f.HEADFREE_MODE = 0;
      }
      if (rcOptions[BOXHEADADJ]
        #if defined(ADV_HEADFREE)
           && ((GPS_distanceToHome < 15)
           #if defined(ADV_HEADFREE_RANGE)
             || (GPS_distanceToHome < (ADV_HEADFREE_RANGE))
           #endif
           || (!f.GPS_FIX || GPS_numSat < 5))
        #endif
      ) {
        headFreeModeHold = heading; // acquire new heading
      }
   #endif


2) in config.h, add this:
Code: Select all
  /**************************************************************************************/
  /***********************            Advanced HEADFREE        **************************/
  /**************************************************************************************/

    /* Advanced Headfree mode.
       When the copter is out of defined range, the headfree orinetation will be always towards from home position.
       Generally that means, when pull the pitch stick, copter will come closer. Once copter is inside defined range again,
         it will maintain the last headfreeorientation. This orientation can be still reset using HEADADJ function (only inside defined range).
       Please note that the default orientation before getting out of range is the armed position (just like before). 
       If HEADFREE_RANGE is commented, 15 m will be the default range. Please note that for safety reasons minimum range is 15 m, even is less is defined!!!  */

    #define ADV_HEADFREE
    #define ADV_HEADFREE_RANGE 15          // in m - activation range around home point


Now, if copter is out of defined range (or 15m by default is no range is defined), headfree will be positioned regarding to home direction (if pull the pitch, copter will come closer).
Please note that HEADADJ is working inside defined range only.

I just tested in the air, worked great.

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

Disable AP_MODE solution

Postby nhadrian » Sat Jan 19, 2013 7:02 am

Hi,

Another small catch. In official Multiwii code, AP_MODE for GPS hold can't be deactivated, because then compilation ends with error.
Here is the solution:

in multiwii.ino, replace this line:
Code: Select all
          if (rcOptions[BOXGPSHOLD] && abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE) {


to this:
Code: Select all
          if (rcOptions[BOXGPSHOLD]
            #if defined(AP_MODE)         
               && abs(rcCommand[ROLL])< AP_MODE && abs(rcCommand[PITCH]) < AP_MODE
            #endif
          ) {


Now, if AP_MODE is commented, you will get GPS hold without the possibility of moving the hold point away but still can correct in controls if neccessary.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby jy0933 » Sat Jan 19, 2013 9:17 am

just a few quick questions after reading the code..

1. I noticed the angle correction is to be tested/set with angle mode.. I wonder if Acc_lpf_factor setting will affect the effectiveness since it will delay acc reading at some point

2. when baro/alt hold is activated... should I move stick to center (1500 in my case)? how much time do i have between switch on baro/alt hold at hovering and center the stick?

3. I heard one problem existing in mwc along with stability is a non-fixed cycle time. I wonder if i turn the "fix cycle time =9000" on (in fact i tend to fix it to 5000, but still..).. if it will affect the effectiveness/response of baro hold?

4. suggested process on tuning baro/alt hold to get best out of it?

5. Temperature drift? the rig is built for school AP project.... the temp range here can be like 30c in summer and -20c in winter (but we usually only go out when it warms up to -10c +)

the board I am using is AIOPv1.1...

looking forward to using this code on the rig... definitely pretty much need to know about it before putting on other people's money :)

thanks
jy0933
 
Posts: 180
Joined: Wed Jun 27, 2012 4:24 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sat Jan 19, 2013 10:37 am

Hi, I'd reply to the followings:

1) I don't think the delay is significant at all, at least for me is wasn't noticeable

2) only in case if throttle middle point is UNCOMMENTED and 1500 is set! Otherwise it'll use the activation throttle position as before!

3) since I'm using a fixed 25Hz calculation for VARIO_MODE, so cycletime doesn't affect the vario mode itself, maybe can only disturb the BaroPID calculation in extreme cases (but it is the same as before... no major changes in them)

4) I don't have any, unfortunatelly the weather is terrible now so I couldn't spend time on fine-tune the Baro PID values.
BUT, for porper working, I suggest to tune PIDs in hovering first! If you have good behaviour than you can try rising/descending. And maybe fine-tune the correction values, but maximum 10 at a time for each!!!

5) Temperature drift is only important when you use RTH_ALT_MODE or FAILSAFE_RTH_MODE, because in these modes defined altitudes are used!
For example, if you set up home to 4m and the sensor has -4m drift during cooling down from 20 C to -5 C in the air, then it'll hit the ground during descending to RTH home altitude!
That's why I suggest strongly to let sensors cooling down before takeoff!!!
BTW, temperature drift depends on the baro sensor type too...
In VARIO mode drift doesn't matter. If you notice that the hovering alt is changed, simply move back by stick....

BR
Adrian

PS.: I added some comment according to crashes, etc.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby Aitch » Sun Jan 20, 2013 11:07 am

a lot of this terminology is beyong me, however,

for return to home with auto land, could the code not be written so that
1.) first safe altitude is achieved
2.) return to home performed
3.) auto land initiated
4.) a set decent rate is used until it cant decent any more (cos its on the ground)
this should compensate for sensor / altitude error
5.) mtor shut down after pre determined time say 4 seconds

Aitch
Aitch
 
Posts: 8
Joined: Wed Jan 09, 2013 4:37 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sun Jan 20, 2013 12:13 pm

1) I was thinking on, but is is too difficult for me to do that, many-many connection to other code parts required. - ANY HELP ARE WELLCOME!!! ;)
2) it is working now
3) in fact the code works on a different way. I made a general function to reach target altitude - called here too. So first descend to a defined home altitude, then wait till defined period, then call another function which is doing auto landing.
4) it works on this way now. ACC sensors can't be used to determine touchdown. Just imagine what happens if one prop hit some grass, then copter starts to tresh itself on the ground. (or landing in a bush...?). So BARO is used (in fact BaroPID value).
5) any seconds spent on the ground with runnning props increase the risk of damages. So could you please tell me what is the advantage of waiting on the ground?
As I prevously described, the BaroPID less than 250 is a really good constrain.
If you make some calculations, it can be admitted that 1250 us in Throttle output (1500 - 250) can't be reached in the air unless copter is prevented in descending by something!!! (unless in the copter are 2-3 x bigger motors than is suggested...)

Please keep in mind what I already told many times, this is FAILSAFE not autolanding feature!!! The primary goal is to minimalize, reduce damages, and also prevent hitting obstacles (ie. houses, cars, visitors, etc)
For a perfect autolanding feature much more development and testing are required! ANY HELP ARE WELLCOME!!!!! ;)

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sun Jan 20, 2013 12:25 pm

Hi all,

My next target is the using of SONAR sensor, I ordered an SRF02 already.

My idea is the following:

Once the copter is close to the ground (less than 3-4 m by sonar mesurement) I'd like to correct the baro readings according to that. In this case the baro drift and also the uneven ground surface could be compensated.
So generally, my idea is to modify the BaroGroundPressure (calculate back from current altitude), so after rising above 3-4 m again, the Baro altitude value also would show the exact altitude measured from the ground on that area. In this case, any preset altitude values (ie. home latitude, rth altitude) could be used more accuratelly.

The problems should be solved:
1) smooth transition between baro/sonar values
2) smooth changing in baro reading when alt_hold is active
3) calculation and changing of BaroGroundPressure value
4) compensation of SONAR value by tilt (primary idea is to use the same AccZ than for throttleanglecorrection - any other suggestions? I thought on calculated angles by tilt-roll but I can't solve how to calculate a mayimum angle from those two values without high calculation needs)
5) etc...

What do you think?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby schott1984 » Mon Jan 21, 2013 2:37 am

Been using the source you posted. RTH, vario ALT, and failsafe RTH work pretty well.

For some reason I can't get it to do anything with ALT on RTH, in either regular RTH or failsafe. It just pretty much comes home at whatever ALT it was at before i hit the switch or it lost signal (turned Tx off).

Any help here? I'm using the MS5611 baro.

Here are some of my code snippets:

Code: Select all
    #define FAILSAFE                                  // uncomment  to activate the failsafe function
    #define FAILSAFE_DELAY     1                      // Guard time for failsafe activation after signal lost. 1 step = 0.1sec - 1sec in example
    #define FAILSAFE_OFF_DELAY 5000                    // Time for Landing before motors stop in 0.1sec. 1 step = 0.1sec - 20sec in example
    #define FAILSAFE_THROTTLE  (MINTHROTTLE + 200)    // (*) Throttle level used for landing - may be relative to MINTHROTTLE - as in this case


Code: Select all
    #define FAILSAFE_ALT_MODE             // uncomment for descending with constant vario if in Failsafe - use with FAILSAFE and define the FAILSAFE_SLOW_VARIO
    #define FAILSAFE_SLOW_VARIO   50      // in cm/s - slow desceding speed under SAFETY_ALT, this is default is SAFETY_ALT is not used.  - lower limit is 25 cm/s!
    #define FAILSAFE_FAST_VARIO   75      // in cm/s - fast desceding speed over SAFETY_ALT, lower limit is 25 cm/s!
    #define FAILSAFE_SAFETY_ALT   350     // in cm   - safety altitude, where to slow down descending before landing, in cm!!!

    #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      1000     // 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.


Code: Select all
    #define VARIO_ALT_MODE           // define ALT HOLD code
    #define ALT_VARIO_MAX                     200   // in cm/s  - maximum rising/descending vario when full throttle applied  - lower limit is 25 cm/s!
    #define ALT_HOLD_THROTTLE_NEUTRAL_ZONE    50    // in us    - deadband of stick around hovering point when in ALT HOLD is active (us in PWM signal)
    #define ALT_HOLD_THROTTLE_MIDPOINT        1500  // in us    - if uncommented, this value is used in ALT_HOLD for throttle stick middle point instead of initialThrottleHold parameter.

    #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      75       // in cm/s  - vario used for reaching target altitudes during RTH - lower limit is 25 cm/s!
    #define RTH_ALT        1000       // in cm    - altitude during approach
    #define HOME_ALT       350       // in cm    - altitude after reaching home position


Let me know what you guys think. Like I said, on turning off Tx or hitting RTH switch, it just turns to home, comes home at what appears to be the same altitude it was when RTH was triggered, gets home, turns nose out, then hovers there.

Baro hold seems to work OK most of the time.

Let me know if you need more info.
schott1984
 
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Mon Jan 21, 2013 5:47 am

Hi,

Did you have BARO mode by switch enabled during RTH? (When transmitter is turned off, it doesn't matter for RTH altitude)
Could you please send me the complete code to let me check your settings?
nhadrian@gmail.com

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby schott1984 » Mon Jan 21, 2013 6:13 pm

When I hit my Aux2 switch, I have MAG and BARO come on with GPS HOME; All on the Aux2 high.

Find my sketch files attached.

Looking forward to seeing what you find!
Attachments
Multiwii_r1311_NHA_r13_COMPLETE.zip
(154.89 KiB) Downloaded 130 times
schott1984
 
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Mon Jan 21, 2013 6:40 pm

schott1984 wrote:When I hit my Aux2 switch, I have MAG and BARO come on with GPS HOME; All on the Aux2 high.

Find my sketch files attached.

Looking forward to seeing what you find!


Hi,

It looks I found the missing part in the I2C GPS code part.
Since I don't have i2c GPS, I didn't recognized this till now, and it is hard to debug.
I attached a modification.
Please test it, during first initialization, please be careful and be prepared to turn off BARO immediatelly (in case of any malfunction).
I hope it works like it should, please let us know your result!

BR
Adrian
Attachments
MultiWii_for_schott1984.zip
(161.2 KiB) Downloaded 141 times
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby schott1984 » Mon Jan 21, 2013 6:43 pm

nhadrian wrote:
schott1984 wrote:When I hit my Aux2 switch, I have MAG and BARO come on with GPS HOME; All on the Aux2 high.

Find my sketch files attached.

Looking forward to seeing what you find!


Hi,

It looks I found the missing part in the I2C GPS code part.
Since I don't have i2c GPS, I didn't recognized this till now, and it is hard to debug.
I attached a modification.
Please test it, during first initialization, please be careful and be prepared to turn off BARO immediatelly (in case of any malfunction).
I hope it works like it should, please let us know your result!

BR
Adrian


Alright. Probably can't test until this weekend, though.
schott1984
 
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Mon Jan 21, 2013 9:37 pm

Adrian, it would be useful to "beep" like rcoptionsbeep when in AltHold mode, you change the state (climb, descend, hold) because you will get feedback, even in fpv.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Wed Jan 23, 2013 10:25 am

Yesterday i flew about 1.5Km away with R5 release of NHAdrian. It worked fine. I also flew R13 but in but in visual range. I'll update my fpv multirotor platform to r13 this week.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Wed Jan 23, 2013 5:52 pm

dramida wrote:Adrian, it would be useful to "beep" like rcoptionsbeep when in AltHold mode, you change the state (climb, descend, hold) because you will get feedback, even in fpv.


Hi,

I'll think on it how to solve this ...!

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Wed Jan 23, 2013 5:55 pm

dramida wrote:Yesterday i flew about 1.5Km away with R5 release of NHAdrian. It worked fine. I also flew R13 but in but in visual range. I'll update my fpv multirotor platform to r13 this week.


Please don't forget to raise the FAILSAFE_OFF_DELAY to neccessary value.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby schott1984 » Sun Jan 27, 2013 9:08 pm

nhadrian wrote:
schott1984 wrote:When I hit my Aux2 switch, I have MAG and BARO come on with GPS HOME; All on the Aux2 high.

Find my sketch files attached.

Looking forward to seeing what you find!


Hi,

It looks I found the missing part in the I2C GPS code part.
Since I don't have i2c GPS, I didn't recognized this till now, and it is hard to debug.
I attached a modification.
Please test it, during first initialization, please be careful and be prepared to turn off BARO immediatelly (in case of any malfunction).
I hope it works like it should, please let us know your result!

BR
Adrian



Heading outside to test this out now. You know the problem is with the altitude part, right? GPS home works fine, just doesn't rise in ALT at all.
schott1984
 
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sun Jan 27, 2013 9:13 pm

There is a trigger for changing altitude once RTH started/mode changed in the GPS code too.
I think that caused the problem.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby schott1984 » Mon Jan 28, 2013 2:23 am

nhadrian wrote:There is a trigger for changing altitude once RTH started/mode changed in the GPS code too.
I think that caused the problem.


Seemed to work now. I only had the vario for reaching RTH ALT at 75 cm/s. I changed it to 200 for next test run. I'd like to to jump up pretty quick in case of trees in immediate area.

THANKS!
schott1984
 
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Mon Jan 28, 2013 8:41 pm

schott1984 wrote:
nhadrian wrote:There is a trigger for changing altitude once RTH started/mode changed in the GPS code too.
I think that caused the problem.


Seemed to work now. I only had the vario for reaching RTH ALT at 75 cm/s. I changed it to 200 for next test run. I'd like to to jump up pretty quick in case of trees in immediate area.

THANKS!


thanks for feedback!!! I wish you many happy landings!!!

I'm almost finished my new release, increased the resolution of vario and also made the code even more clean and universal...
I hope can share at the weekend!

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby schott1984 » Mon Jan 28, 2013 8:44 pm

nhadrian wrote:
schott1984 wrote:
nhadrian wrote:There is a trigger for changing altitude once RTH started/mode changed in the GPS code too.
I think that caused the problem.


Seemed to work now. I only had the vario for reaching RTH ALT at 75 cm/s. I changed it to 200 for next test run. I'd like to to jump up pretty quick in case of trees in immediate area.

THANKS!


thanks for feedback!!! I wish you many happy landings!!!

I'm almost finished my new release, increased the resolution of vario and also made the code even more clean and universal...
I hope can share at the weekend!

BR
Adrian


What's the quickest way to update source on my multiwii to your latest release with all my personal settings?
schott1984
 
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Mon Jan 28, 2013 9:12 pm

schott1984 wrote:
What's the quickest way to update source on my multiwii to your latest release with all my personal settings?


I suggest to use "diffmerge" and check all ino and h files one by one. You will see the changes in code and can decide if you accept or not.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby schott1984 » Mon Jan 28, 2013 9:19 pm

nhadrian wrote:
schott1984 wrote:
What's the quickest way to update source on my multiwii to your latest release with all my personal settings?


I suggest to use "diffmerge" and check all ino and h files one by one. You will see the changes in code and can decide if you accept or not.


Yeah, I've been using "winmerge" Same thing basically, I think.
schott1984
 
Posts: 9
Joined: Tue Jan 15, 2013 4:56 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Wed Jan 30, 2013 2:01 am

Today i flew MWC R13 on a Crius AIOP Quad. It worked well but some time when i want to arm the copter , a long beep is triggered and the copter dosen't arm. After recalibration, it worked. And one more thing: Rushduino OSD (aka minimOSD) dosen't sense the ARMED state and the baro vario is shown reversed. More to dig in tomrow.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Wed Jan 30, 2013 6:16 am

dramida wrote:Today i flew MWC R13 on a Crius AIOP Quad. It worked well but some time when i want to arm the copter , a long beep is triggered and the copter dosen't arm. After recalibration, it worked. And one more thing: Rushduino OSD (aka minimOSD) dosen't sense the ARMED state and the baro vario is shown reversed. More to dig in tomrow.


Long beep can be caused by the failsafe, simply arm again and it will work. (there is an integer wich has to be reset before arm).

The serial part is not touched, neither the vario number calculation, so possibly there is something with the Rushduino code.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Wed Jan 30, 2013 11:24 am

Thank you Adrian.
After flying R13 for the third time I think that newly proposed function like:

-altitide controlled vario with throttle stick
-RTL with altitude control settings
-Home with altitude setting

is good enough to make in to the main trunk
. I didn't test the failsafe procedure yet as my frsky has its own FS setting.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby jaames74 » Thu Jan 31, 2013 11:59 am

dramida wrote:
After flying R13 for the third time...



hi dramida,
is there a chance to make a demo video as usual?? ;)
jaames74
 
Posts: 22
Joined: Tue Jun 12, 2012 5:56 pm

r15 release

Postby nhadrian » Fri Feb 01, 2013 6:33 am

Hi all,

Here is my new r15 release.
- based on 1322, so theoretically the hold position injection (WP16) works with EZ-GUI (not tested since EZ-GUI was released in the evening...)
- included advanced headfree mode (more details here: viewtopic.php?f=7&t=2951#p29370 )
- beep function for vario mode when switching between rising/descending (for Dramida)
- increased resolution for manual vario mode (2,5 cm/s...instead of 25 cm/s :D), so even smoother vario mode
(if you modify my code, please note that AltHold is now in mm instead of cm, so use /10 divider for cm)
- many parts of the code is even more optimised, ie. PID changings are collected into IMU.ino for easier understanding
- rising/descending to target is more robust and direct. You'll feel in the air...
- some comments changed in config.h, I suggest strongly to go throush on them!

And don't forget the basics: TRY IT ON YOUR OWN RISK!!! This is the next state of a custom development, BUGs could be still remain.
If you need something well tested code for your expensive copter, download any of the OFFICIAL MULTIWII RELEASES instead of mine..... :P

BR
Adrian
Attachments
Multiwii_r1322_NHA_r15_complete.zip
(163.79 KiB) Downloaded 270 times
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Fri Feb 01, 2013 11:28 am

Thank you Adrian. Have you tested your distribution with MinimOSD?
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Fri Feb 01, 2013 1:58 pm

dramida wrote:Thank you Adrian. Have you tested your distribution with MinimOSD?


No, I'm using Mobidrone OSD. Theoretically there are no any changes in serial code compared to the official r1322 release so it should work on the same way as with the official r1322.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby jy0933 » Fri Feb 01, 2013 3:35 pm

one quicky...

what if the hovering point is not at ALT_HOLD_THROTTLE_MIDPOINT

should I change ALT_HOLD_THROTTLE_MIDPOINT to about the hovering point or ?


also.... is it possible to use vario from taking off.. say... turn on alt hold (vario), then arm, then stick up for ascending... center stick for maintain hovering?

btw.. what kind of alt hold accuracy are we talking about here with ms5611?


thanks
jy0933
 
Posts: 180
Joined: Wed Jun 27, 2012 4:24 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Fri Feb 01, 2013 5:35 pm

jy0933 wrote:one quicky...
what if the hovering point is not at ALT_HOLD_THROTTLE_MIDPOINT
should I change to about the hovering point or ?
thanks

You have two options. "ALT_HOLD_THROTTLE_MIDPOINT" is for using defined throttle position for hovering, which doesn't depend on hovering point.
But if you would like to use your hovering throttle point instead of defined value, then simply comment "ALT_HOLD_THROTTLE_MIDPOINT" line.
Do not set it to 0 as copter would always rise!!!!

jy0933 wrote:also.... is it possible to use vario from taking off.. say... turn on alt hold (vario), then arm, then stick up for ascending... center stick for maintain hovering?

I would not recommend this since accZ has also influence on alt hold code, and can cause big jumps during takeoff. I recommend to activate the BARO in stable hovering!
BTW, if you are brave enough, can try it but with ALT_HOLD_THROTTLE_MIDPOINT uncommented. First arm copter then turn on baro then apply throttle.
I don't know how it will react!!!!!!

jy0933 wrote:btw.. what kind of alt hold accuracy are we talking about here with ms5611?

The alt hold code during hovering (0 cm/s target vario) is the same as in the official release!
That means accuracy is exactly the same as for the official release too!
It depends on alt hold PIDs/baro sensor/motor/prop/frame/weight/etc too... can't exactly defined!
Each setup has its own accuracy.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Fri Feb 01, 2013 5:39 pm

jy0933 wrote:one quicky...
btw.. what kind of alt hold accuracy are we talking about here with ms5611?
thanks


Another short comment at this point.
For the best alt hold behaviour I strongly recommend to set up the throttle curve and expo for hovering around 1500 throttle stick input with 3/4 charged battery.
That will definitelly cause the best and balanced alt hold behaviour could be reached!!!

ALT_HOLD_THROTTLE_MIDPOINT is basically for FPV purposes or countinous vario mode, since after many rising/descending it is hard to remember the throttle position of the activation. But when the center point is defined (ie. 1500), it is much easier to find the 0 vario.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby jy0933 » Fri Feb 01, 2013 8:12 pm

make sense to me

here's what i defined.. and gonna go out test as soon as it gets warmer


Code: Select all
 #define VARIO_ALT_MODE                          // define ALT HOLD code
    //#define VARIO_MODE_CHANGE_BEEP                  // beep if changing between rising/descending  - long beep when entering hoover mode, short beep when changing between rising/descending
    #define ALT_VARIO_MAX                     20   // in cm/s  - maximum rising/descending vario when full throttle applied  -  maximum 250!!!
    #define ALT_HOLD_THROTTLE_NEUTRAL_ZONE    50    // in us    - deadband of stick around hovering point when in ALT HOLD is active (us in PWM signal)
    #define ALT_HOLD_THROTTLE_MIDPOINT        1500  // in us    - if uncommented, this value is used in ALT_HOLD for throttle stick middle point instead of initialThrottleHold parameter.



say if the hovering point on tx is 70% throttle.. once i fly in hovering and turn on alt hold. I should bring the throttle stick back to 1500 to maintain the hold.. right?



thanks
jy0933
 
Posts: 180
Joined: Wed Jun 27, 2012 4:24 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Sat Feb 02, 2013 12:19 am

One interesting observation about R13:

I've made a landing using vario altitude mode. After touching ground, the proppelers continued to spin (as expected) slower and slower until they reached the minimum arm throttle (1150us). So it could be possible to detect the landing and stop the motors.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sat Feb 02, 2013 8:13 am

jy0933 wrote:make sense to me

here's what i defined.. and gonna go out test as soon as it gets warmer
Code: Select all
 #define VARIO_ALT_MODE                          // define ALT HOLD code
    //#define VARIO_MODE_CHANGE_BEEP                  // beep if changing between rising/descending  - long beep when entering hoover mode, short beep when changing between rising/descending
    #define ALT_VARIO_MAX                     20   // in cm/s  - maximum rising/descending vario when full throttle applied  -  maximum 250!!!
    #define ALT_HOLD_THROTTLE_NEUTRAL_ZONE    50    // in us    - deadband of stick around hovering point when in ALT HOLD is active (us in PWM signal)
    #define ALT_HOLD_THROTTLE_MIDPOINT        1500  // in us    - if uncommented, this value is used in ALT_HOLD for throttle stick middle point instead of initialThrottleHold parameter.

say if the hovering point on tx is 70% throttle.. once i fly in hovering and turn on alt hold. I should bring the throttle stick back to 1500 to maintain the hold.. right?
thanks


Yes, you are right.
nhadrian
 
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sat Feb 02, 2013 8:14 am

dramida wrote:One interesting observation about R13:

I've made a landing using vario altitude mode. After touching ground, the proppelers continued to spin (as expected) slower and slower until they reached the minimum arm throttle (1150us). So it could be possible to detect the landing and stop the motors.


Hi,

Interresting, I'll think on it! Thanks.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby scanman » Sat Feb 02, 2013 7:11 pm

I'm trying the nhadrians build R15 on "Crius All in one pro" board . I get the following problem : If i use the include "#define FAILSAFE" option then the board doesnt work properly, it will not arm and it will not read the correct throttle reading in the gui and just do totally random things with the switches in the gui.
if i use a switch to arm, it can hardly fly, if i comment the "#define FAILSAFE" option it is back to normal.
On older builds the failsafe options works OK.
ITs the same problem with the build version r1317 so its not nharians code, its something from before his code.

(its a tri-copter)
scanman
 
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sun Feb 03, 2013 7:35 am

scanman wrote:I'm trying the nhadrians build R15 on "Crius All in one pro" board . I get the following problem : If i use the include "#define FAILSAFE" option then the board doesnt work properly, it will not arm and it will not read the correct throttle reading in the gui and just do totally random things with the switches in the gui.
if i use a switch to arm, it can hardly fly, if i comment the "#define FAILSAFE" option it is back to normal.
On older builds the failsafe options works OK.
ITs the same problem with the build version r1317 so its not nharians code, its something from before his code.

(its a tri-copter)


I suggest to make an EPROM clear:

http://arduino.cc/en/Tutorial/EEPROMClear

I had something similar long time ago with an old MWI version, I got random switch checkboxes in the GUI, and this solved the issue for me.
But if you have false throttle channel reading than it is rather a hardware issue, because Failsafe code itself doesn't affect channel reading. Check all connections, solderings.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby scanman » Sun Feb 03, 2013 5:17 pm

ok thanks , i tried the eeprom clear it didnt seem to help i will try it again, i dont think its connections because I can remove the failsafe switch and it works perfectly without touching any connections, but i will re-check.

By the way Adrian, thank so much for the "Tip" of using Visual Micro for arduino projects i was continually cursing the rudimentary arduino user interface including their extremely frustrating search function.
scanman
 
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Sun Feb 03, 2013 6:42 pm

The R15 release of Multiwii works as expected. It can change altitude in flight as configured. A new MSP SET CURRENT ALTITUDE and Set WP ALTITUDE would be nice. It also beeps when changing altitude in alt Hold Mode with vario control.
Notice: when entering in hold altitude from vario mode, the loong beep is missing.

Here are two flights with R15:

Position hold and alitutde hold on wind
http://www.youtube.com/watch?v=8wImr9Jm4Yc

MAP GPS navigation and autolanding
http://www.youtube.com/watch?v=2wMqMO8-F_I
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby nhadrian » Sun Feb 03, 2013 6:53 pm

Great flights!!!

I have one question. Are you still using bluetooth only ofr Android communication? My first tests with HM-TRP modules (same as in the 3DR) were successful, I got extended range.
Are you thinking on to expand the range?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby jy0933 » Sun Feb 03, 2013 10:34 pm

impressive.... i'm waiting for a better day to go out an test
jy0933
 
Posts: 180
Joined: Wed Jun 27, 2012 4:24 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Postby dramida » Sun Feb 03, 2013 11:15 pm

nhadrian wrote:Great flights!!!

I have one question. Are you still using bluetooth only ofr Android communication? My first tests with HM-TRP modules (same as in the 3DR) were successful, I got extended range.
Are you thinking on to expand the range?

BR
Adrian

Actualy i am using bluetooth with a range about 200m. I am very interested about increasing the range to be able to take the shoots approximately from the same position without loosing the link. I am wondering if EosBandi woud update his WinGUI to be able to inject new PH and home.
User avatar
dramida
 
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest

Next

Return to Software development

Who is online

Users browsing this forum: Google [Bot] and 1 guest