GPS Navigation

DorsetFlyer · Post by **DorsetFlyer** » Tue Jul 08, 2014 10:22 am

I have a question about GPS navigation, specifically in MultiWii 2.3_navi_b5_baro_fix. I have set #define RTH_ALTITUDE, so the barometer is needed for RTH as well as the magnetometer. Do I need to set BARO and MAG as well as GPS HOME in RC Control Settings or does the firmware “know” to use the barometer and magnetometer? The same applies to MISSION. Another question. In MISSION there is a “Land Here” option. How does this work in view of the uncertainty in the landing point height and the barometer error? And finally, what does the LAND option in RC Control Setting actually do?

pjman · Post by **pjman** » Wed Jul 09, 2014 2:13 am

I am a noob so can't answer most of your questions. What I can tell you is that just this morning I had a crack at tuning pos hold myself. I couldn't see any response when I turned on pos hold only. I had to turn on angle mode at the same time before it would work. With this in mind I suspect you will need to add baro and mag to your GPS home position switch.

brewski · Post by **brewski** » Wed Jul 09, 2014 2:39 am

Before using Mag do the following.
Connect quad to PC Configurator using either USB or Bluetooth. Have props on & connect Lipo. Hold quad tightly, Arm & increase throttle to max while watching Compass in Configurator. If compass changes more than about 10 degrees it will be totally useless when using GPS or Headfree.
The fix is on the this Forum as well as RC Groups. With HK board you have to physically remove Mag chip & use an external Mag board (or GPS with built in Mag) mounted on a mast. I have mine on CF mast out front of quad well away from wiring or any other magnetic disturbance.

DorsetFlyer · Post by **DorsetFlyer** » Wed Jul 09, 2014 9:32 am

Thanks for your help both of you. I was pointed by majik01 to the MultiWii forum on www.multiwii.com/forum/viewtopic.php?f=8&t=3989 and it seems to contain all the help you need about GPS navigation, although it’s a lot to wade through. It appears that you do need ANGLE, BARO and MAG for all navigation options. I’m aware of the issue of magnetic interference from the power leads. It ruined my first attempt at RTH. I fixed it by arranging the power leads symmetrically and twisting each pair together, also raising the flight controller so it was 60 mm above the leads. I tested it with an ordinary compass sitting on the flight controller and got no deflection at hovering current. Also in flight the heading hold was not affected by changing the throttle. It does return to home correctly now. I now have the GPS on a mast 70 mm higher than the flight controller (130 mm above the wiring). I get 12 satellites in the field with the original MTK 3329 GPS but I don’t think the position accuracy is any better than about 3 metres. From the forum I see that the landing option just controls the rate of descent (typically 50 cm/s) until the ground is reached. Haven’t tried it yet.

brewski · Post by **brewski** » Wed Jul 09, 2014 1:15 pm

Hi Dorsetflyer,

Glad you got it sorted. EOS Bandi MW2.3 Navi b7 is probably the most advanced open source software available today. I suggest you buy a UBlox Neo 6m GPS (HK <$20) & you will achieve 1.5m horizontal accuracy or better. Forget Angle & use Horizon as it is far superior especially with GPS modes.
I havn't tried the Autoland or Fencing but these could definitely be useful if they work as no one has commented on these in Forum. I just leave Alt Hold on & decrease throttle for a controlled descent. Might gives these a go this weekend if wind dies down.

DorsetFlyer · Post by **DorsetFlyer** » Wed Jul 09, 2014 3:33 pm

