Need Help, MultiWii Pro Trying to get GPS Working.

[Packie]

Hello all,

I'm familiar with the Arduino code editing, and I have a drone that functions very well with a MultiiWii pro board. but now its time to move forward to GPS. I've fiddled with commenting and uncommenting code, but cant get any results. I'm using multiwii 2.3.

here are some pics, you can check my wires too.

[Kbev5709]

First off, why use 2.3 when 2.4 has all the GPS code functionality complete? GPS was not fully implemented in 2.3.
Second your RX wire on the GPS module is going to the RX pin on the FC. It is supposed to be RX to TX and TX to RX.
Third, the MTK 3329 GPS unit is only so so as far as accuracy is concerned. It runs NMEA instead of the better Ublox format.
I know because I have one of each. Your config.h GPS section needs set up and initialized then the NMEA statement needs to be uncommented. In the following first snippet of code I show you that you need to uncomment #define GPS_SERIAL 2 and uncomment #define INIT_MTK_GPS

Code: Select all

/**************************************************************************************/
  /***********************                  GPS                **************************/
  /**************************************************************************************/

    /* ENable this for using GPS simulator (NMEA only)*/
    //#define GPS_SIMULATOR

    /* GPS using a SERIAL port
       if enabled, define here the Arduino Serial port number and the UART speed
       note: only the RX PIN is used in case of NMEA mode, the GPS is not configured by multiwii
       in NMEA mode the GPS must be configured to output GGA and RMC NMEA sentences (which is generally the default conf for most GPS devices)
       at least 5Hz update rate. uncomment the first line to select the GPS serial port of the arduino */
       
   #define GPS_SERIAL 2         // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
                                   // must be 0 for PRO_MINI (ex GPS_PRO_MINI)
                                   // note: Now a GPS can share MSP on the same port. The only constrain is to not use it simultaneously, and use the same port speed.

    // avoid using 115200 baud because with 16MHz arduino the 115200 baudrate have more than 2% speed error (57600 have 0.8% error)
    #define GPS_BAUD   57600       // GPS_BAUD will override SERIALx_COM_SPEED for the selected port

   /* GPS protocol 
       NMEA  - Standard NMEA protocol GGA, GSA and RMC  sentences are needed
       UBLOX - U-Blox binary protocol, use the ublox config file (u-blox-config.ublox.txt) from the source tree 
       MTK_BINARY16 and MTK_BINARY19 - MTK3329 chipset based GPS with DIYDrones binary firmware (v1.6 or v1.9)
       With UBLOX and MTK_BINARY you don't have to use GPS_FILTERING in multiwii code !!! */

    
     //#define NMEA
    //#define UBLOX
    //#define MTK_BINARY16
    //#define MTK_BINARY19
    #define INIT_MTK_GPS        // initialize MTK GPS for using selected speed, 5Hz update rate and GGA & RMC sentence or binary settings

Upload the config.h with everything set like that.
In this next snippet, I have recommented the #define INIT_MTK_GPS and uncommented the # define NMEA

Code: Select all

  /***********************                  GPS                **************************/
  /**************************************************************************************/

    /* ENable this for using GPS simulator (NMEA only)*/
    //#define GPS_SIMULATOR

    /* GPS using a SERIAL port
       if enabled, define here the Arduino Serial port number and the UART speed
       note: only the RX PIN is used in case of NMEA mode, the GPS is not configured by multiwii
       in NMEA mode the GPS must be configured to output GGA and RMC NMEA sentences (which is generally the default conf for most GPS devices)
       at least 5Hz update rate. uncomment the first line to select the GPS serial port of the arduino */
       
   #define GPS_SERIAL 2         // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
                                   // must be 0 for PRO_MINI (ex GPS_PRO_MINI)
                                   // note: Now a GPS can share MSP on the same port. The only constrain is to not use it simultaneously, and use the same port speed.

    // avoid using 115200 baud because with 16MHz arduino the 115200 baudrate have more than 2% speed error (57600 have 0.8% error)
    #define GPS_BAUD   57600       // GPS_BAUD will override SERIALx_COM_SPEED for the selected port

   /* GPS protocol 
       NMEA  - Standard NMEA protocol GGA, GSA and RMC  sentences are needed
       UBLOX - U-Blox binary protocol, use the ublox config file (u-blox-config.ublox.txt) from the source tree 
       MTK_BINARY16 and MTK_BINARY19 - MTK3329 chipset based GPS with DIYDrones binary firmware (v1.6 or v1.9)
       With UBLOX and MTK_BINARY you don't have to use GPS_FILTERING in multiwii code !!! */

    
        #define NMEA
    //#define UBLOX
    //#define MTK_BINARY16
    //#define MTK_BINARY19
    //#define INIT_MTK_GPS        // initialize MTK GPS for using selected speed, 5Hz update rate and GGA & RMC sentence or binary settings

