Alt. Hold Ideas and discussion

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

Then there is definitely something wrong in my setup. I could not get the BARO to light up in the GUI, STABLE and ACC would fine though. But the copter would want to take off into the sky once I flicked my AUX1 switched, even if I didnt have any mode boxes on. Wierd. I will look into it and report back.

Colin

alexmos wrote:Alt Hold activated by BARO box, and it start working only if BARO becomes green in GUI. Sonar is ON by default (if you enabled it in config), but may be turned off by activating PASSTHRU on Aux1.

Before flight, strongly recomended to test it in GUI:
- enable ALT_DEBUG in config.h
- in GUI, debug1= sensor alt (sonar or baro or mixed), debug2, debug3= estimation errors, debug4= throttle correction, heading=velocity, alt=estimated alt


alexmos
Posts: 108
Joined: Tue Aug 09, 2011 12:12 pm

Re: Alt. Hold Ideas and discussion

Post by alexmos »

Then there is definitely something wrong in my setup. I could not get the BARO to light up in the GUI, STABLE and ACC would fine though. But the copter would want to take off into the sky once I flicked my AUX1 switched, even if I didnt have any mode boxes on. Wierd. I will look into it and report back.


You can mail me some screenshots/extra info to private, I will try to help you to solve problem.

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: Alt. Hold Ideas and discussion

Post by LuFa »

alexmos wrote:Hi guys! Here is my alt hold implementation.........


Cool !
Can you tell me how to aktivate the Sonar ? does it automaticly switch on when i switch on Altitute hold ?


thx

Lapino
Posts: 84
Joined: Tue Aug 16, 2011 10:01 am

Re: Alt. Hold Ideas and discussion

Post by Lapino »

Hi,

just out of curiosity...is there a Simulink model of alt. hold or Multiwii in general? Or a signal flow diagramm...? :D

Best regards,

Tobi

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

Wow! Alexmos, that actually works! For the first time I had it hovering! You just made my day!

I think it was the THROTTLE_EXPO that was giving me the wierd throttle reaction, I disabled it. I had it hovering for a long time, and it was correcting very well. I could see the copter was following the error in the BMP085 actually, just like in the GUI (normal). The reaction of the copter to the error was right on though. It was pretty tight response and it seemed to inject the right amount of output to reach it's goal without overshoot, kind of anticipating where it will end up. The old bar code would oscillate/overshoot until out of control. For the most part, the hover was working within the precision of the BMP085 (about 1.2 meters) and worked *so* well. Given that I just used your PIDs and didnt tune (besides THROTTLE_HOVER param) this is amazing! About 3 times total over 2 batteries flight time, the copter just dropped as if the velocity estimator diverged. Still, I am impressed.

I tried to enable one of my boards with the MS6511 baro but it doesnt read. I tested the board in MultiWii1.9 and the baro works, but in your code it doesnt. I verified the baro address and code was correct. I also see that MS6511 is updating BaroAlt variable as the debug1 shows the proper raw baro value. I see you use BaroAlt to set SensorAlt...so it should work. Any suggestions? Anything you can think of why the estimated alt would read 0 when debug1 reads ok?

Magnetron, I havent tried yours yet but I will soon.

Colin

alexmos wrote:
guru_florida wrote:Hi alexmos,

No luck here. Copter just flies away (into the sky).

I adjusted the THROTTLE_HOVER/SHIFT to 1275 which was my throttle just before the copter would take off. Maybe it's just my PIDs are way off. I left P as default 4.7. TRUSTED_ACCZ is enabled. I am using the BMP085 like your setup.

Also, as a warning to others who try, It seems the code ignores the AUX modes as setup in the GUI. Looks like AUX1 activates HOLD and is hard coded. Just to be safe, test your setup by holding the copter first - with a good grip. This is not a big deal if the algorithm works, easy to fix afterwards.

I'm really looking forward to seeing Alt hold working!


My PIDS for Alt are: P=10, I=0.05, D=10
Vel PIDS are not used.

Alt Hold activated by BARO box, and it start working only if BARO becomes green in GUI. Sonar is ON by default (if you enabled it in config), but may be turned off by activating PASSTHRU on Aux1.

Before flight, strongly recomended to test it in GUI:
- enable ALT_DEBUG in config.h
- in GUI, debug1= sensor alt (sonar or baro or mixed), debug2, debug3= estimation errors, debug4= throttle correction, heading=velocity, alt=estimated alt

