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 »

Yes, I see. So there must be something with the official release.

Could you please test if the same exists with the official r1348 release? If yo, than I can't help... :(

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Alexinparis »

dramida wrote:Hi Adrian, I guess i disabled your mood regarding gimbal. I reattach the config.h file
config.zip


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.


I think the response is here:
#define TILT_PITCH_MIN 1000 //servo travel min, don't set it below 1020
;)

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Tazzy »

THANKS Adrian for your grate works on this release i LOVE IT ;) (r17)
The vario function is so nice out off the box with std pids :) the only thing i need to find out is why it oscillate little when i activate pos hold ....
Dramida do you have some adjustments tips on the ph oscillation ?

// 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 »

Hi, i also observed that circular oscilations ocurs for a few seconds when GPS PH is enabled when moving in one direction.
I tried to raise GPS leaning coefficient P from 1.8 to 3 and seems better. Also you have to calibrate the mag on the field, without metal objects nearby ( less than 2 m) when calibrating and check magnetic declination of your location.
Good luck and please share your experience.

Tazzy wrote:THANKS Adrian for your grate works on this release i LOVE IT ;) (r17)
The vario function is so nice out off the box with std pids :) the only thing i need to find out is why it oscillate little when i activate pos hold ....
Dramida do you have some adjustments tips on the ph oscillation ?

// Tazzy

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by subaru4wd »

Adrian, do we know if any of your code made it into the 2.2 release?

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 »

Alexinparis wrote:
dramida wrote:Hi Adrian, I guess i disabled your mood regarding gimbal. I reattach the config.h file
config.zip


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.


I think the response is here:
#define TILT_PITCH_MIN 1000 //servo travel min, don't set it below 1020
;)


Alex & Adrian, thank you for the catch :) i'll install today NHA R17 on one of my copters to test it :)

flyboy_____
Posts: 33
Joined: Thu Sep 15, 2011 10:45 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by flyboy_____ »

If we use 5 baros in the board, kill the 2 most off values and take the average of the closest value, dosn't this give a more precise altitude reading??

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

flyboy_____ wrote:If we use 5 baros in the board, kill the 2 most off values and take the average of the closest value, dosn't this give a more precise altitude reading??


they will most likely read about the same

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 tested NHA R17 on a quad and a tricopter, both with Crius aiop.

On the quad all worked OK. (the beep-ing when entering in vario mode outside AltHold dead band are still missing)

On the tricopter the altitude hold was imprecise as if AccZ was failing. Once when i activated altitude hold (the throttle stick was in middle dead band), copter plunged down about 10m and i quickly disabled Alt Hold before crushing. After that, i uploaded the latest dev r1359 on the same tricopter and everything is good as it should. Here is the config.h if is of some interest.
Attachments
config.zip
(20.95 KiB) Downloaded 159 times

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

That's interresting with your tri. I'll check config!!! The interresting is that there is nothing frame-specific in my code... :S

About beep issue, it would need deeper modification in the code for proper beep working.
I can't see the benefit of spending many hours on this function. Because if the copter is close, it "feels' where is the hovering point.
If the copter is far during FPV flight or filming, beep can't be heared.

BR
Adrian

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

I just updated the EZ-GUI by Ezio. There is an altitude injection in the map too!
Since I'm using a pre-defined altitude for HOME, that will be easy to implement the home altitude change feature.
But, I want to implement a feature for HOLD mode too, that means that during vario mode, if a WP is inserted, copter will rise/descend to the altitude sent by WP.

I hope it'll take less than a week.

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:That's interresting with your tri. I'll check config!!! The interresting is that there is nothing frame-specific in my code... :S

About beep issue, it would need deeper modification in the code for proper beep working.
I can't see the benefit of spending many hours on this function. Because if the copter is close, it "feels' where is the hovering point.
If the copter is far during FPV flight or filming, beep can't be heared.

BR
Adrian


Hi you are right about beying frame specific, the same falling in alt hold happened with dev r1349 pre2.2 MWC today and i recorded it on FPV OSD.
The beeps can be heared through fpv system but now with a definable dead band and a specific throttle hold position, the beeping is useless. So you are right again, you can forget about beeping when modifying altitude.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

it also behave a bit wired on my hexa...

ver R17....

