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
nhadrian
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

dramida wrote:.... new MSP SET CURRENT ALTITUDE and Set WP ALTITUDE would be nice. ...


At this point serious help is needed!!!
For me it looks like that current nav structure can't handle proper WP navigation, so it must be reworked from the base.
Till now I developed my code without any help, but at this point it must be changed to a team play.

MSP, EEPROM, GPS, main loop, GUI, etc. must be chanded...

BR
Adrian

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

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


First I was wondering on handle an FTDI board connected to phone USB, but Bart said it is far too complicated.
I prefer the phone method since I'm using MAC OS. But my phone is always in my pocket.

The 100 mW 3DR modules have aprox. 800 m range, hardly depends on the antenna type. If the ground module is connected to the bluetooth module, it should give the same rande as with the WinGUI.
The only problem/important thing is the arrange of the modules, because my experience is that if the BT module is too close to the 3DR module, they push down each other.
Now they are separated on my FPV tray as far as they could be, and the antenna positions are also set to the best direction ( they are almost collinear, the transmit power is lowest in that direction for a 1/4 wavelength antenna)

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

So you took a 3DR uhf transciever module with 5v TTL output and re-programmed as slave. I am not clear about 3DR configuration. Some help please?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

dramida wrote:So you took a 3DR uhf transciever module with 5v TTL output and re-programmed as slave. I am not clear about 3DR configuration. Some help please?


There isn't any master/slave option! 3DR modules are simple transparent serial connections, what goes in to first module, goes out from the second one, and reversed.
If you are interrested, I can share my setup values, but I think everything is written down clearly in the 3DR wiki site:
http://code.google.com/p/ardupilot-mega/wiki/3DRadio

Once you go through the wiki, you'll understand every important parameter.

And what I like in them, you can setup the 'air module" by remotelly, that means you connect one module to your FTDI, the second module is connected in the air, and you can setup both from the first one.
That means you can remotelly setup the module in copter and only have to connect the ground module to the FTDI instead of BT module.

