Altitude Hold/Advanced Failsafe solutions by NHA

nhadrian · Post by **nhadrian** » Thu Feb 21, 2013 4:38 pm

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 · Post by **Alexinparis** » Thu Feb 21, 2013 4:43 pm

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 · Post by **Tazzy** » Thu Feb 21, 2013 8:13 pm

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

dramida · Post by **dramida** » Thu Feb 21, 2013 8:58 pm

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 · Post by **subaru4wd** » Fri Feb 22, 2013 5:14 am

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

dramida · Post by **dramida** » Fri Feb 22, 2013 11:04 am

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_____ · Post by **flyboy_____** » Mon Feb 25, 2013 3:37 pm

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 · Post by **jy0933** » Mon Feb 25, 2013 4:22 pm

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

dramida · Post by **dramida** » Wed Feb 27, 2013 11:24 am

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.

nhadrian · Post by **nhadrian** » Wed Feb 27, 2013 8:35 pm

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 · Post by **nhadrian** » Thu Feb 28, 2013 6:08 am

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

dramida · Post by **dramida** » Thu Feb 28, 2013 8:38 pm

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 · Post by **jy0933** » Thu Feb 28, 2013 11:29 pm

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)

dramida · Post by **dramida** » Fri Mar 01, 2013 12:13 am

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 · Post by **nhadrian** » Fri Mar 01, 2013 6:18 am

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.

ezio · Post by **ezio** » Fri Mar 01, 2013 7:46 am

Waiting for a video.

dramida · Post by **dramida** » Fri Mar 01, 2013 9:52 am

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 · Post by **nhadrian** » Fri Mar 01, 2013 4:40 pm

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 · Post by **nhadrian** » Sat Mar 02, 2013 11:49 am

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

jy0933 · Post by **jy0933** » Sun Mar 03, 2013 4:47 am

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 · Post by **nhadrian** » Tue Mar 05, 2013 4:12 pm

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

ezio · Post by **ezio** » Wed Mar 06, 2013 1:34 am

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

Leon11t · Post by **Leon11t** » Wed Mar 06, 2013 6:02 pm

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 · Post by **nhadrian** » Wed Mar 06, 2013 6:57 pm

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

Leon11t · Post by **Leon11t** » Wed Mar 06, 2013 8:13 pm

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

nhadrian · Post by **nhadrian** » Wed Mar 06, 2013 8:27 pm

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

dramida · Post by **dramida** » Wed Mar 06, 2013 10:39 pm

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 · Post by **scanman** » Sat Mar 09, 2013 8:27 am

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.

nhadrian · Post by **nhadrian** » Sat Mar 09, 2013 10:16 am

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 · Post by **nhadrian** » Sat Mar 09, 2013 3:52 pm

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

jy0933 · Post by **jy0933** » Sat Mar 09, 2013 9:42 pm

Adrian... about sonar...

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

nhadrian · Post by **nhadrian** » Sat Mar 09, 2013 10:00 pm

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

dramida · Post by **dramida** » Mon Mar 11, 2013 12:59 am

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 · Post by **ardufriki** » Thu Mar 14, 2013 11:31 am

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 · Post by **nhadrian** » Thu Mar 14, 2013 11:50 am

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 · Post by **ardufriki** » Thu Mar 14, 2013 12:19 pm

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 · Post by **Goetz** » Fri Mar 15, 2013 7:01 pm

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 · Post by **nhadrian** » Fri Mar 15, 2013 7:13 pm

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

dramida · Post by **dramida** » Fri Mar 15, 2013 10:35 pm

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 · Post by **Peter** » Sun Mar 17, 2013 12:07 am

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 · Post by **Eric** » Mon Mar 18, 2013 5:51 am

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 · Post by **Eric** » Mon Mar 18, 2013 6:43 am

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

Goetz · Post by **Goetz** » Mon Mar 18, 2013 1:36 pm

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 · Post by **nhadrian** » Mon Mar 18, 2013 5:04 pm

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

nhadrian · Post by **nhadrian** » Mon Mar 18, 2013 5:17 pm

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

ezio · Post by **ezio** » Mon Mar 18, 2013 11:53 pm

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.

Eric · Post by **Eric** » Tue Mar 19, 2013 5:17 am

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.

Eric · Post by **Eric** » Tue Mar 19, 2013 5:58 am

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

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

nhadrian · Post by **nhadrian** » Tue Mar 19, 2013 6:32 am

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 · Post by **Eric** » Tue Mar 19, 2013 6:44 am

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.