Thanks brewski. I have tried a Ublox NEO-6M (in the same position and with #define NMEA and GPS_BAUD 38400) but it did not get any more satellites than with the MTK (one less typically). But perhaps the number of satellites isn’t the only thing that determines position accuracy. Everyone says the Ublox is superior. Is it something about the way it processes the raw data? I'll give it another try anyway. It's very windy here too.

brewski · Post by **brewski** » Wed Jul 09, 2014 9:16 pm

I use #define UBlox and Baud 38400. Give this a try with your Ublox 6M. Which revision do you have mine is Rev3 with EEProm + rechargeable lithium battery.
Going by spec sheet this Rev has better processing/filter & sensitivity.

DorsetFlyer · Post by **DorsetFlyer** » Thu Jul 10, 2014 8:50 am

Those are the settings I used. I’ve no idea which revision I have, just the one that Hobby King sells. On the chip it says NEO-6M-0-001. Hobby King say it has an EEProm but the battery is just a MS621FE button cell. I’m new to multi rotors although I’ve been flying RC planes for donkeys’ years. Started with a KK2.1 board but soon moved to MultiWii Pro for the extra features. I’ve been using MultiWii 2.2 and had GPS Hold and RTH working reasonably but probably in need of tuning. I’ve now installed MultiWii 2.3_navi_b5_baro_fix but I haven’t had a chance to try it yet as it has been so windy. I think I had best try it with the existing hardware for a start, make sure BARO and MAG work properly, then try the GPS features. After that I’ll swap for the Ublox and see if there is an improvement.

brewski · Post by **brewski** » Thu Jul 10, 2014 9:44 am

DorsetFlyer wrote:Those are the settings I used. I’ve no idea which revision I have, just the one that Hobby King sells. On the chip it says NEO-6M-0-001. Hobby King say it has an EEProm but the battery is just a MS621FE button cell. I’m new to multi rotors although I’ve been flying RC planes for donkeys’ years. Started with a KK2.1 board but soon moved to MultiWii Pro for the extra features. I’ve been using MultiWii 2.2 and had GPS Hold and RTH working reasonably but probably in need of tuning. I’ve now installed MultiWii 2.3_navi_b5_baro_fix but I haven’t had a chance to try it yet as it has been so windy. I think I had best try it with the existing hardware for a start, make sure BARO and MAG work properly, then try the GPS features. After that I’ll swap for the Ublox and see if there is an improvement.

Hi DorsetFlyer,
The first thing you should do is download MW2.3 Navi b7 from EOS Bandi site. Just Google it. Download the firmware for FC as well as the WinGui that works with it.
This guy is now the leading edge in MW GPS together with Ezio & his Android EZ-GUI. Features & stability are now up with the commercial offerings in my opinion.
Check out my post regarding running default PIDs & doing hands off Pos Hold on an X525 frame viewtopic.php?f=8&t=5296&start=100
Quad will hold position until battery exhausted even with wind gusts.
You say these are the GPS settings you used but you used NMEA & should be UBlox defined in Arduino using raw data for best performance. You might have to use UCentre to configure. Your UBlox is V1 (001) so maybe spend $20 for a V3. Try UBlox setting first & see how it performs.
Have you done all the antivibration measures?
There are critical (set 6050 to 42Hz LPF- can up later if reqd) , buy quality APC composite or CF props with matching prop adapters, balance props & motors.
Once vibration is under control you will have a quad that is reliable & delivers consistent performance. A good test is to handhold & run throttle thru the range observing graphs on either MultiwiiConfig , WinGui or EZ-GUI if you have Bluetooth module installed.
I assume that you have also set up TX so that all controls go from 1000-2000 & 1500 using trim on all functions inc AUX.

Cheers..B

DorsetFlyer · Post by **DorsetFlyer** » Thu Jul 10, 2014 2:45 pm

Thanks for all that advice brewski. I’ve installed b7 and the GUI and set the PIDs to default values and recalibrated the accelerometer and magnetometer . Sorry about the mix up with NMEA and UBLOX. I was using #define UBLOX with the Ublox. My frame is a Hobby King X580 and I’m using EMAX MT2216-850 kV motors with the 10 x 4.5 props that come with the motors. I’ve balanced these with a Dubro Tru-Spin balancer (“blades and hub“). They seem to run pretty smooth but I haven’t measured anything. I hadn’t set a low pass filter but I have now set 42Hz. I have a Bluetooth module on order so I’ll see if I can get that sorted. The Tx controls are set up as you say. Still waiting for calmer conditions for flight tests. Will let you know how I get on. Cheers mate.

brewski · Post by **brewski** » Thu Jul 10, 2014 9:25 pm

If the props & prop adapters are similar to the 10 x 4.5 ones that came with my X525 kit then no matter what you do there will be bad vibration as adapters don't centre props accurately. The nylon props were so thin that you could see them bending up as throttle increased!
Back to your original question yes with RTH you should set Mag on in AUX with this function. I have Baro on as well with RTH & Pos Hold & Mission.
I haven't tried LAND here (don't think Ive even seen it) but it would use GPS coordinates. LAND is controlled descent using Gyro & Baro to best of my knowledge.
Prior to using ext Mag when I enabled Mag it was highly unpredictable which way it would decide to go. Which flight controller & ESCs did you go with?