Estimated alt should follow sensor alt, and after enabling Alt Hold, throttle correction should be near zero if position doesn't changes, and react to any change in altitude.

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

Tobi,

I have been using Matlab to test out my own algorithm. I made a DLL for matlab that allows me to read the values from the control board and also write back the throttle value so I can do hardware in the loop testing. My baro hold was then coded in matlab for testing. I can also plot the results.

If your interested I can send you the source and DLL for it.

Colin

Lapino wrote:Hi,

just out of curiosity...is there a Simulink model of alt. hold or Multiwii in general? Or a signal flow diagramm...? :D

Best regards,

Tobi

Lapino
Posts: 84
Joined: Tue Aug 16, 2011 10:01 am

Re: Alt. Hold Ideas and discussion

Post by Lapino »

PM sent ;)

alexmos
Posts: 108
Joined: Tue Aug 09, 2011 12:12 pm

Re: Alt. Hold Ideas and discussion

Post by alexmos »

Can you tell me how to aktivate the Sonar

Sonar is activated when system starts. In GUI, "debug1" variable should show sonar or baro data (if ALT_DEBUG defined in config.h). Sonar switched off only in PASSTHRU mode.

I have found now, that current GUI (or any previous, downloaded from MultiWii repository) does not work with my code, because of protocol version mismatch. You should use GUI that I have used: http://code.google.com/p/multiwii-alexm ... akechanges Later I will merge my code with current dev.

I think it was the THROTTLE_EXPO that was giving me the wierd throttle reaction, I disabled it. I had it hovering for a long time, and it was correcting very well. I could see the copter was following the error in the BMP085 actually, just like in the GUI (normal). The reaction of the copter to the error was right on though. It was pretty tight response and it seemed to inject the right amount of output to reach it's goal without overshoot, kind of anticipating where it will end up. The old bar code would oscillate/overshoot until out of control. For the most part, the hover was working within the precision of the BMP085 (about 1.2 meters) and worked *so* well. Given that I just used your PIDs and didnt tune (besides THROTTLE_HOVER param) this is amazing! About 3 times total over 2 batteries flight time, the copter just dropped as if the velocity estimator diverged. Still, I am impressed.


Thanks, It is good news! Your result is just like mine, and it was my target - to get robust stabilization within baro error range. Get more precize baro (or sonar) and you will get near-perfect ALT stabilization in hovering. But the next target is to get the same results in fast flight. Theoretically, my code will do this, but I can't test now due to bad weather conditions.

I tried to enable one of my boards with the MS6511 baro but it doesnt read. I tested the board in MultiWii1.9 and the baro works, but in your code it doesnt. I verified the baro address and code was correct. I also see that MS6511 is updating BaroAlt variable as the debug1 shows the proper raw baro value. I see you use BaroAlt to set SensorAlt...so it should work. Any suggestions? Anything you can think of why the estimated alt would read 0 when debug1 reads ok?


I have no versions. I have merged my code with main multiwii trunc last time in the begining of december, 2011 and may be, some important changes were added since that time. I am plannig to merge with the next stable release when it will appear.

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Alt. Hold Ideas and discussion

Post by Magnetron »

I have tryed dev20120219 with MS5611 and my moving average. The quad was very stable and with alt default pid value the quad seem to maintain his altitude. I have an idea to optimize vertical trust. At BaroPID we could add acc vertical value considered by D vel component... Something like this:

temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / 400 + accADC[YAW]*D8[PIDVEL]/x;

Where 'x' must be defined empirically...
I think x=30 is a good start... Marbalon or Alexinparis what are you think about my idea?
Last edited by Magnetron on Sat Feb 25, 2012 5:54 pm, edited 2 times in total.

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: Alt. Hold Ideas and discussion

Post by LuFa »

@alexmos :