Clearly spoken you only need a BT module and two "air 3DR modules" (the type without USB plug, the firmware is the same!!! there isn't any ground/air firmware!!!)

BR
Adrian

oddcopter
Posts: 4
Joined: Tue Dec 06, 2011 6:37 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by oddcopter »

Adrian,

Sorry to ask such a basic newb question, but once I load your version of the firmware and have configured the appropriate define values in the config.h file, is this activated by just switching on "baro" on my transmitter or are there other switches involved?

I play around with lots of different boards and honestly haven't done that much with multiwii. As a non programmer, I am amazed that the expensive Naza board has been considered above the rest in alt hold performance for so long. I have searched for less expensive alternatives that perform as well to write about on my blog without much luck. This sounds very exciting!

Thanks,
Britt

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

If Naza has 10 out of 10 in altitude hold, i would give Multiwii -10 and arducopter 9.
And yes, you have to switch on the baro to enter in altitude mode.
I advice you to increase D factor to 60 if you are using MPU6050 or BMA180 as acceleration sensor because D factor is the amount of Z acceleration taken into Alt-hold calculation.

I found this clip with a barometer simulation of altitude hold and altitude variation using MWC code. It seems that multiwii code works perfect, the only errors are from sensor readings.

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

oddcopter
Posts: 4
Joined: Tue Dec 06, 2011 6:37 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by oddcopter »

dramida,

I'm not sure I am following what you are saying. The code is perfect, but the multiwii altitude hold rates a -10. Why are the Naza and Arducopter so much better? Are you saying it is all because of the sensors? I don't know what kind of sensors the Naza uses, but the Arducopter uses a MS5611 which you rate a +9? Many Multiwii boards also use the MS5611. I must be misunderstanding.

NHA, sorry if I am cluttering the thread, I am very interested in your code and just trying to understand how it compares to what else is out there.

oddcopter
Posts: 4
Joined: Tue Dec 06, 2011 6:37 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by oddcopter »

Well, I tried this out this afternoon and was very pleased considering it was my first pass and I am a multiwii novice. I am using a AIOP v1.0. All I did was uncomment the line "#define VARIO_ALT_MODE" and had a switch to activate the baro. It held altitude well. Certainly as good as my attempts with MegapriateNG, but not quite as well as the Naza yet. Of course, I did some quick setup and tuning, so that could be why. Overall, I am very impressed and will keep working with it. Thank you for your hard work Adrian!!

I was getting some strange random yawing, but don't think I have the Mag calibrated correctly which may be causing it. Dunno.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

It can be a faulty mag calibration!

You can check in the gui. First, check the 4 major directions, then try to turn the copter aroung roll/pitch by 20-30 degrees and watch the gui. The direction must not change!

BR
Adrian

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

im just wondering what is that BT module... 200m is a very decent range for short distance test... mind give a link about it?

thx

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

BT module and 3DR air modules also can be bought at rctimer.com, and in many other webshops too.
Just google around!

Mark_K
Posts: 22
Joined: Tue Oct 09, 2012 7:26 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Mark_K »

I apologize if this has been answered before...

The altitudes like RTH_ALT are they absolute heights based on the GPS or are they relative to the altitude that arming takes place?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Mark_K wrote:I apologize if this has been answered before...

The altitudes like RTH_ALT are they absolute heights based on the GPS or are they relative to the altitude that arming takes place?


They are all relative heights relative to armed ground level.

There would not be any sense on using GPS height, once because it is not so accurate and second, when you would modify config.h, you should know the exact place where you will fly after...

BR
Adrian

Mark_K
Posts: 22
Joined: Tue Oct 09, 2012 7:26 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Mark_K »

nhadrian wrote:There would not be any sense on using GPS height, once because it is not so accurate and second, when you would modify config.h, you should know the exact place where you will fly after...

BR
Adrian


Thanks! I was assuming this is right but wanted to check before I got to watch my quadcopter auger into the ground while RTH because I told it to fly -97m below ground. :D

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Today i flew R15 of NHAdrian on a Crius AIOP.

3 issues:

1- When in BARO mode, it dosen't beep when enters in altitude hold mode from climb or dive . So i still have to watch my stick carefully and a larger dead-band around has some counter-effects as described in 3.
2- Home altitude isn't reset at each arming so i had the surprise that after going on the other side of the road, i could not auto-land in rth mode.
3- After setting a clear dead-band (50us) around alt-hold position, when you are out of dead-band with throttle, the correction is calculated wrong from the middle point, not from middle point plus-minus dead band so you have a jump in altitude variation and can't set a slow variation just after exiting the dead band range .


Another issue was about GPS PH (not concerning baro)

After giving a waypoint more than 400m away (fpv mode with bluetooth, EZ-GUI android aplication), the PH went crazy and i have to reboot controller. No other tests were made after PH incident.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi Dramida,

here are my replies:
1.) I'll check the beep code, maybe can be solved easilly
2.) that's interresting because for me it resets on every arm. BTW, I'll check it again in code

*******Just to avoid any confusion for other users***********
Please note that in RTH mode I didn't have any auto-land feature!!!!!!!!!!!!!!!!!!!!!!
The only feature I have is descending to a safety altitude once home reached!
This is NOT an autoland feature since there isn't any ground sensing algoríthm in it, nor a slow-down one.
Maybe it can be used for autoland but generally not made for that purpose!!!

***********************************************************
3.) nice catch, I'll modify the code, not a big issue, but till now I didn't think on this... ;)

____________________________________________

About PH, that part wasn't touched in the code.
I'm still having the oppininon that the current MWI code is not capable for proper WP navigation, inserting WP16 by MSP and changing nav mode is only a forced solution but have many weak points. The complete restructure of navigation algorythm would be neccessary.... :S

I also tested the EZ-GUI PH modification within 80-100 m range, it worked quite well. (with BT + 3DR communication)
Unfortunatelly many things could cause that breakdown, even some overflow in navigation code caused by long distances....

BR
Adrian

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Thanks for reply, i will make further tests with your code. Keep up the good work :)

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

dramida wrote:Thanks for reply, i will make further tests with your code. Keep up the good work :)


2.) and 3.) are corrected. I'll upload once flight tests are done.
1.) is more tricky since for me it beeps when entering into hovering. BTW I'll try to find the problem.

BR
Adrian

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

nhadrian wrote:
dramida wrote:Thanks for reply, i will make further tests with your code. Keep up the good work :)


2.) and 3.) are corrected. I'll upload once flight tests are done.
1.) is more tricky since for me it beeps when entering into hovering. BTW I'll try to find the problem.

BR
Adrian

Hi Adrian, Thanks for improving MWC.
I want to make you a donnation in MWC components for helping the community. Please send me a PM list with what you want.