Cheers..b

DorsetFlyer · Post by **DorsetFlyer** » Fri Jul 11, 2014 9:51 pm

I tried out b7 today. It was rather too windy for my liking but the quad flew quite well on just HORIZON. I had 8 satellites so I tried HORIZON+BARO+MAG+POSHOLD and it held horizontal position within about 2m for a few seconds then shot upwards at some speed and I had to abort. Tried a few more times with the same result. I wondered if the problem may be that the Altitude P gain was too high at the default value of 6.8. I see that others use 1.6 to 1.9 so I tried it with 2.0 and got the same result.

So I tried just HORIZON+BARO and it did exactly the same, shooting up fast.
I also tried HORIZON+MAG and that held the heading well.

Looking at the MultiWii sketch, which I can’t pretend to follow very well, it appears to me that in IMU.cpp a complimentary filter is used to merge the vertical velocities from the barometer (0.015) and the integrated accelerometer (0.985). So does that mean that the accelerometer was mainly responsible for the wild behaviour ?

Regarding the props, they are not all that bad. They come with the motors and are designed to fit them precisely with a “slot and key” arrangement so they should be well centred. Hobby King sell the motor and prop combination as NT2213-936KV MultiStar. You can bend the props but they don‘t appear to flex in flight and they are quite quiet. I’ll see about getting some carbon props though.

I’m still using the MTK because I would like see how it performs so as to have a direct comparison with the UBLOX. But it looks as if BARO, not GPS is my the main problem. Be glad of any advice.

Cheers, DF

DorsetFlyer · Post by **DorsetFlyer** » Sat Jul 12, 2014 7:56 am

Had a flight this morning with HORIZON + MAG + POSHOLD. Without BARO there was no vertical flyaway. Horizontal position took a little while to stabilise, wandering around several metres, but then settled to within about a metre. Occasionally it would be pushed further off by a gust but it would sit there with me just using the throttle. Next time I’ll try the UBLOX but I’m still stumped about what to do about the barometer.

brewski · Post by **brewski** » Sat Jul 12, 2014 8:28 am

Have a look at Baro values in MW Config. They should zero out when USB connected. I get a drift of approx. 1.5m + over 10minutes with stable atmospheric pressure. I believe this is due to sensor heating which is made worse by heat trapped by foam covering Baro module.
Lift quad up a metre & value should change by 1m+. The only way that quad would suddenly go skyward is if it thinks that that is where ground is i.e. a large negative output from Baro. If where you live is subject to sudden atmospheric change then you will just have to disconnect Lipo more often to zero Baro.
When you connect Bluetooth & run EZ-GUI you will see immediately if there is any offset on Baro & take corrective action. It would be nice if when you arm it zeros Baro as Megapirates does. We should put this up for Software Development.

stronnag · Post by **stronnag** » Sat Jul 12, 2014 9:13 am

In order to attempt to mitigate the effect on heat on the Baro, I've gotten into the habit of performing a stick recalibration of the baro immediately before arming (on the basis that the FC was powered up at least 30s previously, and some warming will have taken place).

brewski · Post by **brewski** » Sat Jul 12, 2014 8:35 pm

Hi Stronnag,

Which combination cals the Baro? I have only seen ACC & Mag in the stick charts.

stronnag · Post by **stronnag** » Sat Jul 12, 2014 9:15 pm