Today i would test your code .
But i get a Compailing error if i aktivate Hexa :(

did you can tell my how to juse your code with Hexacopter ?

thanks so mutch

alexmos
Posts: 108
Joined: Tue Aug 09, 2011 12:12 pm

Re: Alt. Hold Ideas and discussion

Post by alexmos »

Sorry, but Hexa needs more interrupts than quad, and sonar uses one of it (on 328p chip there are no free interrupts in this case). Try to disable sonar. If sonar will be added in oficial release, may be it will be compatible with hexa.

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

Hi Magnetron,

Alexmos did something like this in his code. I think it's a good idea, having the vertical velocity dampen the output through D. What's interesting is he uses Kp*Kd*EstVelocity . Here is the line from alexmos's PID code:
DTerm = ((int32_t)D8[PIDALT]) * P8[PIDALT] * constrain(EstVelocity, -100, 100) / 1000;

I cant get his code to work with the MS6511 though. I tried my heart out. Strangely enough, I had to disable the MAG in order for ALT value to even go non-zero. Seems like the Atmel may be out of memory. possible?

Magnetron wrote:I have tryed dev20120219 with MS5611 and my moving average. The quad was very stable and with alt default pid value the quad seem to maintain his altitude. I have an idea to optimize vertical trust. At BaroPID we could add acc vertical value considered by D vel component... Something like this:

temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / 400 + accADC[YAW]*D8[PIDVEL]/x;

Where 'x' must be defined empirically...
I think x=30 is a good start... Marbalon or Alexinparis what are you think about my idea?

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

Magnetron, the copy you are working on is the standard MultiWii code repository as MultiWii_dev_20120225, correct?

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: Alt. Hold Ideas and discussion

Post by Magnetron »

Hi, I am working now on 20120219... I will try 20120225...

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

Thanks Magnetron. Where can I download your latest code? 20120219 or whatever. I can use zip or svn no problem.

Magnetron wrote:Hi, I am working now on 20120219... I will try 20120225...

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

Hi Lapino,

I zipped everything up. If you just want to do MATLAB, you can download the matlab .m files and the MultiWiiLink.dll from below. There are instructions in the zip to modify MultiWii code...very simply, just adding a command to the serial 'switch' statement to return only the variables you are interested in.
http://www.colinmackenzie.net/multiwii-matlab.zip

If you want to edit/compile the MultiWiiLink dll code, download the whole project solution for MSVC 2010 here. There are 3 projects, you are interested in MultiWiiLink project and MWLinkSample. The latter is just a ugly form with a few scattered display variables to test MultiWiiLink before going into Matlab), since if you recompile the DLL you have to restart matlab (no DLL unload in Matlab.)
http://www.colinmackenzie.net/MultiWiiSimulator.zip

Ignore the 3rd project in the solution, it was a MultiWii copter simulator (Z axis only) to test my baro algorithm. It works but I didnt anticipate how much acc/baro sensor noise would exist...so without a proper "velocity estimator" it's useless. I then moved into Matlab to get real data.

If you get setup we should connect via skype to IM or something.

Colin

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

I integrated the SRF08 I2C sonar sensor into the latest dev. Details here:
viewtopic.php?f=7&t=1282

I also integrated into alexmos's code but I havent tested it yet. Looks good in the GUI.

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: Alt. Hold Ideas and discussion

Post by guru_florida »

alexmos,

I just flew your code with bmp085 and the SRF08 i2c sensor. It worked awesome! I went through 4 batteries mostly flying at 1-4 feet just because it was awesome seeing the copter fly around a few feet off the ground and not crash. lol. Really this makes flying at 1 foot off the ground possible! I never would have thought. Really smooth flight at the low alt levels. Still baro is kind of crappy at high alts.

Good work on the velocity estimator, it seems to work very well. Also tying the velocity into the D term of the PID was a great idea. I can actually see that working while flying.

I need to get ms6511 working on your code. No idea why it doesnt work. I'm going to try bringing your code up to latest dev level.

Thanks for all your hard work on it.

Magnetron: I am still waiting to hear where I can download your code, I'd like to try yours out too. Thanks.

Colin

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

Re: Alt. Hold Ideas and discussion

Post by nhadrian »

I have MS5611 and it works quite well with the latest dev code, dev20120225.
It still has some drift issue on low temperatures though.
You should get the sensor coding from there.

BR
Adrian

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: Alt. Hold Ideas and discussion

Post by nicodh »

Hello, guru_florida, I was looking at your code over matlab, tried to use it but my pc lags, need to test some more.
Anyway, I want to test the code in my quad. I'm using a naze32 board with the bmp baro. Do you share the code so I can try to integrate it to my naze32?

Thanks!

alexmos
Posts: 108
Joined: Tue Aug 09, 2011 12:12 pm

Re: Alt. Hold Ideas and discussion

Post by alexmos »

guru_florida wrote:alexmos,
I need to get ms6511 working on your code. No idea why it doesnt work. I'm going to try bringing your code up to latest dev level.
Colin