Question:
-What happens if i fly in a valley with altitudes lower than starting point?
-Can i set rth home altitude to -2m?

Easy improvements:
- when altitude is less than 7m and auto RTH enabled/ failsafe enabled, the altitude variation speed should be minimum, 25 cm/s (for a easy landing).(these values should be define-able) If i set 25 cm/s by default, it will take a loooong time to descent from 100m :)
- after reaching ground, if copter continues to descent, propellers will spin slower and slower. You could put a condition apliable only in descent with Altitude controlled mode that verifies when output throttle is less than 1300us fore more than 2-3 seconds.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi,

Please understand me but I don't want to make any autoland function for RTH only with BARO!
My oppinion is that RTH is made for bringing the copter back if any unwanted orientation loss/video signal loss in FPV happens.
Once it hovers on a safety altitude over home, control can be given back and land manually or continue the flight.

Autoland with automated slow down function is available in FAILSAFE_RTH routine, because failsafe means there is no any valid connection between transmitter/copter, so it must be taken down somehow. In that case autoland decreases the probability of crashes. But that's all!

A good autoland function should be taken into a separated function, for example to a switch: Take off/land position
For good autoland instead of baro and GPS, optical flow sensor and sonar must be used!
For this we need 2 things:
- optical flow sensor
- sonar sensor

We would need something like this:
https://pixhawk.ethz.ch/px4/modules/px4flow

Once sensor handling is implemented into MWI, values could be used for a SAFETY autoland feature!!! I'd be pleased to help making a good autoland/takeoff feature just like ie. in ar-drone...

So this is the reason why I would not support any improvements related to autoland except in FAILSAFE mode, I hope you understand my position.
____________________________________________

Dramida, I'll check out what happens if you fly lower than armed level!
So in my next release I'm sure it will be tested/solved if there will be any problem caused by negative value.
Please be patient for some days because it is snowing since many days here... :(

BR
Adrian

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Hi Adrian, most if not all FrSky radio users sets the failsafe of the receiver to RTH + Baro, with throttle at midpoint. Are you suggesting that receiver failsafe should not be used?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi Dramida,

I can't understand your question completely.

I like the current receiver failsafe code. The trigger is that any of first four channel drops under 980 us).
Most receivers have the same option (ie. Futaba FASST, FrSky, Graupner, etc. receivers all have a programmable failsafe option, that means receiver gives a pre-defined output on throttle channel when connection is lost).
But maybe also the RSSI could be used for that purpose, ie. if the RSSI signal is under 10% it goes to failsafe mode. I don't know how accurate the rssi output on a receiver is...
For Failsafe I suggest to use the FAILSAFE_RTH mode if GPS is available, and configure well the receiver output and failsafe mode.

So why there is an autoland feature in the failsafe routine?
Because maybe the connection error is caused not by distance but anything else (empty transmitter battery, etc), so even if the copter is back at the home position, the connection can't be restored. In that case copter will land to prevent any further crashes.

For normal flgiht, I strongly recommend to take off/land manually.

BR
Adrian

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

nhadrian wrote:Hi Dramida,

I can't understand your question completely.

I like the current receiver failsafe code. The trigger is that any of first four channel drops under 980 us).
Most receivers have the same option (ie. Futaba FASST, FrSky, Graupner, etc. receivers all have a programmable failsafe option, that means receiver gives a pre-defined output on throttle channel when connection is lost).
But maybe also the RSSI could be used for that purpose, ie. if the RSSI signal is under 10% it goes to failsafe mode. I don't know how accurate the rssi output on a receiver is...
For Failsafe I suggest to use the FAILSAFE_RTH mode if GPS is available, and configure well the receiver output and failsafe mode.

So why there is an autoland feature in the failsafe routine?
Because maybe the connection error is caused not by distance but anything else (empty transmitter battery, etc), so even if the copter is back at the home position, the connection can't be restored. In that case copter will land to prevent any further crashes.

For normal flgiht, I strongly recommend to take off/land manually.

BR
Adrian

Yes, i agree with you about auto-landing. It's only a last resort option. Thank you for making the concept clear. So i should re-bind the FrSky receiver to discard pre-defined failsafe values.

User avatar
KasparsL
Posts: 75
Joined: Wed May 16, 2012 3:31 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by KasparsL »

dramida wrote: So i should re-bind the FrSky receiver to discard pre-defined failsafe values.