I'm convinced that I read somewhere on multiwii.com (like http://www.multiwii.com/forum/viewtopic.php?f=18&t=4905) that the baro is recalibrated on the stick 'Calibrate Acro Gyro' sequence (and perversely not by the MSP Calibrate Acro Gyro command, otherwise I'd have added the function to mwptools). Also confirmed by inspection of the code https://code.google.com/p/multiwii/source/browse/trunk/MultiWii_shared/MultiWii.cpp?spec=svn1648&r=1648#852.It also resets the GPS home position.

Another well hidden MW gem.

DorsetFlyer · Post by **DorsetFlyer** » Sun Jul 13, 2014 11:12 am

I’ve done a simulation on the GUI and everything works as it should. When USB was connected the altitude read zero and stayed there. After 5 minutes I armed and the altimeter stayed zero. After another 5 minutes I raised the quad 2m and altimeter read 2m. I set the throttle to 50% and switched from (ANGLE) to (ANGLE + BARO) and the four throttle commands did not change. In flight when I do that the quad shoots up fast so it must be receiving a command to increase throttle. So why does it happen in flight and not in the GUI simulation? All I can think of is that it’s something to do with the accelerometer, not the barometer, since the z-acceleration plays such a big part in holding the altitude. I my simulation the quad was at rest so there was no change in z-acceleration. It just stayed at 255. But in flight this would not be the case. I presume the firmware subtracts the z-acceleration from the calibration to get a value that can be integrated to obtain the vertical movement. I wonder if I’ve got it set up somehow so that it gets this wrong. The way it flies is as if it thinks it’s going down when it’s actually going up. But if I quickly raise or lower the quad the variometer does moved in the right direction.

I’m grateful for the advice on barometer drift, but I don’t think this is the problem here. I can see this is important in a mission where the height must be correct relative to the arming point. Suppose the barometer drifts 20m up after arming and the mission altitude is 25m then it would fly at only 5m. But when you switch to position hold if it was at 5m but thought it as at 25m that would not matter because it would just try to hold what it thought was 25m and this would actually be 5m, which is what you want.

So I remain completely stumped !

mike105105 · Post by **mike105105** » Sun Jul 13, 2014 3:52 pm

Are you sure your acc is callibrated and all options for sensor orientation are correct in the config? You say the z val is 255? Mine at rest is 512, could be the source of your issue.

Also a side note: I have barely any drift on my baro over the course of a battery pack. Sure it fluctuates up and down a bit, but not a huge amount. Even alt hold works fairly well even though I need to do some pid tuning on it.

Mike

DorsetFlyer · Post by **DorsetFlyer** » Sun Jul 13, 2014 7:48 pm

That’s very interesting Mike. Clutching at straws, it could be that if the accelerometer was only reading 0.5G it would appear to be falling and so increase the throttle. I calibrate the accelerometer in the GUI Flight Deck. I don’t know how else to do it. In the Sensor Graph tab the scale is +/- 300 so 255 seemed right. I did wonder if the wrong accelerometer was specified in config.h. I have #define FFIMUv2 for the MultiWii Pro, which should specify all the sensors correctly. For good measure I just tried adding #define BMA180 (which is supposed to be the accelerometer on this board) but that changed nothing. Is this the accelerometer you are using ? I don’t know what other configuration options are available. If you know anything else I should have set please let me know.

mike105105 · Post by **mike105105** » Sun Jul 13, 2014 9:37 pm

I have the witespy readtoflyquads pro mini and the ez3.0 black. Both use #define FREEIMUv043 // same as FREEIMUv04 with final MPU6050 (with the right ACC scale)

Mike

brewski · Post by **brewski** » Mon Jul 14, 2014 3:00 am

DorsetFlyer wrote:That’s very interesting Mike. Clutching at straws, it could be that if the accelerometer was only reading 0.5G it would appear to be falling and so increase the throttle. I calibrate the accelerometer in the GUI Flight Deck. I don’t know how else to do it. In the Sensor Graph tab the scale is +/- 300 so 255 seemed right. I did wonder if the wrong accelerometer was specified in config.h. I have #define FFIMUv2 for the MultiWii Pro, which should specify all the sensors correctly. For good measure I just tried adding #define BMA180 (which is supposed to be the accelerometer on this board) but that changed nothing. Is this the accelerometer you are using ? I don’t know what other configuration options are available. If you know anything else I should have set please let me know.