Now, upload the sketch like that.
Make sure your ACC is properly calibrated. Make sure your compass is properly calibrated.
If uploading the two different statements at separate times does not work, try uncommenting BOTH the #define NMEA and the #define INIT_MTK_GPS and uploading that.
If you stick with 2.3, use the first method. Mine always worked doing it that way when I had 2.3. With 2.4 try method two if method one doesn't seem to work. I have upgraded to 2.4 on this same combo but have not had the chance to see what works on my set up because basically, I'm always flying better boards now and that one just sits there.
One more thing. You must uncomment the "Enables the MSP_WP command set" , which is used by WinGUI for displaying and setting up navigation #define USE_MSP_WP

Even after all of that, sometimes your GPS just won't work. Some days just suck for GPS. Best to try it on a cloud free day away from EVERYTHING. Mine only works reliably on sunny days. Space weather can affect GPS. This link http://www.swpc.noaa.gov/products/planetary-k-index provides info related to the PLANETARY K index. Your best bet is to not use GPS when the K index is K = 4 and above. It also helps to have the correct magnetic declination http://geomag.org/models/igrfplus-declination.htmlentered into your config.h sketch FOR WHERE YOU WILL BE FLYING. With GPS, entering your home MD means the location where the quad is armed, not where you live. Entering the relevant MD using the confi.h sketch can be done, but every time you adjust your MD,you will need to recalibrate the ACC and mag due to the new upload. For this reason you are much better off using the Win GUI or the EZ GUI to make these changes with ease and no ACC recalibration, but, when it comes to mag calibration, it should be done before every GPS flight or mission. Speaking of magnetism, the GPS system can also be affected by geomagnetic storms caused by disturbances in the earth's magnetic field. You can also check that at the NOAA link provided.

One more tip. If you upgrade to 2.4 in order to make the Win GUI work with the newer version you need to open up he multiwii.h file and change the version number back to 230 from 240. #define VERSION 240 to #define VERSION 230

Also, looking at one of your pics I see a ground wire on every motor/ ESC pin set. ??? Why?? All you really need is the signal wires there (and one hot and one ground for power from one esc.) That looks like a recipe for a ground loop situation.

With that red HK board your altitude hold will be fairly stable within about three feet vertically with the PIDs set really well. The baro on that board sucks however, (I also own one of those HK red Mega boards) and if your PIDs are a mess it will hold like crap. That baro starts to change settings after a while and if you don't zero it when arming it could take off thinking it is - 45 feet and all kinds of other crap. Look at your GUI graph with the craft sitting still. That baro is acting like the quad is going up and down when it's really just sitting there. A simple throttle down and yaw left on the throttle stick will reset the gyro and temporarily set the baro to zero (before it starts going off on a tangent or whatever it is doing shortly after zeroing.)
REMEMBER RX to TX and TX to RX

[Packie]

Your advice is gold !

I will make an attempt shortly. but . . .

1) I thought I was avoiding a ground loop not causing one.

2) do I have to change the code when I drive a view miles away ? ( FOR WHERE YOU WILL BE FLYING. With GPS, entering your home MD means the location where the quad is armed, not where you live.) So I need to take my laptop to a hillside with me ?

none of your advice, which appears crucial, is found any ware else I could find. Even on RCGroups. of which I post. (Test Pilot Mafia, if you want to see my previous work using bi and tri copters.)
I'm really wanting the GPS for station keeping for academic competitions and science efforts.

My professors and I believe the barometer to be mostly useless.

[Kbev5709]

My professors and I believe the barometer to be mostly useless.

The baro is involved in getting at least NEAR the heights set forth in your mission plan. Apparently, your professors don't know enough about your baro. One big drawback to your setup is the lack of preparing the baro properly for use. The baro is SUPER SENSITIVE to propwash and sunlight. The correct way to prevent the wash and light is to cover the baro with some dark colored open cell foam. Until you do this, the baro WILL be useless.

Your advice is gold !

I will make an attempt shortly. but . . .

1) I thought I was avoiding a ground loop not causing one.

Will someone else please let him know that you don't need all those ground wires hooked up like that? Never mind, I got this. What you have there is the perfect setup for creating one. Think about this. Each of your ESCs are already grounded to the battery from their 11.1v in ground. The other +5v BEC out ground wire is only there to complete a v in circuit to power the FC. Since all of the ESCs are already grounded at the 11.1v side, doubling ground wires to the FC has the potential for creating loops, not eliminating them. This potential for problems would multiply if you were using a BEC off of one of the other ESCs to power another device that interacts with the FC. When I look at your wiring, you did things correctly on the RX side of the FC, with only one ground hooked to it from the FC but then created probably three ground loops on the ESC side by hooking up the extra ESC ground wires. Ground loops in the audio world are prevented by what is known as a star grounding system where all grounds are taken from a central "ground hub" for lack of an easier term to use, with only one ground to each device from that hub. You want a similar situation on your quads wiring. Adding ground wires to a device that is already grounded (your FC) allows that loop to form. Here is a (very) rough sketch of a good wiring schematic to avoid the creation of ground loops.

This next sketch shows the ground loops added (your wiring)