when stick is above middle dead band.. it suddenly jump up half meter... (and caused battery alarm)... my quad was using r15 w/o this problem... might be i set too much D for alt hold (D=60) in R 17? (D=60 on quad for r15..working fine...but I will start wondering what is the conversion factor between old pid and new pid)

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 »

jy0933 wrote:it also behave a bit wired on my hexa...

ver R17....

when stick is above middle dead band.. it suddenly jump up half meter... (and caused battery alarm)... my quad was using r15 w/o this problem... might be i set too much D for alt hold (D=60) in R 17? (D=60 on quad for r15..working fine...but I will start wondering what is the conversion factor between old pid and new pid)

Maybe it's time to tweak config.h parameters. Adrian, can you tel us more about this?

Code: Select all

/********** developer tunable parameters - PID correction for rising/descending ************/
 
    #define VARIOALTP_CORR 40   // For test and developer purposes only!!!  -  ALT-P correction during rising
    #define VARIOALTI_CORR 20   // For test and developer purposes only!!!  -  ALT-I correction during rising
    #define VARIOALTD_CORR 20   // For test and developer purposes only!!!  -  ALT-D correction during rising
 

And why you differentiated rising from descending?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi,

Yes and no... :S
The reason why I differentiated rising from descending is that copter behaves not the same for rising/descending.
Just a short example you can even try with your copter. Let's say copter hovers at 1500 us throttle signal (can be measured via GUI).
First apply +50 (for example use a 3-way switch for +-50 offset on throttle), it will start to raise slowly.
Then, apply -50. it will start descending. But, the descending speed will be higher!!! Even the absolute value is the same....