guru_florida,

I have merged with 2.0 and tested it in flight, all works. nhadrian has reported that MS5611 works now, so you can try it too.
http://code.google.com/p/multiwii-alexm ... 2FMultiWii

I have slightly updated Alt Hold algorithm for Sonar and Baro fusion, and added LPF for output. Now it is not rapid as it was, but big baro or sonar noise less affects motors, and sonar-to-baro translation is smoother. It is important for now, because grass is coming and sonar works definitelly worse :)
Also I have added deadband for baro (default +-50cm), it gives more smoothness in hovering.
Video from my phone: http://www.youtube.com/watch?v=Kt0efEtmHzA
Alt PID: P=10, I=0.010, D=20
Vel PID (for position hold): P=5, I=0.005

schmuggler
Posts: 5
Joined: Wed Apr 18, 2012 11:50 am

Re: Alt. Hold Ideas and discussion

Post by schmuggler »

Hello alexmos
your position hold is very stabel is it with gps or you optical sensor ?
regards jan

alexmos
Posts: 108
Joined: Tue Aug 09, 2011 12:12 pm

Re: Alt. Hold Ideas and discussion

Post by alexmos »

schmuggler,
it's optical sensor. But stability depends on surface quality (contrast pattern required) and works only in daylight

schmuggler
Posts: 5
Joined: Wed Apr 18, 2012 11:50 am

Re: Alt. Hold Ideas and discussion

Post by schmuggler »

Hello alexmos
thanks fore explain nice job you did.
regards jan

Tifani
Posts: 63
Joined: Sun Nov 06, 2011 5:15 pm

Re: Alt. Hold Ideas and discussion

Post by Tifani »

Hi Alex !
If I try to do "SVN Checkout" I'm getting this error "Server sent unexpected return value (405 Method Not Allowed) in response to.."
The same with other MultiWii repositories - what I'm doing wrong - I just want to download. I tried link for "not members" but no luck.
Thanks for any help
Tom

alexmos
Posts: 108
Joined: Tue Aug 09, 2011 12:12 pm

Re: Alt. Hold Ideas and discussion

Post by alexmos »


Tifani
Posts: 63
Joined: Sun Nov 06, 2011 5:15 pm

Re: Alt. Hold Ideas and discussion

Post by Tifani »

Thanks !!!
Now is working.
Thanks for Your work.
Regards
Tom

mahowik
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Alt. Hold Ideas and discussion

Post by mahowik »

Hi guys!

Could someone tell me if you have success of using alt-hold and bmp085 with official 2.0 version? And which PIDs in this case?
Or it works good only with MS5611?

thx-
Alex
Last edited by mahowik on Thu May 03, 2012 6:04 pm, edited 1 time in total.

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: Alt. Hold Ideas and discussion

Post by Bledi »

yes alt hold is working. First part of this video is alt only pid tuning : http://www.youtube.com/watch?v=nHRniYL5jsI

mahowik
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Alt. Hold Ideas and discussion

Post by mahowik »

I saw a lot of posts with great results, but it was related to MS5611... And I wanna to find the same for bmp085 if it's also true for this baro sensor :)

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: Alt. Hold Ideas and discussion

Post by Bledi »

Thé vidéo is with à crius se so it's à bmp085 :)

mahowik
Posts: 331
Joined: Sun Apr 10, 2011 6:26 pm

Re: Alt. Hold Ideas and discussion

Post by mahowik »

ok
Thanks! I will try... and I need more more more statistics (with bmp085)! :)

Ausi1972
Posts: 17
Joined: Sat Apr 14, 2012 9:03 pm

Re: Alt. Hold Ideas and discussion

Post by Ausi1972 »

I'm using the crius multiwii with the bpm085 and got alt hold working perfectly. Accurate within 1m. Set on a switch of my tx.
I need to tune my other settings a bit more to get level working better but that won't happen until I have fitted my new Simon esc's.

Here are my settings.
Alt: P 1.6 I 0.015 d 7

User avatar
Jonit
Posts: 37
Joined: Sat May 12, 2012 10:12 pm
Location: Slovakia

Re: Alt. Hold Ideas and discussion

Post by Jonit »

Today I was testing barometer on Crius SE board.. seems to work pretty well ;)
P - 3.0, I - 0.015, D - 7
http://www.youtube.com/watch?v=dwuBiPqpkkU&feature=youtu.be

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