Don't forget that if you re-bind the FrSky receiver, on TX signal lost it will output last values! Tu use MultiWii failsafe You need to push the button on receiver, while transmitter is OFF. Then RX will stop outputting anything on TX signal loss, witch can be detected by MultiWii.

Sorry for spam, if You already knew that ;)

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

You got me right!, thanks alot, i didn't knew that one!

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Tazzy »

Ok today i did try compile this code to my quad but as soon i activate the gps in code i get a fail.....
Probably because i have some config faults ....
it is a promini with gy86 and i2cgps , i will try it on my mega to see if that works better.


this is the line
//Home position reached
nav_mode = NAV_MODE_POSHOLD;
this ---->> TargetAltReached = 0; // reset parameter when switch mode
if (NAV_SET_TAKEOFF_HEADING) { magHold = nav_takeoff_bearing; }

with this fail
GPS.ino: In function 'void GPS_NewData()':
GPS:419: error: 'TargetAltReached' was not declared in this scope

Can anyone give me some tips ??

// Tazzy

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi, please send me your config.h to nhadrian@gmail.com I'll check it.
Also, please give some info what release do you try?

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

Multiwii_r1342_NHA_r16 release

Post by nhadrian »

Hi all,

I attached my latest release.

News:
- now it resets altitude on every arm, not only once after power on
- vario mode resolution increased (AltHold is now in mm instead of cm)
- the "gap" is removed when stick is out of the center deadband (Dramida's catch).

It is based on the official r1342 release.

I wish good luck!

BR
Adrian
Attachments
Multiwii_r1342_NHA_r16.zip
(165.12 KiB) Downloaded 144 times

Mark_K
Posts: 22
Joined: Tue Oct 09, 2012 7:26 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Mark_K »

Thanks for the work! Can I just replace the config.h with my existing one from your last release?

Mark_K
Posts: 22
Joined: Tue Oct 09, 2012 7:26 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Mark_K »

Mark_K wrote:Thanks for the work! Can I just replace the config.h with my existing one from your last release?


Alright, I answered my own question. :) Short answer is no...

Long answer is to windiff it and change the couple of differences.

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

Multiwii_r1343_NHA_r17

Post by nhadrian »

Tazzy wrote:Ok today i did try compile this code to my quad but as soon i activate the gps in code i get a fail.....
....
Can anyone give me some tips ??
// Tazzy


Hi all,

I attached my latest release:
- meerged with official r1343 - PLEASE NOTE THAT PROBABLY SOME PID ADJUSTMENTS WILL BE REQUIRED because the optimization in official release !!!
- fixed a BUG caused compilation error with I2C_GPS when nothing of my functions were uncommented //catch of Tazzy
- some code optimization in my code for faster calculations

BR
Adrian
Last edited by nhadrian on Sun Feb 17, 2013 12:15 pm, edited 1 time in total.

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

Multiwii_r1344_NHA_r17_EXPERIMENTAL

Post by nhadrian »

Hi all,

I made an experimental merge with the official r1344 release (more configurable values in GUI).

****** THIS IS NOT FLIGHT TESTED, JUST FOR THOSE WHO WOULD LIKE TO DEVELOP SOMETHING FROM MY CODE*******

In GUI it looks like all additional values works but not flight tested. Theoretically it should work, but please be patient!!!

BTW, I really like this idea to put many values into EEPROM since there is enough space for that!!!!
(my oppinion is that even more values should be uploaded to EEPROM, instead of ie. LOG functions.)

Can be used with the gui attached in the official r1344 release!!!

BR
Adrian
Attachments
Multiwii_r1344_NHA_r17_EXPERIMENTAL.zip
(168.69 KiB) Downloaded 129 times

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

I have used r16 on my test rig... the performance is just astonishing... it was able to maintain the altitude literally with in 15cm and the vario works like a charm... next thing i'm going to try is in windy day... hope everything works well too

what are the main differences in the later revs performance wise? if there isnt really much diff.. i would feel better just leave as is

:)

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

For me the new changes in IMU code gives better performance, till now I had some back-drift but now it disappeared.

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Multiwii_r1343_NHA_r17

Post by Tazzy »

nhadrian wrote:Hi all,

I attached my latest release:
- meerged with official r1343 - PLEASE NOTE THAT PROBABLY SOME PID ADJUSTMENTS WILL BE REQUIRED because the optimization in official release !!!
- fixed a BUG caused compilation error with I2C_GPS when nothing of my functions were uncommented //catch of Tazzy
- some code optimization in my code for faster calculations