Generally speaking, for rising we must have higher gains to follow the AltHold value changing, but if the same would applied in descending would lead to low rpms which possibly cause wobbling and uncontrolled falling. (With a variable pitch copter it wouldn't be a problem since there is constant RPM, even when general pitch is near 0, roll/pitch axis can be stabilized)

till now I didn't have time to adjust the CORR values, I'm still concentrating on code itself.
What I can suggest is to test them and figure out what is the best for your copter.

(BTW, the same like with the PID values itself, nobody can tell what is the best way of finding the best PID values for altitude hold...)

BR
Adrian

ps.: I'm ready with the modifications, I'll test at the weekend with EZ-GUI. What I expect is that hovering somewhere in HOLD mode with active VARIO_ALT mode. If I insert a new HOLD point with altitude via EZ-GUI, copter will move to the new WP, also rise/descend to the target altitude (for safety reasons, if throttle input is higher that 2x NEUTRAL ZONE, it will disarm temporary the automatic control). After reaching target altitude, vario control is back, so altitude can be changed via throttle stick.
Also, the pre-defined home altitude can be reset using EZ-GUI.

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Odp: Altitude Hold/Advanced Failsafe solutions by NHA

Post by ezio »

Waiting for a video.

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:.........
The reason why I differentiated rising from descending is that copter behaves not the same for rising/descending.
...........
Generally speaking, for rising we must have higher gains to follow the AltHold value changing, but if the same would applied in descending would lead to low rpms which possibly cause wobbling and uncontrolled falling. (....
BR
Adrian


Hello Adrian, i am happy to see other sharing same hobby (sharing means they code and i fly ;) )

I see the gravity just an offset. It's the same like tricopter yaw, the copter always tends to rotate in a specific direction but a single PID loop does the trick. The "trick" is to use enough I term to compensate the continous gravity offset. So for tricopter Yaw, we don't have two sets of parameters, as PID loop can correct unbalanced behaviour. As Alex from Paris said, rewriting the alt variation algoritm as a whole will bring consistence, smaller memory usage (328) and better tweaking.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

The problem is that there is far far not linear relation between ESC input (RPM for a simonk firmware) and traction on motor axle.
It is even worse because when descending, props gets negative flow, and this will cause lot of turbulences.
(for a tricopter, the situation is not the same. Anyway, if you think through the process, you will see that we have an offset, the offset is the hovering throttle...)

BTW, dramida you could help me a little bit! If you set all corr values to 0, then you will get "untouched" PID control. You could share your experiences, maybe you have right and not any corr values should be used.

Alex don't like the idea of touching the val_tmp value, but, it is a must, since the D term always tries to keep 0 velocity. If for example I'd ascend with 100 cm/s, the D term would always stop the copter. Since D part is quite fast in this form (NOT A REAL D-TERM!!!!! don't forget this...) it will lead to a bouncy behaviour. So vel_tmp MUST BE SHIFTED with target vario for smooth behaviour.

BR
Adrian

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Hi all,

I attached my r18, based on r1353 official release!
Changes:
- introducing struct for storing WP 1-16 datas (0 is HOME, 1 is HOLD 2-15 is reserved for further WP usage...)
- altitude upload for HOLD and HOME works now great with EZ-GUI (don't forget to enable hidden functions with pressing yelow bar at GPS tab!!!)

DON'T FORGET TO PAY SERIOUS ATTENTION AT THE FIRST TIME!
TRY IT ON YOUR OWN RISK!!!

Here is a smart test video, sorry for quality but I only have a mobile phone for recording...
On the video first I sent 8m for altitude, then 6 m for the next WP...:

http://youtu.be/KxCjX17b-Kw

BR
Adrian

ps.: I'm using a 433 MHz 3DR telemetry module for telemetry, the "receiver" module is connected to the BT module.
I tried several settings for modules but still have unstable connection... :(:(:(

Any suggestion on setting 3DR modules?!?!?!
Attachments
Multiwii_r1353_NHA_r18.zip
(166.95 KiB) Downloaded 143 times

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

just a quick vid on my quad.. r15(cuz i hate re tuning pid)

but it works really well

http://www.youtube.com/watch?v=9nbb35CJoVI

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

Multiwii r1358 NHA r19

Post by nhadrian »

Hi All,

I attached my latest revision, r19:
- correction values are removed, I made several test, a well-tuned alt PID can handle vario mode too (dramida, you had right)
- save around 400k space
- some optimizations
- vell_tmp is shifted directly via target vario (Alex, it is a must, in Arducopter, they're making something similar)

-the WP altitude injection works great with EZ-GUI (thanks to EZIO!!!), I posted a sample video earlier.

please note that all WP functions will work with serial GPS only, because the implementation is not done officially.

And the most important, TRY IT ON YOUR OWN RISK... ;)

BR
Adrian
Attachments
Multiwii_r1358_NHA_r19.zip
(166.29 KiB) Downloaded 254 times

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: Multiwii r1358 NHA r19

Post by ezio »

nhadrian wrote:Hi All,

I attached my latest revision, r19:


-the WP altitude injection works great with EZ-GUI (thanks to EZIO!!!), I posted a sample video earlier.


BR
Adrian

glad to hear it

User avatar
Leon11t
Posts: 38
Joined: Thu Sep 27, 2012 12:24 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Leon11t »

I just got out of the field! Tested your firmware. Alt Hold works just fine. I did not feel the difference compared to the other versions. EZIO staff, could not to test.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Leon11t wrote:I just got out of the field! Tested your firmware. Alt Hold works just fine. I did not feel the difference compared to the other versions. EZIO staff, could not to test.


Hi,

thanks for your feedback!!! That means PID values don't need corrections indeed...

BR
Adrian

User avatar
Leon11t
Posts: 38
Joined: Thu Sep 27, 2012 12:24 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Leon11t »

Image
This is my PIDs.
They from Mahowik firmware. I thing for FPV its good PIDs.

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Leon11t wrote:This is my PIDs.
They from Mahowik firmware. I thing for FPV its good PIDs.


Hi,

PIDs hardly depend on the configuration, for example I have P7.0 I60 D70 for my copter, but this is a really small Y6 with 500g AUW....

What I was saying is that if the alt PIDs are tuned well for hovering, it is good for vario mode too (it looks like you have them for your config... ;) )
That's why you don't feel really difference between r19 and earlier releases, although I removed the PID correction code part.

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 suggest you to try the auto-land feature without sonar in home location only (as we already know the altitude from baro).

At about 4-5m height, the descent rate is lowered to 25 cm/s

AccZ in conjunction with baro could give you a good indication when to slow down the descend and when to turn off the motors.

Pid loops are usualy correcting small errors in flight, less than a meter. in landing procedure, when the copter touches the ground and the target altitude is lowered below ground level, the error in pid loop will greatly increase continously, as the time passes. This by itself coud trigger shutting down motors.

scanman
Posts: 74
Joined: Thu Jun 21, 2012 9:26 am
Location: Durban, South Africa
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by scanman »

Hi it tried the failsafe on the bench with the props off, it works fine without the NHA defines - motors spin for 30 seconds then disarm, however with the NHA defines, the motors only spin for 3 seconds then disarm, is this correct behaviour?
my settings are attached.

failsafe.JPG

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

scanman wrote:Hi it tried the failsafe on the bench with the props off, it works fine without the NHA defines - motors spin for 30 seconds then disarm, however with the NHA defines, the motors only spin for 3 seconds then disarm, is this correct behaviour?
my settings are attached.


Hi,

If you don't have valid GPS data (ie. tested inside a building) it is normal.
This behaviur is because the disarm is triggered via engine RPM. Once failsafe is active, it starts to descend. When it hits ground, it can't descend anymore, but ALT CODE still would force to descend.
So the RPM will be less and less. It the RPM is small enough, it dill disarm copter.

This behaviour is hard to be seen without props!!!

What I suggest is to put on props, hold down copter on the ground STRONGLY and arm it. Apply hovering throttle than turn off TX. What you have to see is that RPM is less and less then disarms.
ALSO BE PREPARED TO DISCONNECT BATTERY IN CASE SOMETHING GOES WRONG!!!

BR
Adrian

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

Multiwii r1360 NHA r20 - Autoland feature

Post by nhadrian »

Hi All,

I attached my r20 revision:
- intorducing Autoland checkbox item/function:
Image

- right now autoland uses only BARO, it means THE GROUND SENSING IS JUST CALCULATED!!!
- Autoland works only with GPS / valid GPS data
- Autoland activates RTH and BARO, so don't need to activate them separated
- first copter returns to home like before, on a safety altitude, then descends fast to the safety altitude. Then slows down, and descends with slow vario.
- when touches ground, RPW will continue decreasing
- when RPM is slow enough, it disarms.
- please note that my oppinon is that SONAR should be used for Autoland!!! I'll try a MAXBOTIX one, and then integrate to the code...

Here is a small video (please note that ther was small ghusts, that caused copter move away by 2-3 meters but nav code corrected during descending...:D
In the video the whole RTH and landing procedure were automatic!!!
******UPDATE: here is a better quality video**********
http://youtu.be/YMloNuyMD08

I tested it with a MEGA2560 (CRIUS AIO PRO) and SERIAL GPS. It should work with I2C GPS also but I can't test because I haven't got any device.

As always, TRY IT ON YOUR OWN RISK, THIS PROJECT IS UNDER DEVELOPMENT!!!

BR
Adrian
Attachments
autoland.jpg
(10.59 KiB) Not downloaded yet
Multiwii_r1360_NHA_r20.zip
(166.51 KiB) Downloaded 459 times

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by jy0933 »

Adrian... about sonar...

how about the SR-04? it's much cheaper and working

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

jy0933 wrote:Adrian... about sonar...

how about the SR-04? it's much cheaper and working


Hi,

I don't have any sonar but I'll receive one Maxbotix soon.
So I'll try that one first...
It has analog and PWM output so really easy to use...

BTW, SR04 is cheap indeed but STILL there is not any support in official Multiwii, so useless...
Once it will have support in MWI, it'll worth to try.

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 »

This release with autoland is a must have for fpv! Thanks Adrian! I'll test it on my specially built test quad with crius aiop.I hope i'll post soon a video also.

ardufriki
Posts: 88
Joined: Thu Dec 13, 2012 4:47 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by ardufriki »

Sorry, I am a little bit confused. I have a I2C NAV with CRIUS GPS v2. It seems to work PH and RTH modes. But....

- Would this "mod" work with my card or only with ATmega2560 proccessor?
- Are you going to release a new versión merged with MW v2.2?
- Is this a mod to be included in future versions of MultiWii (i.e. v2.3 or development releases)?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

ardufriki wrote:Sorry, I am a little bit confused. I have a I2C NAV with CRIUS GPS v2. It seems to work PH and RTH modes. But....

- Would this "mod" work with my card or only with ATmega2560 proccessor?
- Are you going to release a new versión merged with MW v2.2?
- Is this a mod to be included in future versions of MultiWii (i.e. v2.3 or development releases)?



Hi,

First, my r20 code is already merged with 2.2 since 2.2 IS THE SAME as r1362 in Muultiwii sared!!!!!
I have never tested with I2C GPS. My oppinion is that mega2650 should be used for any navigation function more than hold.... BTW if your config code is small be enough for 328p it can be used. I will never look at code size reduction!!!!
About merging, without any help in coding it will never be in multiwii official code!!!
But this position is good for me, I'm having great flights and maybe some others too using my code revisions....

BR Adrian

ardufriki
Posts: 88
Joined: Thu Dec 13, 2012 4:47 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by ardufriki »

In my case I have modified the code (r1362 and earlier) including a small hack in my receptor (cheap turnigy 9x8c) as it doesnt have FAILSAFE.

Now I trigger FAILSAFE through A6 PIN, connected inside the rx (status led inside) and comparing the input volts with a constant value. If the value is good then I actualize the Failsafecount variable.

It works , but your new coded features are amazing, so I will flash and try to modify in order to get it working.

For now, the size of the compiled .hex seems to fit in the 328p. I will try, thanks,

Goetz
Posts: 82
Joined: Sun Mar 04, 2012 3:40 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Goetz »

first of all: congratiulations, this mod is great, many good ideas, and they are working, very good work.

Safety for the Copter in mind, I have two Ideas:

1) Loosing RC-Connection is in most of the cases a question of the Copterposition. When the Copterposition is recorded during flight with good RC-Connection, in Failsave this recorded point of last RC-signal should be a good RTH-Point to get back RC-Connection in most Cases.


2.nd Point is quite a new toppic, but cause of the savety Idea I post it here:
I Ihink most of the flat Hexas could hoover and do an emergency-flight as a quad; Y6 as an Y4. So if Sensors recognice the need of serious, continous YAW-Correction over a certain time, it would be nice to have the software to switch to another configurationset with different motormixing and PID-Values in flight...? I think alternative PID-Sets are switchable already, so if Motormixes could be added, software could invoke an emergency-flightmode when one Motor/ESC/Prop is damaged to brig the Copter home...

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Goetz wrote:first of all: congratiulations, this mod is great, many good ideas, and they are working, very good work.

Safety for the Copter in mind, I have two Ideas:
...



Hi,

first of all I'm glad to hear you are happy with my code.
About last copterposition, there is far small memory for continous recording the flight.
If you have a signal loss, it can be the trigger but what is the guarantee of having signal back at that point?
I think the home is the most relevant target in Failsafe because when copter is closer and closer signal will be back (unless battery problem in TX... :) )

About second one, maybe you should start a topic in Ideas...;)

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 »

A week ago i saw someone's hexa distroyed because one prop failure.

First the hexa started to rotate on yaw uncontrolable but it could still keep level. The rotation actually helps to keep it level. But the pilot was unable to react and land the copter and tried to steer it by leaning. On that point the copter flipped and slamed into the ground. An algoritm for a parachute trigger and kill all motors could save the day.

Peter
Posts: 82
Joined: Mon Jun 11, 2012 2:09 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Peter »

I think I have seen once a naza controller that automatically switched to head free mode when one of the six failed. So you could steer it while rotating.

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

Check the code, found it won't work with an I2C gps nav board.
It relies on mod_nav, which is not used by i2c gps nav. We have to do such modifications:
1. when send i2c gps command, update nav_mode
2. we the i2c gps is in waypoint mode, after it reaches the waypiont, it updates from wp mode to poshold mode, have to sync this to mwc, then mwc starts to land.

Here are my projects with modifications, thanks a lot.

https://github.com/Smartype/I2C_GPS_NAV_v2_2
https://github.com/Smartype/MultiWii

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

Ignore my post. I did not see the modifications in GPS.ino. sorry for this.

Goetz
Posts: 82
Joined: Sun Mar 04, 2012 3:40 pm

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Goetz »

nhadrian wrote:...About last copterposition, there is far small memory for continous recording the flight.
If you have a signal loss, it can be the trigger but what is the guarantee of having signal back at that point?
I think the home is the most relevant target in Failsafe because when copter is closer and closer signal will be back (unless battery problem in TX... :) )

About second one, maybe you should start a topic in Ideas...;)

BR
Adrian


I don#t think of recording whole Flight, only last position, overwriting next time again. I think with FPV Orientation is not so easy and there is easily something between RX+TX like Hill / House. Failsave with direkt Line return would end in an Crash, because there is something in between (Hill / House...)

Isn't there an RSSI-measuring in new MW... ...as an crteria "only record new Position if RSSI is good"?

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Eric wrote:Ignore my post. I did not see the modifications in GPS.ino. sorry for this.


Hi,

no problem!
BUT!
There is a new option in BART's EZ-GUI android app. It lets you send new WP for HOME/HOLD+altitude, via MSP.
It works great in the air with serial GPS, but is not implemented to I2C_GPS.
If you are interrested, you could try it for the community... :D

BR
Adrian

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Goetz wrote:[
I don#t think of recording whole Flight, only last position, overwriting next time again. I think with FPV Orientation is not so easy and there is easily something between RX+TX like Hill / House. Failsave with direkt Line return would end in an Crash, because there is something in between (Hill / House...)

Isn't there an RSSI-measuring in new MW... ...as an crteria "only record new Position if RSSI is good"?


Let me introduce my position.

I attached a small sketch, for example copter moves on the blue line, take off at home.
At the end of the blue line, RSSI drops down, so copter stores the 90% RSSI position.
Then RSSI drops even more down, at 40%, FAISAFE activates (via RSSI or receiver setup).

BUT there is an obstackle between us and the copter (that causes perhaps the signal lost), copter will hit on both method.

That's why I introduced the safety alt in my function!!! If you know well your field, you can determine a safety alt, so copter will descend to that altitude and continues home on that altitude.
In this way, if safety altitude is high enough (can be 40-50 m ore ven more), it will avoid collision.

BR
Adrian

About RSSI, I tried the RSSI input via analog, still noisy (at least for me), it youldn't be used for failsafe, because it always would trigger the failsafe.
But, Once I can solve this, I'll implement this feature, BTW it is only some lines in code...

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by ezio »

nhadrian wrote:
Eric wrote:Ignore my post. I did not see the modifications in GPS.ino. sorry for this.


Hi,

no problem!
BUT!
There is a new option in BART's EZ-GUI android app. It lets you send new WP for HOME/HOLD+altitude, via MSP.
It works great in the air with serial GPS, but is not implemented to I2C_GPS.
If you are interrested, you could try it for the community... :D

BR
Adrian


actually setting Home position works with i2c gps.
I'm still not sure about setting position hold, but looking in to the code it should work too.

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

ezio wrote:
nhadrian wrote:
Eric wrote:Ignore my post. I did not see the modifications in GPS.ino. sorry for this.


Hi,

no problem!
BUT!
There is a new option in BART's EZ-GUI android app. It lets you send new WP for HOME/HOLD+altitude, via MSP.
It works great in the air with serial GPS, but is not implemented to I2C_GPS.
If you are interrested, you could try it for the community... :D

BR
Adrian


actually setting Home position works with i2c gps.
I'm still not sure about setting position hold, but looking in to the code it should work too.


You can set/write any WP in I2C gps, just i2c write to the registers from I2C_GPS_WP0 to I2C_GPS_WP15, then do a I2C_GPS_COMMAND_START_NAV with the waypoint number.

Postion hold works for the current position only. And when it reaches a way point, it holds automatically.

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

Ok, I added setting home/hold from serial support for I2C gps.

https://github.com/Smartype/MultiWii/co ... 85497f22f6

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

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by nhadrian »

Eric wrote:Ok, I added setting home/hold from serial support for I2C gps.

https://github.com/Smartype/MultiWii/co ... 85497f22f6


Thanks.
I'll look after soon.

BTW, I have success with ADNS 3080 motion sensor and with demo application!!!
With the python-based image grabber I can see the grabbed pictures now!!!
So I think now I would be able to add the 3080 handling to your I2C_GPS code.

BR
Adrian

Eric
Posts: 38
Joined: Thu Nov 08, 2012 7:08 am

Re: Altitude Hold/Advanced Failsafe solutions by NHA

Post by Eric »

nhadrian wrote:
Eric wrote:Ok, I added setting home/hold from serial support for I2C gps.

https://github.com/Smartype/MultiWii/co ... 85497f22f6


Thanks.
I'll look after soon.

BTW, I have success with ADNS 3080 motion sensor and with demo application!!!
With the python-based image grabber I can see the grabbed pictures now!!!
So I think now I would be able to add the 3080 handling to your I2C_GPS code.

BR
Adrian


The optical flow code was in the multiwii board, by adding gps code, the flash space is tight. So I moved it to i2c gps board.
I have only 260 bytes left :-(
Binary sketch size: 30,460 bytes (of a 30,720 byte maximum)

By the way, my optical flow sensor is mounted on the arm, so I rotated the dx, dy 45 degree. You may do not have to do that.

Post Reply