Re: Alt. Hold Ideas and discussion

Post by nhadrian »

Hi all,

After many tests with the current Altitude hold algorithm, I can tell you that it will newer work!!!!!!!!!
The problem is that this is not a real PID loop. So it can be setup only for one type of circumstances. For example, if you set up in a calm weather for hoovering, you should reduce D-term because if D is too much, it will give much power and will cause overruns. Or you can reduce P-I values. BUT! Even using GPS RTH, it will not be able to compensate the altitude loss caused by moving the copter. It is even worse when using RTH in windy conditions!!!!!! And if you raise the values for better altitude hold, it will overrun in calm hoovering so much it can even fall of from hovering.
So I'm sure we should use the Acc-Z for regulation too, and a normal PID loop for Baro!!!!!
With the previous code (which used vel too) I had good results at the end, even it needed so much PID tuning.
Or, Alexmos has a good altitude hold algoithm too.

Alex, could you bring back the old code, and for example, make a choice for using it in the config.h, I mean for example:

#define SIMPLE_ALT_HOLD //simple alt hold from MW2.0
#define NEW_ALT_HOLD //alt hold with acc_Z

So then it would be selectable.

BR
Adrian

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: Alt. Hold Ideas and discussion

Post by LuFa »

wich "New" Alt-Hold code did you mean ?
is there a different of Alt-Hold code from 2.0 and the Newest Dev ?

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

Re: Alt. Hold Ideas and discussion

Post by nhadrian »

No, I mean that the old code with vel, or the code of alexmos...

AntonyUK
Posts: 1
Joined: Sat Jun 09, 2012 10:15 am

Re: Alt. Hold Ideas and discussion

Post by AntonyUK »

Hi.
I know this is not a normal question for you people BUT.
I have been trying for 3weeks now to achieve what you call altitude hold.
I must tell you that this is not a flying machine but a type of sub ( Remotley operated vehicle ).
Its operation is the same. IE No movement in height = go into hold height. Or depth in my case
I am using Arduino for the coding and the only thing going in loops is Me.
I use a pressure sensor for the depth this outputs .4 to 4.5 volts.
Enough of the "I's"
What I am requesting is a very basic altitude hold code or process that I could use.
I understand I am out of order but I don't know any other options I have.
many thanks.
Antony.

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: Alt. Hold Ideas and discussion

Post by LuFa »

Hi ,

today i have upload the r35 from alexmos to test the altohold :)
I use the MS5611 baro sensor .
It works great but i have one proplem :
The Mwii hold the alt good for the first time , after 30sek or more the Mwii beginns to move slow down and land ^^ stand for some seconds on the ground and move up to the target alt .

have anyone a idea why ?
My PID´s are : P 10 I 10 D 20

Thanks :D

awoods177
Posts: 14
Joined: Mon Apr 30, 2012 10:08 pm

Re: Alt. Hold Ideas and discussion

Post by awoods177 »

Hi guys, I'm trying to get the latest alexmos version running to use sonar, but when I upload it and look in the GUI, I am not getting any trasmitter/receiver data. Everything else seems to work fine.

Any ideas? With the "official" multiwii releases everything is just fine...

Also, I just wanted to make sure I had the pins in the right position for the sonar. I've connected Ground, VCC and Trig to the G + S pins on A2 and then the echo pin to the S pin on D12. Is this all correct? any way to verify the sonar is working?

Thank You

cencen
Posts: 6
Joined: Sun May 27, 2012 8:49 am

Re: Alt. Hold Ideas and discussion

Post by cencen »

awoods177 wrote:Hi guys, I'm trying to get the latest alexmos version running to use sonar, but when I upload it and look in the GUI, I am not getting any trasmitter/receiver data. Everything else seems to work fine.

Any ideas? With the "official" multiwii releases everything is just fine...

Also, I just wanted to make sure I had the pins in the right position for the sonar. I've connected Ground, VCC and Trig to the G + S pins on A2 and then the echo pin to the S pin on D12. Is this all correct? any way to verify the sonar is working?

Thank You


If you are using Alexmos R23 version (for multiwii V2.0) comes with already defined serial_sum receiver in config.h. You should uncomment the define if your receiver is not that type. Your connections with sonar is correct. You should uncomment the line define sonar_debug to see the sonar values in debug1. You can read about my sonar experience and tips here http://www.multiwii.com/forum/viewtopic.php?f=7&t=1413&start=190
Regards,