BR
Adrian


Hi folks
I did try to compile r17 version and now i get GPS.ino:419:160: error: missing ')' in expression
with this config.h file https://dl.dropbox.com/u/20806695/config.h when i try to compile it lol

// Tazzy

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Here is a video with R15 of NHAdrian altitude hold, altitude variation, position hold.
The intro and outro are shot with some other multiwii tricopter last year.

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

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by alexia »

wouaaa incredible stability

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Uploaded R17

On my table, i found a few bugs:

Camera pitch has a bug, when tilting forward the copter, after a point dependent of Aux3 ch, the pitch servo does a full-reverse.

Beeps in baro mode are heard only when passing from climb -hold - dive or dive-hold- climb. If you try dive-hold-dive or climb- hold- climb, beeps are not present when switching modes.

I attached my config.h file
Attachments
config.zip
(78.72 KiB) Downloaded 118 times
Last edited by dramida on Mon Feb 18, 2013 6:07 pm, edited 2 times in total.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Are you using my camstab code or the original one?

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Oau, that was quick, please see the attachment on the previous post.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

a quicky.. where is the imu complimentary setting moved to? didnt find it in r17_exp

thanks

Mystic3D
Posts: 31
Joined: Sat Jan 12, 2013 2:33 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Mystic3D »

Was going to give r17 a try.
I get a compile error
GPS.ino:419:160: error: missing ')' in expression

I suspect it's becasue I am using I2C GPS.

config.h attached.

Nice work so far, was going to try on my Tri..... :) :D

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi all,

Here is the corrected r17, based on the official r1347 release!!!
The BUG was in I2C_GPS part.

BTW, my oppinion is that forget to use 328p and i2c GPS, it is not enough for naw functions.
There are great boards for less than 50 USD on market....
Also, WP16 injection does not work with I2C GPS!!!

reply to jy0933:
- IMU settings are removed from official release, not my change at all....

*****UPDATE: I cleaned config.h to default *****

BR
Adrian
Attachments
Multiwii_r1348_NHA_r17.zip
(165.37 KiB) Downloaded 122 times
Last edited by nhadrian on Thu Feb 21, 2013 6:09 am, edited 1 time in total.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Alexinparis »

Hi Nhadrian,

I appreciate your enthusiasm for bringing new things.
Here are some comments on your mods.
Some of them were already exchanged by mail 1 month ago and I think it’s important to trace things we said.
I focus only on the vario alt functionality.

There was in _shared a vario alt code introduced by mahowik introduced in r1266.
viewtopic.php?f=8&t=2371&p=26473#p26473
This code was removed after by mahovik because of some annex minor issues, but there was some good feedbacks.
dramida posted a video: viewtopic.php?f=8&t=2371&p=26473#p26601

The fact is: the control code of Mahowik is quite simple and works.
So a legitimate question: how does it compare with yours ?

Why do I think it’s important ?
1) flash size: the solution you suggest takes a lot of flash (more than 10k) and then does not compile on a 328p, nor a promicro where space is very limited.
2) complexity: do we need really to separate every case: rising in vario mode / descending in vario mode / rising to target / descending to target / any other case ?

The principle of vario Mahowik code is basically to modify the target alt.
You said we need another stage of regulation where we need to adjust PID factors depending on the situation. (the previous 5 possible cases)
And you introduced this idea here:
viewtopic.php?f=8&t=2371&start=420#p28200
with this assumption: “The problem is that BaroPID calculations are tuned for hovering, and can't allow high rising/descending speeds, even if AltHold parameter itself is changing as fast as it has to"
And the solution : “For proper code working when higher vario rates needed, I use variables in BaroPID calculations instead of stored eeprom values, which are modified according to ALT_HOLD code state"

So, to sum up my mind: to decide what to include, I must have a clear comparison of the benefit of your code regarding the old one based on user feedback because it's much more complex and takes more bytes.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi Alex,

thanks for your comment.
I have to repeat myself from our mailing.

My basic idea was to calculate an accurate vario, which doesn't depends on the cycle time at all.
So in my code I made an accurate calculation, where the total throttle stick range is divided for a defined vario range.
Within this range, the target vario is proportional to throttle stick position. The idea of modifying the PIDs was coming from my tests. The behaviour of the copter was not smooth enough in vario mode, so I started to think on the problem. Since I learnt some about regulations, I thought the problem is there. Maybe I'm right.
I don't know MAHOVIK's solution deeply, but If I remember right, vario was depending on cycle time mainly...

