Altitude Hold/Advanced Failsafe solutions by NHA
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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...
Could you please test if the same exists with the official r1348 release? If yo, than I can't help...
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Altitude Hold/Advanced Failsafe solutions by NHA
dramida wrote:Hi Adrian, I guess i disabled your mood regarding gimbal. I reattach the config.h file
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
Adrian, do we know if any of your code made it into the 2.2 release?
Re: Altitude Hold/Advanced Failsafe solutions by NHA
Alexinparis wrote:dramida wrote:Hi Adrian, I guess i disabled your mood regarding gimbal. I reattach the config.h file
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
-
- Posts: 33
- Joined: Thu Sep 15, 2011 10:45 am
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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??
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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)
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)
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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?
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
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.
Odp: Altitude Hold/Advanced Failsafe solutions by NHA
Waiting for a video.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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?!?!?!
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
but it works really well
http://www.youtube.com/watch?v=9nbb35CJoVI
Multiwii r1358 NHA r19
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
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
Re: Multiwii r1358 NHA r19
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
This is my PIDs.
They from Mahowik firmware. I thing for FPV its good PIDs.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
my settings are attached.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Multiwii r1360 NHA r20 - Autoland feature
Hi All,
I attached my r20 revision:
- intorducing Autoland checkbox item/function:
- 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...
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
I attached my r20 revision:
- intorducing Autoland checkbox item/function:
- 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...
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
Adrian... about sonar...
how about the SR-04? it's much cheaper and working
how about the SR-04? it's much cheaper and working
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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)?
- 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)?
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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,
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,
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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...
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...
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
Ignore my post. I did not see the modifications in GPS.ino. sorry for this.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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"?
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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...
BR
Adrian
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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...
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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...
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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...
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.
Re: Altitude Hold/Advanced Failsafe solutions by NHA
Ok, I added setting home/hold from serial support for I2C gps.
https://github.com/Smartype/MultiWii/co ... 85497f22f6
https://github.com/Smartype/MultiWii/co ... 85497f22f6
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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
Re: Altitude Hold/Advanced Failsafe solutions by NHA
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.