Feridun

jonathan
Posts: 1
Joined: Sat Jul 06, 2013 9:21 am

Re: Alt. Hold Ideas and discussion

Post by jonathan »

hello l try alex-mos but my sensor dont work ? did l want to activated sonar? how? thanks jonathan

adhikariminmultiwii
Posts: 5
Joined: Fri Jan 16, 2015 3:27 pm

Re: Alt. Hold Ideas and discussion

Post by adhikariminmultiwii »

Hello guys: I have some error problem. while I upload the code to multiwii SE it shows following error

avrdude: stk500_getsync(): not in sync: resp=0x30

what does it mean and how can I overcome this?

Thanks in advance.

fvk1960@gmail
Posts: 3
Joined: Wed May 13, 2015 12:38 pm

Re: Alt. Hold Ideas and discussion

Post by fvk1960@gmail »

Hi, i am just a hobbyist and no programmer. But Itried some things. Maybe someone can make something nice of it.

First I dislike to first fly into hoover and then activate althold.
I like to choose on forhand the Mode : Acro, Attitude(Angle/Horizon), Altitude. Now the last one can only be activated while inflight in current MW.

So I changed the code that the baromode only activates by itself after preselecting Baromode and armed and having some altitude.
#if BARO
#if (!defined(SUPPRESS_BARO_ALTHOLD))
if (rcOptions[BOXBARO] ) {
if (!f.BARO_MODE && f.ARMED && (alt.EstAlt>50)) {
f.BARO_MODE = 1;
AltHold = alt.EstAlt;
#if defined(ALT_HOLD_THROTTLE_MIDPOINT)
initialThrottleHold = ALT_HOLD_THROTTLE_MIDPOINT;
#else
initialThrottleHold = rcCommand[THROTTLE];
#endif
errorAltitudeI = 0;
BaroPID=0;
}
So now you can preselect Baromode by aux switch before arming and you can arm normally.
Slowly increase throttle and slowly go into height above 50 cm.
Now at 50cm it is assumed you have aproxemitly hoover throttle and baromode is now truly enabled.
It would be nice if anyone could translate this aproach into a controlled software where 50cm is a target and using accz to detect hoover and then enable baromode.

Second discomfort is that the initial throttlehold can be anywhere in the throttlestick position. Resulting in a asymetric stick position for althold.
I like to have throttlestick center for hoovering.
Thus I changed software into
#elif defined ALTHOLDMODE2
if (abs(rcData[THROTTLE]-MIDRC)>ALT_HOLD_THROTTLE_NEUTRAL_ZONE) {
uint16_t altChange = abs(rcData[THROTTLE]-MIDRC);
AltHold = (rcData[THROTTLE] > MIDRC) ? (AltHold = alt.EstAlt + (altChange/2)) : (AltHold = alt.EstAlt - (altChange/2));
AltHold = constrain(AltHold, -32767, 32767);
isAltHoldChanged = 1;
} else if (isAltHoldChanged) {
AltHold = alt.EstAlt;
isAltHoldChanged = 0;
}
#endif
rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
}
#endif
Now after BaroMode enables I move further my autocentering throttlestick to center and the copter is altholding at stick center.
By the way now stick movement is scale for altchange speed. The bigger stick movement the bigger output.
The original code was timebased contineously increasing Althold height.
And it overruns it size going from positve to negative when copter does not respond quick enough.
So I use the real altitude add the desired height increase given by stick and set althold target.
Now the added height from stick is constant offset in althold versus estalt.
In my example it limits to 500/2=250. So althold is constantly 250 above estalt. Or i.e 25 at 1/10 of stick position change.
So stick gives a constant offset from 25(neutal zone) to 250.

I wonder if this priciple is used in software like NAZA or so.
My NAZA equiped copter has transmitter with autocenter throttle and amezingly hoovers at center throttle and Altitude mode can be selected before arming.
With the above modification my Multi AIOP works in a simalar way.
Select BarMode on forehand.
Arm
Move throttle stick slowly to center and my quad hoovers at 50 cm.

Like i said i am just a hobbyist maybe someone can make this principle in a more professional manner.
Where it does not matter how fast you center the throttle stick the copter goes into hoover at designated height checks accz and goes into althold.
From there you can FPV / fly in althold mode.

:)

Post Reply