Using this graphic you can see there are multiple loops created between all of the ground wires and the only ground circuit that is not part of a loop is the RX and the battery of which each has only one ground. In fact, ALL of the rest of the ground circuit other than the RX and battery is part of multiple loops all interconnected through the FC and the ESCs.
Below is a pic of my ESC out pins with nothing but the four signal wires attached to the pins I only installed enough pins for the signals. Three of the ESC ground wires are removed and only one is used to power the FC (connected on another pin elsewhere, not even on the ESC pins) I promise that I only have the FC grounded once to one ESC. If I wanted I could cut all four ESC ground wires and power from a UBEC. Also visible is the open cell foam being used to cover my baro. These are the hook ups on one of my RTFQ mega boards. The four empty pins are waiting for my next sonar module coming in the mail in two days.

Next pic is my HK red board. Here there are two ground wires hooked up. Only one goes to an ESC (on pin D5.) The other one is completing the RX power circuit with the red +5v wire going to the RX from pin D7. On pins 9 and 10 are my sonar trigger and echo wires. The RX ground hookup is a continuation of the star ground with only one ground wire between the RX and the already grounded FC. If I ran another ground wire from my RX to the FC I would create a ground loop with that wire.

The baro on this board is sans the foam because it is entirely protected from propwash and light by a black protective cover shown in the following pic. I have also found that this cover instead of foam was enough to make this baro almost acceptable and seems to work better this way than with using the foam.

2) do I have to change the code when I drive a view miles away ?

Your GPS runs on a combination of satellite fixes from the GPS module and magnetic bearing readings from your mag and altitude readings from the baro. If the mag does not have the home location right, how can the GPS work properly? My home (where I live) MD changes after only a mile or two of travel away from it. If you do your flying across town it will be way off if you set it to where you live to start with. Not only that, the MD of any one location CHANGES OVER TIME. So, even if you always fly at the same location you will still need to update to the new MD every now and then.

So I need to take my laptop to a hillside with me ?

I mentioned in my advice that there are three ways to set your MD. Config.h (which requires re calibrating both the ACC and mag.) Win Gui which requires no ACC recalibration. EZ GUI, which is just like Win GUI but easier to carry. If you are stuck using Win GUI instead of EZ GUI, you can look up the MD of the location where you plan on flying on the link I provided, and set that number in before leaving to fly. Easy peasy. The EZ GUI can find your correct MD and enter it in for you with the push of a button on site. No matter what method you use, re-calibrating the mag is standard operating procedure for ANY quad. DJI requires a mag calibration before flying to prevent fly aways. Every other commercial quad that is GPS capable also comes with instructions on mag calibrating before any GPS controlled flight. Is Multiwii something special? NOT! (Note:) MD and calibration are two different things. If you use an EZ GUI you can calibrate the mag with no cable connected at the flight location. If you are stuck using the Win GUI just calibrate the mag before going to fly the mission after setting the correct MD. You can do all of that from home before leaving to fly. The secret to a good mag calibration is a complete circle of rotation in all three planes done away from metallic objects or highly mineralized soils.
PS. Flying GPS is not a set and forget kind of thing. To change parameters like the MD and others, if you are using GPS you should invest in a bluetooth and EZ GUI. Or, if you'd rather lug your laptop, get a 915Mhz set, At least that way you don't need the USB cable connected to make these changes.

none of your advice, which appears crucial, is found any ware else I could find. Even on RCGroups. of which I post. (Test Pilot Mafia, if you want to see my previous work using bi and tri copters.)
I'm really wanting the GPS for station keeping for academic competitions and science efforts.

Well, you will loose those competitions if you don't set things up properly and probably be the laughing stock if your quad flies away looking for a fraudulent home position. Also, you would stand a better chance of winning any competition if you went with a mega board with a better baro. The red HK Mega board is utilizing what is basically an obsolete baro, the BMP085. There are better boards out there not using this obsolete baro but instead using the much improved MS561101BA. Since mw only supports those two baro's for GPS you should be using the best one available to minimize altitude hold issues that the obsolete baro has.
You are the one who came here asking for help with GPS. I can't help that you are not finding the info I am providing elsewhere. It is out there, mostly in forums like this, gleaned through trial and error and reading up on it by people like me and assembled by your's truly in this one spot just for you. GPS flight is a whole other animal that will bite you in the ass if not done correctly, totally unlike flight under standard remote control.

Finally I'm sure you've probably heard the term GIGA. Garbage in, garbage out. The MWFC can not think for itself. Especially during GPS flights, it is crucial the information that the FC uses to go where you think it should go needs to be correct. Neglect these simple rules and I can guarantee a malfunctioning GPS. The more thought and planning you put in to a GPS flight, the better your chances of success. Lots of people fall down right after drawing up their mission in the GUI by forgetting to actually upload the mission to the FC. I can provide a link to a video of one of my GPS missions showing that I have actually done it, not just talk about it, if you'd like.

[Kbev5709]

Your advice is gold !

OK, then why did you just disappear without letting me know if all this new advice is worth wasting my time for you.