The complexity is because different target varios (independent if in manual or automated mode) needs different PID modifications for smooth working. I can't handle on other way.

Well, I feel like I'm on my own. The main reason why I started to post my code, to let others check/modify/think on it.
But, there was not even a small line suggestion what to modify, or input/remove from my code. I mean exact solution, code part, not only some "basic" ideas.
But, any input would still welcome.

I'm sure there are more simple solutions, I wanted only show a possible way of solving vario problem. But it was so good I started to use (and maybe some others), and still using during my FPV flights. And I'm really happy to have at least something like this.

About space problems, the RTH code and FAILSAFE RTH code was made for further nav purposes.
My oppininon is that 328p can't handle any navigation which is more complex than position hold, maybe RTH. For a MEGA 10k is not a problem.
And, there are many great panels on market equipped with MEGA and under 50 USD. This is only my private oppinion...

So, to be honest, the current state is the maximum I could get out of the "problem" on my own right now...
:(:(:(:(
Please understand my position.

BR
Adrian

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

I want to help judging for yourself from my flights with those two versions of altitude control software, Mahovik's and NHAdrian

Here is altitude control algorithm of Mahowik:
http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

here is altitude control of NHAdrian R15:
http://www.youtube.com/watch?v=lOczUY4kCLE

I like the altitude features of R15 because i can set "hold" stick position to 1500 and also i have a configurable dead band around it. But in quality of flight, it seems that R15 is a little jumpy in holding the altitude and variation also, it has small bumps when varying the altitude (hear the engines on min 1.39 of this video http://youtu.be/T51TSROoIk4?t=1m39s ).Overall NHA- R15 does the job and comes with many goodies like RTH with defined height and home target altitude and an improved failsafe with RTH and auto-landing.

I'll tell my opinion after, as i don't want to influence someone's.

Tests were made on a crius AIOP with 20 HZ LPF for MPU6050

ps. i didn't flew NHA R17 as i noticed a problem on gimbal pitch stabilisation on my tricopter. Also i suggest to leave the releases with config.h unconfigured, it's difficult to set up after some's other setup.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

nhadrian wrote:Hi all,

Here is the corrected r17, based on the official r1347 release!!!
The BUG was in I2C_GPS part.

BTW, my oppinion is that forget to use 328p and i2c GPS, it is not enough for naw functions.
There are great boards for less than 50 USD on market....
Also, WP16 injection does not work with I2C GPS!!!

reply to jy0933:
- IMU settings are removed from official release, not my change at all....

BR
Adrian


no biggy... you got any clue where is it now?

thanks

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

jy0933: in IMU.ino you'll find the settings.
Dramida: I cleaned the config.h in the previously uploaded R17. BTW I suggest to use diffmerge for moving your settings to a new config.h. This program is really simple, on the left is your previous file on the right is your new file. All differences are marked and you can go through step by step. Merging a config.h takes less than a minute!!!

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

dramida wrote:Uploaded R17

On my table, i found a few bugs:

Camera pitch has a bug, when tilting forward the copter, after a point dependent of Aux3 ch, the pitch servo does a full-reverse.

Beeps in baro mode are heard only when passing from climb -hold - dive or dive-hold- climb. If you try dive-hold-dive or climb- hold- climb, beeps are not present when switching modes.

I attached my config.h file


Dramida, I can't open the config.h inside your zip! Please try to attach the config.h itself. There is a problem with the file coding...

BTW, IMU calculations changed in the official releases so maybe that causes your gimbal problem. Are you using SERVO_TILT_NHADRIAN or original SERVO_TILT ?
I'm using camera stabilization with SERVO_TILT_NHADRIAN but I have no issues at all. Although my camera stabilization code is quite simple and basic, vould be solved on a more elegant programming way... but it takes the job for me.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by dramida »

Hi Adrian, I guess i disabled your mood regarding gimbal. I reattach the config.h file
config.zip
(20.94 KiB) Downloaded 114 times


Bug: when i tilt the copter in front (pitch), camera gimbal works as expected and compensate, but when reaching a 40 drgrees angle or so (depending on Aux 3 ch for pitch control), the pitch servo does a full reverse. I checked the servo with a tester and works ok, also gimbal works fine on previous R15 version.

Post Reply