[solved] Waypoint navigation using i2c GPS module?

[matt_prox]

Hi all,

I'm fairly new to multiwii and I have a question that may be quite silly. I have a promini-based setup (MW version 2.3), and I have recently added a GPS to my rig. I have a question about the i2c navigation modules, necessary with promini setups due to serial port constraints. I used EOSBandi's navigation firmware on the board (https://code.google.com/p/i2c-gps-nav/), and configured the necessary sections in my MW config.h file (i.e. uncommenting "#define I2C_GPS" and setting my magnetic declination). I manage to get GPS hold and RTH functions working correctly (they still need a little tuning), but I cannot seem to enable waypoint navigation. In the EZGui - which I use to configure my settings - the mission planner section is disabled when the app is connected. It also disables the Nav settings (and others relating to GPS) on the config page. I think this is because it auto-detects what kind of GPS navigation is in operation, and I assume it's because the i2c GPS system only offers minimal GPS functions. Please could someone confirm this for me? I can't seem to find a definitive answer for this online.

What is confusing me most is that the I2C-GPS-NAV code documentation specifically says it has functionality for 15 waypoints. Is there a way that I can get these to work without having to buy a mega-based FC? Is there something I am missing?

Thanks in advance.

[edsimmons3]

Uncomment #define USE_MSP_WP then the EZgui etc will be able to communicate mission info to the flight controller.

[matt_prox]

I'm afraid that didn't work for me. Mission planner is still disabled in EZgui.

[edsimmons3]

Do you have sufficient ram on your controller for the setup you have chosen? Please could you share your config.h file? Perhaps via pastebin or similar to prevent filling up the forum thread...

Thanks,
Ed

[edsimmons3]

By the way, have you tried the later verison of multiwii, I think I started out with 2.3 and then chose the release that was current on github a couple of months back. Sorry to be vague but I had much more success with the newer code and the I2C board. I found initially that I was greedy with the options in my config and used up the ram with some really interesting consequences - thankfully with that figured out it's flying really well now.

[matt_prox]

Here is my config.h file:
http://pastebin.com/eGdkZRE0

I have been hesitant to move over to the newer MW version, but maybe it's time.

When I compile my code in Arduino, the results are as follows:

Sketch uses 26,858 bytes (83%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,342 bytes (65%) of dynamic memory, leaving 706 bytes for local variables. Maximum is 2,048 bytes.

I assume this is what you mean when you're asking if I have enough ram? I think it's fine, no?

[Kbev5709]

Did you pay for the EZ GUI unlocker??

[matt_prox]

I did, yes.

[matt_prox]

OK. Following Ed's advice I upgraded to the new version of MW, and it seems to have solved the problem. Thanks Ed!

I have made a lot of hacks to the code in 2.3, and I will need to begin implementing these in the new version (which will be tight, given that compiling MW2.4 gives me low memory warnings). Hopefully it is possible.

[edsimmons3]

Hi Matt,

You may find some success in using a tool like meld (graphical diff & merge tool) to merge your changes from 2.3. Are these changes likely to help others? If so could we start collecting useful things for possible future inclusion? I have a few local versions with edits too...

Ed

[Kbev5709]

I have made a lot of hacks to the code in 2.3, and I will need to begin implementing these in the new version (which will be tight, given that compiling MW2.4 gives me low memory warnings). Hopefully it is possible.

If you don't fly an airplane or a collective pitch heli, you can re comment everything in config.h under "Airplane, "Common for Heli & Airplane", and "Heli". These settings are enabled by default and if you fly a quad, are not utilized. Believe me, they don't need uncommented for your quad to fly. I always re-comment these settings with no ill effects on flying.
Also, if you don't use an onboard LCD, you can re-comment everything that relates to LCD settings under the headings "Type of LCD", "Display Settings", "LCD configuration menu", and if you don't plan on using FPV telemetry, the settings under "LCD telemetry", can be re-commented as well. If you don't use any servo's on your quad (I don't) you can re-comment ANYTHING that relates to servo settings. You will be amazed at the amount of virtual memory opened up after doing this. I guarantee your hacks and just about any other cool code mods you make will fit with no problems after doing this. If, at some point in time you want to include one or more of these items, just go upload the unmodified config.h sketch you saved as a separate file for future use (if you don't you should) and start over. Hopefully you save all of your modified config.h files with their own names as well.

[matt_prox]

Ed,

I don't think my mods would be particularly useful to others. They largely revolve around the custom radio module (which I am actually moving away from because it wreaks havoc on the cycle time). One exception to this (also in the alt-hold code you and I were discussing in my other thread) is in multiwii.cpp (I'm now using MW v2.4). In the section of code handling throttle stick commands to adjust the altitude setpoint, I noticed that when the stick is returned to the midpoint, the AltHold variable (ie setpoint) is reset to the current estimated altitude - I indicated where in the snippet below:

Code: Select all

//IF Throttle not ignored then allow change altitude with the stick....
        if ( (abs(rcCommand[THROTTLE]-initialThrottleHold)>ALT_HOLD_THROTTLE_NEUTRAL_ZONE) && !f.THROTTLE_IGNORED) {
          // Slowly increase/decrease AltHold proportional to stick movement ( +100 throttle gives ~ +50 cm in 1 second with cycle time about 3-4ms)
          AltHoldCorr+= rcCommand[THROTTLE] - initialThrottleHold;
          if(abs(AltHoldCorr) > 512) {
            AltHold += AltHoldCorr/512;
            AltHoldCorr %= 512;
          }
          isAltHoldChanged = 1;
        } else if (isAltHoldChanged) {
          AltHold = alt.EstAlt; //   <==========================  AltHold variable reset to current altitude
          isAltHoldChanged = 0;
        }
        rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
      }
      #endif //BARO

I noticed that my althold was performing *okay-ish* when I didn't touch the stick, and when I adjusted it was relatively smooth. But as soon as I centered the throttle stick at the end of the adjustment, the copter would climb of fall abruptly. I decided to comment this line to see if it would help, and yes, it is much better. With my sonar, I can now get my copter to hover within about ~10cm up to 2m off of hard ground (ie. paving). And the PID tuning still isn't perfect. I haven't tested over grass yet, so I will report back soon.

kbev - thanks for the suggestions! I will definitely be giving them a try soon. I don't need anything to do with servos, LCD's, buzzers, etc, so this is useful advice! Much appreciated.

Matt