Don't use any of the boards. Just define all the sensors in the list following board selection.
If that doesn't work you may have a dodgy ACC IC. Which HK MW board do you have? If using BMA180 it must be an old one as all latest boards use the superior MPU6050 Gyro/ACC. Here are stick commands http://diydrones.com/profiles/blogs/mul ... for-mode-1
These seem to be good for V2.3 & I haven't seen anything more recent & there are some I've seen that are wrong.

DorsetFlyer · Post by **DorsetFlyer** » Mon Jul 14, 2014 6:06 pm

My board is the red one sold by Hobby King as “MultiWii PRO Flight Controller w/MTK GPS Module” and it’s exactly as shown, with four separate sensors. The accelerometer is definitely a BMA180. I bought it last May although the date on the BMA180 is late 2012 so the board may have been around for a while. I’ll try defining all the sensors, rather than the board. The only thing I can think of now is that the BMA180 may have been set to the wrong range but that seems unlikely. I think I’ll start a discussion on the Hobby King page for this board as there may be others using it who have experienced this problem. Meanwhile I’ll try out the UBLOX on position hold and RTH but without BARO. Cheers BF

DorsetFlyer · Post by **DorsetFlyer** » Tue Jul 15, 2014 10:20 am

Just wonder if I should try modifying the firmware so that only the barometer is used in altitude hold.

At the bottom of IMU.cpp in the section #if BARO, change the line vel = vel * 0.985f + baroVel * 0.015f; to just vel = baroVel;

Sounds like the Saucer's Apprentice but it looks harmless and it should show if the accelerometer is the cause of the run away.

brewski · Post by **brewski** » Tue Jul 15, 2014 1:04 pm

Hi Dorsetflyer,
Ditch the board & buy a Crius AIOP V2. Currently <$50 & has the latest MPU6050 6 axis Gyro/ACC, MHC5883 3 axis Mag & MS5611 -01BA3 High Precision Baro (100mm accuracy). I have been down this path starting with a Crius 2.5 clone & understand now why developers of the latest multicopter firmware do not want to try to have to compensate for the poor resolution of sensors & limited memory of these early designs..& we are only talking of a few years!

DorsetFlyer · Post by **DorsetFlyer** » Wed Jul 16, 2014 8:11 am

PROBLEM SOLVED. After advice from majik I disabled "Takeover BARO Mode" which is enabled by default in b7. There was no fly away and the altitude was held quite well. Hard to judge the actual height but it seemed to stay within a meter most of the time with occasional larger excursions before coming back. There was a gradual upwards drift with time which may have been due to atmospheric pressure rising. I also tried out the UBlox. It seemed to hold position better then the MTK.

brewski · Post by **brewski** » Wed Jul 16, 2014 8:52 am

From my understanding,Takeover Baro Mode is required for Navigation. This is how you can set waypoint heights & RTH uses it as well.
I have it on in Config.h & works well. It certainly doesn't fly up when Baro turned on. With RTH quad climbs to preset attitude before returning home & when I set a waypoint height to say 10 metres in Mission & flying at 5m it climbs to 10m on arriving at waypoint.

DorsetFlyer · Post by **DorsetFlyer** » Thu Jul 17, 2014 7:56 am

Oh dear, looks as if I’m not out of the wood yet. In my tests I disabled NAV_TAKEOVER_BARO and also IGNORE_THROTTLE. Looking at Bandi’s forum it appears that both of these take effect only in a mission or RTH. I only used two switches, one turning on just BARO and the other just GPS hold. They both worked correctly individually or together. I didn’t try RTH or Mission so it’s hard to see why it makes any difference whether or not NAV_TAKEOVER_BARO or IGNORE_THROTTLE were enabled.

MultiWii

GPS Navigation

GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation

Re: GPS Navigation