GPS integration

[PatrikE]

You must have GPS fix to be able to select Gps nav modes!
It's within this if-statement.

Code: Select all

if (f.GPS_FIX && GPS_numSat >= 5 ) {
        if (rcOptions[BOXGPSHOME]) {
          if (!f.GPS_HOME_MODE)  {
            f.GPS_HOME_MODE = 1;
            GPS_set_next_wp(&GPS_home[LAT],&GPS_home[LON]);
            nav_mode    = NAV_MODE_WP;
          }
        } else {
          f.GPS_HOME_MODE = 0;
        }
.....
}

So get a Fix and it will be fixed

[nhadrian]

Hi,

I would like to set up a 328p multiwii with a serial GPS.
For his GPS (Locosys LS20031 which is a great GPS!!!) the deffault setup is 38400, etc, when onboard super capacity becomes empty...
So I'd like to reconfigure on startup, before looking for GPS sentences in setup code.
Till now in i2c GPS code I used this code for configuring NMEA output:

Code: Select all

  Serial.begin(38400);
  delay (200);
  Serial.println("$PMTK220,100*2F\r\n");
  delay (50);
  Serial.println("$PMTK314,0,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0*27\r\n");
  delay (50);
  Serial.println("$PMTK251,115200*1F\r\n");
  delay (50);
  Serial.end();

But now I get a compile error. Could somebody help and write these sentences with the MWI serial orders?
Thanks in advance!!!

BR
Adrian

[dramida]

Interesting i2c GPS board for multiwii i found here: http://www.multiwiicopter.com/products/ ... iwiicopter

[Y.Mita]

Mr.EOSBandi, or someone please help me !

I bought GPS antenna, AP.035A.07.0054A Taoglas active gps antenna, 5 parts. And also bought u-Blox NEO-6M module of CRIUS CN-06 which has small patch antenna.
First, I download u-center version 7 and connect CN-06 through FTDI USB Serial adaptor, no ploblem.
Next, I disconnect small patch antenna and connect AP.035A.07.0054A, try to connect u-center, can't communicate, FTDI LEDs no blink.
Third, try all 5 parts of AP.035A, two of them seems work, but other 3 can't communicate.
Fourth, connect small patch antenna again, good comunication.
Fifth, connect again third try good two AP.035A, but this time, can't communicate.

May be between third try, I connect small patch antenna and try upload your u-blox-config.nmea.txt to module.

I check the antenna activate voltage at antenna connector, 3.31V, seems ok.
If I remove both, AP.035A and small patch antenna, communication ok.
I try twice all 5 parts but no communication. I try twice all 5 parts with just before upload u-blox-config.nmea.txt but no communication.
I try another serial communication monitor on PC, when I connect small patch antenna or without antenna, first communication start with "$GPTXT,01,01,02,ANTSTATUS=OK*3B", I think NEO-6M checking antenna status and feedback "ANTSTATUS=OK". But with AP.035A no message come back.
I think config file has "CFG-ANT - 06 13 04 00 1B 00 8B A9" which part doing configuration of antenna connection, but default config which download from module and u-blox-config.nmea.txt seems just same at here.

One more thing I had try, the NEO-6M module seems very sensitive against power glitchs, and I try to add 1uF capacitor to input and output side of 3.3V regulator but no difference.

Please give me some advice !

-*-*-*-*-*-*-*-*- Edited on 14/Aug/2012 -*-*-*-*-*-*-*-
Solved by myself. Reported howto on some later reply.

[shikra]

Interesting i2c GPS board for multiwii i found here: http://www.multiwiicopter.com/products/ ... iwiicopter

I look on website for this every day - excellent. One on the way.

[BrokenRotor]

Help!

I am trying to get the I2C GPS to function when the flight controller has a BMA180 Accel sensor in use. I have tried on a MiniWii and a Quadrino board and it locks the I2C bus on both.
It does work on my MiniWii with MPU6050 sensor. There is some conflict going on here.

[CrazyJ]

Just installed the new Paris GPS module on my Scarab FPV Reconn. The first tests were yesterday, and I was pleasantly surprised at how well the Position Hold and Return to Home worked! The open source MultiWii code has come a long way! THANK YOU GUYS!

Going to use the GPS Position Hold for my Scarab Y-Siix so I can park the copter in the sky and focus on shooting stills! Love it!

Here's a quick video of the GPS in action, and some fun from yesterday.

http://youtu.be/LoscFW8Fjtc

[Y.Mita]

Mr.EOSBandi, or someone please help me !

I bought GPS antenna, AP.035A.07.0054A Taoglas active gps antenna, 5 parts. And also bought u-Blox NEO-6M module of CRIUS CN-06 which has small patch antenna.
First, I download u-center version 7 and connect CN-06 through FTDI USB Serial adaptor, no ploblem.
Next, I disconnect small patch antenna and connect AP.035A.07.0054A, try to connect u-center, can't communicate, FTDI LEDs no blink.
Third, try all 5 parts of AP.035A, two of them seems work, but other 3 can't communicate.
Fourth, connect small patch antenna again, good comunication.
Fifth, connect again third try good two AP.035A, but this time, can't communicate.

May be between third try, I connect small patch antenna and try upload your u-blox-config.nmea.txt to module.

I check the antenna activate voltage at antenna connector, 3.31V, seems ok.
If I remove both, AP.035A and small patch antenna, communication ok.
I try twice all 5 parts but no communication. I try twice all 5 parts with just before upload u-blox-config.nmea.txt but no communication.
I try another serial communication monitor on PC, when I connect small patch antenna or without antenna, first communication start with "$GPTXT,01,01,02,ANTSTATUS=OK*3B", I think NEO-6M checking antenna status and feedback "ANTSTATUS=OK". But with AP.035A no message come back.
I think config file has "CFG-ANT - 06 13 04 00 1B 00 8B A9" which part doing configuration of antenna connection, but default config which download from module and u-blox-config.nmea.txt seems just same at here.

One more thing I had try, the NEO-6M module seems very sensitive against power glitchs, and I try to add 1uF capacitor to input and output side of 3.3V regulator but no difference.

Please give me some advice !

I solved by myself !

First, connect NEO-6M module 13 and 14 pin, it change the setting of module, then all 5 parts AP.035A connect with no ploblem.
Next, upload u-blox-config.nmea.txt to module, no connection.
3rd, short super capacity on module with 75ohm register about 1 minutes for forget settings. Good connection came back. Save this time settings of module by u-center's "Tools","GPS Configuration...", "GPS>>File".
4th, modify downloaded config file to change baudrate 38400 to 115200, update rate 1000msec to 100msec, with reading "u-blox6 ReceiverDescriptionProtocolSpec_(GPS.G6-SW-10018).pdf" which downloaded from u-Blox web site. Modify 2nd line "CFG-PRT" and "CFG-RATE".
5th, upload modified config file, check all 5 parts AP.035A connect with no ploblem at 100msec update with 115200baud.
6th, compare u-blox-config.nmea.txt with my original config file, copy "CFG-MSG" lines from u-blox-config.nmea.txt file to my original config file.
7th, upload modified config file and check the connection, no ploblem !
8th, download u-blox-config.ublox.txt from http://i2c-gps-nav.googlecode.com/svn/trunk/I2C_GPS_NAV/ and modify same as 6th step.
9th, upload modified config file and check the connection, no ploblem ! But be ware, before 3D fix, u-center seems no update on screen.
10th, download trunk shared r1014from http://code.google.com/p/multiwii/source/detail?r=1014, modify MultiWii_2_1 and activate "#define UBLOX", and test on MultiWiiGUI, its works !!!

Maybe, some hardware difference of my module cause this problem. Some part of config.txt file is conflict against my module.

I wrote this reply for somebodys help. Thank you !
Next I try backup to serial EEPROM.

EDITED 14/Aug/2012

add modified config file

[wilco1967]

I'm experimenting with the FrSky telemetry software which is a great new addition !
http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929

The MultiWii is sending a lot of data, including the GPS coördinates, through the Frsky datalink to my 9x transmitter with open9x firmware.
It also sends the GPS_distanceToHome from Multiwii, which shows up as T2 on the 9X

The open9X also calculates the distance by itself, based on the GPS coordinates received. By pressing menu on the Tx, it resets to zero. The readings received both on the 9X and on the GUI match perfectly with the actual position. So far ok.

When flying, I noticed the Dist from open9X differs from T1 (distance from multiwii) by a factor of approx 1.6. The open9X being the higher number.
I went out to what open9X said was 300 meters (very very far for a tricopter in LOS). But multiwii was reporting 180 meters.
Later I checked on google earth from my own estimate how far i was out (over some trees far away as a reference), and as far as I can tell, it seems the open9X reading is the correct one.
Could there be an error in the MultiWii GPS distance calculation, or is the 9X software to blame ?

I had a look in the multiwii GPS code, but the calculations are way over my head.... there are some factors which I don't understand.

Without a live telemetry link, I would never have noticed, as RTH and POS hold work just fine even if the calculated distance would not be correct.

<EDIT>
repeated my experiments today with an additional GPS data logger on board.....
Turned out:
- MultiWii distance reading (T2) is correct
- Open9X internal calculation (Dist) is wrong.... (indication is about 1.6x too far)....
- my own visual distance estimation was even worse.....

So it's an open9X issue.....

Also noticed, the open9x distance is supposed to be the real 3D distance, while the MultiWii distance is distance over ground.
So if your flying straight overhead at 50 meters elevation, the open9X would (or should) show around 50 meters, while multiwii will report 0 distance.

Oh, one more thing....
The T2 used to display MultiWii distance seems limited at 365 meters.... anything higher, and it starts from zero again...

[jy0933]

can i get some help about i2c_nav board +cn06+328 board

here's the steps i have gone thru

1. solder 13&14 pin to enable 38400 >> connect cn06 to ftdi tested with u-center. got gps fix and able to locate

2. download fw "I2c gps nav v2.1 rc2 (Wire lib issue fixed)"

1)add following code under setup() <Change the initialisation sequence>

Code: Select all

uint8_t i;
  delay(3000);      //lets some time to GPS module to init
  Serial.begin(38400);
  delay(1000);
  
  //set GPS dynamic platform to "pedestrian" seems to be best for copter
  PROGMEM prog_uchar conf2[]={0xB5, 0x62, 0x06, 0x24, 0x24, 0x00, 0xFF, 0xFF, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x10, 0x27, 0x00, 0x00, 0x05, 0x00, 0xFA, 0x00, 0xFA, 0x00, 0x64, 0x00, 0x2C, 0x01, 0x00, 0x3C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x4F, 0x82};
  Serial.write (conf2,sizeof(conf2));                                                                                  
  delay(300);

  //disable all default NMEA messages
  PROGMEM prog_uchar conf3[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF0, 0x05, 0x00, 0xFF, 0x19};
  Serial.write (conf3,sizeof(conf3));
  delay(100);
  PROGMEM prog_uchar conf5[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF0, 0x03, 0x00, 0xFD, 0x15};
  Serial.write (conf5,sizeof(conf5));
  delay(100);
  PROGMEM prog_uchar conf6[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF0, 0x01, 0x00, 0xFB, 0x11};
  Serial.write (conf6,sizeof(conf6));
  delay(100);
  PROGMEM prog_uchar conf7[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF0, 0x00, 0x00, 0xFA, 0x0F};
  Serial.write (conf7,sizeof(conf7));
  delay(100);
  PROGMEM prog_uchar conf8[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF0, 0x02, 0x00, 0xFC, 0x13};
  Serial.write (conf8,sizeof(conf8));
  delay(100);
  PROGMEM prog_uchar conf9[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0xF0, 0x04, 0x00, 0xFE, 0x17};      
  Serial.write (conf9,sizeof(conf9));
  delay(100);


  //enable UBX messages POSLLH, SOL, STATUS and VELNED as is in EOSBandi's config file
  PROGMEM prog_uchar conf10[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0x01, 0x02, 0x01, 0x0E, 0x47};
  Serial.write (conf10,sizeof(conf10));
  delay(100);
    PROGMEM prog_uchar conf11[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0x01, 0x03, 0x01, 0x0F, 0x49};
  Serial.write (conf11,sizeof(conf11));
  delay(100);
  PROGMEM prog_uchar conf12[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0x01, 0x06, 0x01, 0x12, 0x4F};
  Serial.write (conf12,sizeof(conf12));
  delay(100);
  PROGMEM prog_uchar conf13[]={0xB5, 0x62, 0x06, 0x01, 0x03, 0x00, 0x01, 0x12, 0x01, 0x1E, 0x67};
  Serial.write (conf13,sizeof(conf13));
  delay(100);

  //set rate to 5Hz
  PROGMEM prog_uchar conf15[]={0xB5, 0x62, 0x06, 0x08, 0x06, 0x00, 0xC8, 0x00, 0x01, 0x00, 0x01, 0x00, 0xDE, 0x6A};    
  Serial.write (conf15,sizeof(conf15));


  //Init i2c_dataset

2 )set define ublox in config and change the baud rate to 38400
3 )replace the twi.c/.h file in wires
4 ) upload to i2c_nav board with arduino 1.0 +ftdi

3. define i2c_gps in mwc2.1 and comment gps_serial options

upload

(literally is this process http://www.rcgroups.com/forums/showpost ... ostcount=9)


i probably have done something wrong in i2c_nav board part.. since gps is tested working in step1 @baud 38400... and literally mw2.1 file uncomment/comment gps options cant be wrong

can someone verify what is going wrong here? the battery on gps chip is dropped( the clip totally broken off the board when i tried to take the battery off)..

also, i found with mega 2560, it is possible to use default baud rate 9600 and make the change to 115.2k for 5hz refresh rate(http://www.rcgroups.com/forums/showpost ... stcount=23).. is it possible to do this for i2c_nav board?

thanks

[Dave66]

I have never been so confused, have read over 50 pages of posts and still have no clear idea how to get my CRIUS CN-06 GPS receiver and I2C Nav module GPS to work with my Crius SE board running 2.1. Solder pins, don't solder pins, add to the sketch and don't, plug it in as per RC Timer, do not, use the Arduino 1.0.1, use the old one, move files to the lib, do not, so much conflicting info. The nav board has no FTDI pins so do I program it through the SE board? I know about changing configh. Usually this forum has clear answers but with so many posts I am lost. I'll keep reading, I know the answer is out there. I guess I have the older SE board with no extra I2C for the GPS, it just has the 4 I2C pins next to the FTDI, RC Timer pic shows the nav board plugged into these 4 pins.

[mrsylvestre]

I have never been so confused, have read over 50 pages of posts and still have no clear idea how to get my CRIUS CN-06 GPS receiver and I2C Nav module GPS to work with my Crius SE board running 2.1. Solder pins, don't solder pins, add to the sketch and don't (...)

Known feeling here. I think that I am beginning to sort it out myself, but information seems indeed to be provided in puzzle form On the other hand, it would not be fair to blame anyone; after all what did I contribute so far ? (first post here).

As I see it, there are different hurdles to pass for a successful connection of CN-06 GPS. It helps to address these stepwise:

1. Connecting things : as GPS modules use serial communications and many (non-Mega) flight control boards/units do not have an extra serial port available one must use a Nav module in-between, that will access the GPS through the serial lines (TX/RX) and will transfer the data to the main flight controller unit (FCU) through the I2C bus (SDA/SCL). As a bonus, because the Nav module is basically a small arduino (similar or same microcontroller as the main FCU), it can also take care of the navigation code, saving resources (memory, cpu cycles) on the FCU.

2. Consequently, the Nav module has its own code, developed by EOSBandi (thanks) on the basis of Arducopter navigation routines (thanks again). The Nav module code for Multiwii is to be found here : http://code.google.com/p/i2c-gps-nav/ (it does not hurt to read the documentation there either). Some version of this code is normally preloaded on the Nav board, but it certainly does not hurt to install the latest version. The Nav board from RCTimer comes ready for soldering a 6-pins FTDI header. It is not clear to me whether the board is 5V tolerant, so I pass the TX and RX lines through a sparkfun logic level converter on a breadboard and I power the Nav board with 3.3V (do not connect the FTDI +5V). I also insert a 100 nF capacitor between the DTR pin of the FTDI cable (or basic FTDI breakout board) and the DTR pin of the Nav board. The CTS line is not used and not connected. Last but not least, when uploading EOSBandi's code to the Nav board using the Arduino IDE (1.0.1, standard libraries), I set Tools/Boards/ to "Arduino Nano w/ ATmega328" (because my FCU is home-made using an ATmega with the UNO bootloader, it took me some time to realise why the IDE would not upload the code on the seemingly similar Nav board, doh !).

3. An additional difficulty associated with CN-06 and other Ublox-based chinese GPS modules is that the battery backup of the GPS settings is basically non-functional (battery drains fast). You may configure your GPS with u-center (UBlox's software) by connecting directly your (serial) GPS to your PC (using a USB-RS232 TTL interface such as a FTDI cable or FTDI breakout board) and using the config file provided by EOSBandi to set binary mode, 115200 bauds, 10 Hz etc. but chances are that when all is connected in your multicopter, the GPS has reverted to 9600 bauds, NMEA, 1 Hz. So, the serial GPS initialisation code, which is to be found on the Nav board (and not on the FCU unless you have a direct serial connection between the GPS and a FCU with more than one serial interface) has to be adapted to reconfigure the GPS each time. Some advocate soldering pins 13 and 14 of the Ublox module together so that the GPS powers on in a predictable mode (38400 bauds). EOSBandi's solution is to solder a small EEPROM onto the GPS module so that it can store its configuration in a non-volatile memory. Another solution is provided by EOSBandi here http://www.multiwii.com/forum/viewtopic.php?f=8&t=2166#p20097 (see zip file, ublox_init() in GPS.ino file : auto-discovering the initial baud rate of the GPS before configuring it) but this is for Mega boards (direct serial link between FCU and GPS) and has not yet, to my knowledge, been ported to I2C-gps-nav. Once ported, the latter would be, IMHO, the easiest option (no delicate EEPROM soldering required and conceptually equivalent to the "shorting pin 13 & 14" approach) for most people.

4. Finally, when using a Nav module, the FCU has to be configured accordingly so it can communicate with it. Basically, one should uncomment the #define I2C_GPS line in the GPS section of the Multiwii config.h file. It probably does not hurt to check in the forums, readme, that the multiwii and i2c-gps-nav codes are in sync though, so that the FCU and the Nav board can understand each other.

Hope this helps someone (to the gurus here, feel free to correct me if I missed something, criticism is welcome)

[dramida]

I'm experimenting with the FrSky telemetry software which is a great new addition !
http://www.multiwii.com/forum/viewtopic.php?f=7&t=1929

The MultiWii is sending a lot of data, including the GPS coördinates, through the Frsky datalink to my 9x transmitter with open9x firmware.
It also sends the GPS_distanceToHome from Multiwii, which shows up as T2 on the 9X

The open9X also calculates the distance by itself, based on the GPS coordinates received. By pressing menu on the Tx, it resets to zero. The readings received both on the 9X and on the GUI match perfectly with the actual position. So far ok.

When flying, I noticed the Dist from open9X differs from T1 (distance from multiwii) by a factor of approx 1.6. The open9X being the higher number.
I went out to what open9X said was 300 meters (very very far for a tricopter in LOS). But multiwii was reporting 180 meters.
Later I checked on google earth from my own estimate how far i was out (over some trees far away as a reference), and as far as I can tell, it seems the open9X reading is the correct one.
Could there be an error in the MultiWii GPS distance calculation, or is the 9X software to blame ?

I had a look in the multiwii GPS code, but the calculations are way over my head.... there are some factors which I don't understand.

Without a live telemetry link, I would never have noticed, as RTH and POS hold work just fine even if the calculated distance would not be correct.

<EDIT>
repeated my experiments today with an additional GPS data logger on board.....
Turned out:
- MultiWii distance reading (T2) is correct
- Open9X internal calculation (Dist) is wrong.... (indication is about 1.6x too far)....
- my own visual distance estimation was even worse.....

So it's an open9X issue.....

Also noticed, the open9x distance is supposed to be the real 3D distance, while the MultiWii distance is distance over ground.
So if your flying straight overhead at 50 meters elevation, the open9X would (or should) show around 50 meters, while multiwii will report 0 distance.

Oh, one more thing....
The T2 used to display MultiWii distance seems limited at 365 meters.... anything higher, and it starts from zero again...

Open LRS would be more suitable for bi-directional data link over RC link. Would be very helpful to autonomous GPS path guided flight.Details on forum here viewtopic.php?f=7&t=1929&p=21128#p21128

[scanman]

Dave 66 youre not the only one puzzling with those RCTimer GPS units ! mrsylvestre thanks for that info. thats the best info yet! i followed your steps. (by the way, Dave 66, i couldnt get the EOSBandi code to compile in Arduino, you have to move files around into different folders - but theres no clear instructions on this either! but eventually it comes right, so don't give up there!) .

Thanks to all those who have put some much effort in so far, i am a bit stuck and would like some assistance, i cant wait to get this working!

I now have my GPS occasionally giving data to the IC2 Nav (i have found by disconnecting and re-joining the green wire to the GPS after it has powered up it starts communicating with the IC2 NAV - go-figure?). My IC2 NAV is giving the "3 short flashes on its red (not blue) LED" which i presume means its got a good fix?

So mrsylvestre , please continue with your tutorial, because i plug the IC2 Nav into the MultiWii SE, (are the 4 pins next to the FTDI pins the correct place to plug it? I tried the soldering suggestion from "DR Tom" but it didnt work.)
I also flashed to MultiWii 2.1 with and uncommented #define I2C_GPS line .

But when i connect to the MultiWii using the GUI (I have tried both Win Gui and the MultiWiiConf2.1), it says i have a gps in the small rectangles showing which features are activaed (like baro, mag, acc etc), but it doesnt show me and GPS fix or co-ordinates. I have even setup the RTH and Pos Hold on my Radio switch and that comes through.
But its like the multiwii is not talking to the IC2Nav. do i need to include additional files in the multiwii arduino?

[Neo360]

Hi Guys,

Help me please, because i have one doubt!!

I have the I2C GPS by Drotek with Drotek CTRL Flight RED edition, i dont understand why the GUI show me this coordinate (See the picture), i think that was not correct because my real coordinate was LAT 45.302542° LON 7.898999° we have any idea about that or is correct?

[Neo360]

Guys how can i put the new GPS code on the onboard atmega in my I2C GPS?

[wareck]

For neo360, toggle your nema database to 0 (WGS1984 "international") and mayme your gps is in 5hz
So parser lag and give bad coordonates

I put a post in drotek forum about tunning the GPS of drotek.
If you don't understand french, I can translate for you.

[Neo360]

For neo360, toggle your nema database to 0 (WGS1984 "international") and mayme your gps is in 5hz
So parser lag and give bad coordonates

I put a post in drotek forum about tunning the GPS of drotek.
If you don't understand french, I can translate for you.

when i put nema database to 0?

please link your post in drotek forum thanks

[mrsylvestre]

Hi,

(...) i plug the IC2 Nav into the MultiWii SE, are the 4 pins next to the FTDI pins the correct place to plug it? (...)

I do not own a MultiWii SE (I am building my own FCU around an ATmega 328 and separate components on breakout boards) but from the pictures I can see of that board, the pins next to the FTDI header are "classical" serial, not I2C pins. If the pins you connected your I2C nav board to are labeled TX/RX/VCC/GND and not something like SDA/SCL/VCC/GND, you are doing it wrong. You have to find a pin header labeled "I2C" or pins labeled "SDA" and "SCL" on the Multiwii SE. Note that these pins might also be labeled "A4" and "A5" (analog 4 & 5 I/O ports on the ATmega 328, which are used for SDA/SCL). It is difficult to tell you exactly where those pins are on your board as googling for "Crius Multiwii SE" returns pictures of different boards (versions) with slightly different layouts.

[scanman]

CRIUS MULTIWII SE with rctimer GPS board and i2C nav board (see attached photo)
: i found out why not getting GPS readings in the gui,
Firstly: if your I2C nav module is not giving 3 fast blinking lights then don't even bother connecting it to the multiwii- sort it out first (see tip below to initialise the gps on every boot).

Now, in the multiwii 2.1, config.h activate the below settings and flash the multiwii:
#define I2C_SPEED 400000L
#define I2C_GPS

Now, if you have got the 3 fast blinking lights on your IC2 Nav module (indicating a fix), but you are not seeing any data in the multiwii gui, then look to see if you are getting lots of I2C errors in the GUI (like 200 per second!), you should have 0 (none) I2C errors.

If you are getting I2C errors,This means that your IC2 nav module is not connected correctly to your multiwii. You CANNOT simply plug it in to the "TTL" port next to the "FTDI" port, you HAVE to solder the SDA and SCL wires onto the CRIUS Multiwii. Heres the problem: DR Tom's diagram is WRONG for CRIUS Multi Wii SE, you need to use Jonit's photograph here:

download/file.php?id=1348&mode=view
viewtopic.php?f=8&t=1569&start=100


Solder the 2 wires , provide power from anywhere and as soon as you get the three fast blinking lights on the ic2 nav module you will see the GPS fix coming through to the gui!
If you are not getting the three fast blinking lights on your ic2 nav module then you need to reflash your ic2 nav module but include the setup code to set the board rate to 115200 :

delay(4000); //lets some time to GPS module to init
//try all com speeds up to 115200 and set to 115 200
Serial.begin(9600);
delay(800);
Serial.println("$PMTK251,115200*1F"); //speed 115200

[p25o1]

managed to test the gps PosHold and RTH.

my set up was using:
quadrino rev 1e mwc
flytron i2c gps.

multiwii 2.1 was used, and for my setup i can say it was "out of the box" experience!!!
i was prepared for a long tuning session , but i was amazed that every thing just worked.

hats off to the developers and all that made such an amazing work.

https://vimeo.com/47706969

[BrokenRotor]

Is anyone using the I2C GPS unit along with a BMA180 accel ?
Every time I add in the I2C GPS it locks up the I2C bus and there is no sensor display in the GUI.

[gompf-2]

Yes, I use a setup with promini and ITG3200/BMA180 (old freeimu) together with a HMC5883L/BMP085 addon board from ebay(HK). I piggy packed a second promini with I2C-Nav (r33 iirc) on the main FC (via SDA/SCL/GND/VCC) and use a MTK3339 trough on half of sparkfun level converter/additional 3.3V PSU.

multiwii 2.1 was used, and for my setup i can say it was "out of the box" experience!!!

Same for me!
After the battle to get the 10Hz firmware for/on the MTK and some first problems with a new model setup (V-Tail/mixing/PIDs/different motors and ESCs on front and tail) I can lift it to 3m, kick in Mag+Baro+posHold and go for catching a beer in the kitchen
Poshold is within 1.5x1.5m² on calm days, hight is pumping within 1.5~2M but I didn´t change anything on the PIDs now. For me it´s enough.
Only thing I noticed is, that the MTK/my wiring is quite sensitive to ripple on VCC and the position of Jeti Dublex RX. I tried to shield the MTK on the desk with a metal "fischermens friend" box but the signal drop in the sat monitor SW was chicken-feed. When the Jeti RX came into the setup it sometimes lasted for ever until 3D fix (without backup battery), with redefined position it´s nearly always under 60s without EPO data.

Why do you ask so definitly about the BMA180. Does GPS work if you undefine BMA180? Whats your BMA180 adress?

[Ausi1972]

I have bought from RCTimer the Crius MultiWii SE V1.0 (with I2C header) + I2C GPS nav module + Crius CN-06 UBlox GPS module

I have shorted pins 13 & 14 on the CN-06, connected it via FTDI head to USB and connected in U-Centre, this shows the GPS position and works fine.
Plugged together on FC but not getting the red led flashing 3 fast, just the 1 sec slow flashing so no GPS fix.

Can someone with this combination let me know what else has to be done to get this working please.

I have loaded V2.1 code onto the FC and enable:
#define I2C_SPEED 400000L
#define CRIUS_SE
#define GPS_BAUD 38400
#define I2C_GPS
#define GPS_LED_INDICATOR

[pm1]

I have bought from RCTimer the Crius MultiWii SE V1.0 (with I2C header) + I2C GPS nav module + Crius CN-06 UBlox GPS module

I have shorted pins 13 & 14 on the CN-06, connected it via FTDI head to USB and connected in U-Centre, this shows the GPS position and works fine.
Plugged together on FC but not getting the red led flashing 3 fast, just the 1 sec slow flashing so no GPS fix.

Can someone with this combination let me know what else has to be done to get this working please.

You have to change the SW on the i2c board (the i2c board is configured for 115200 baud):
http://www.multiwii.com/forum/viewtopic.php?f=8&t=2124&start=10

[CokeViper]

Is it already possible to just define a gps coordinate and let the quadrocopter fly to this position?

[pm1]

I am looking to optimize PH for me. If I switch to PH, (*not* RTH), the reaction is totally different, if the *nav* PIDs are zero or not, when I use the sticks to bring the copter by force away from the correct position (to test the reaction). I seem to be blind somehow, but I don't find the piece of code, where there is any dependency to the nav PIDs. Can someone give me a pointer to this?

Best regards
Peter

[pm1]

Is it already possible to just define a gps coordinate and let the quadrocopter fly to this position?

No, the code has already definitions for 16 WPs, but there is no code to switch to them...

[Ausi1972]

I have bought from RCTimer the Crius MultiWii SE V1.0 (with I2C header) + I2C GPS nav module + Crius CN-06 UBlox GPS module

I have shorted pins 13 & 14 on the CN-06, connected it via FTDI head to USB and connected in U-Centre, this shows the GPS position and works fine.
Plugged together on FC but not getting the red led flashing 3 fast, just the 1 sec slow flashing so no GPS fix.

Can someone with this combination let me know what else has to be done to get this working please.

You have to change the SW on the i2c board (the i2c board is configured for 115200 baud):
http://www.multiwii.com/forum/viewtopic.php?f=8&t=2124&start=10

Is the file to download?
I2c gps nav v2.1 rc2 (Wire lib issue fixed) from here: http://code.google.com/p/i2c-gps-nav/downloads/list

Then does the patch go in? I2C_GPS_NAV.ino

I see another Patch: http://code.google.com/p/i2c-gps-nav/issues/detail?id=4
Which is best?

[scanman]

ublox CN-06 connected to I2C nav module
is anyone else finding that the UBLOX GPS needs to be powered off an on again to start sending its data to the I2C module?
I have tried mofiying EOSBandi's code to get the IC2 Nav module to send a warmboot to the ublox (3 seconds after sending all the baud rate and nav settings), but it didnt make a difference. powering off the quad and powering it up again gets me a fix within 10 seconds.

Do you think we need an external power switch to power off the ublox ? Or is it some serial port problem?

[pm1]

Is the file to download?
I2c gps nav v2.1 rc2 (Wire lib issue fixed) from here: http://code.google.com/p/i2c-gps-nav/downloads/list

Yes

Then does the patch go in? I2C_GPS_NAV.ino

Yes, function setup

I see another Patch: http://code.google.com/p/i2c-gps-nav/issues/detail?id=4
Which is best?

My one is better -> configures to 115200 baud with ublox binary protocol and 10 Hz. If xou try the other one, be aware, taht you have to start with 38400 baud

[pm1]

ublox CN-06 connected to I2C nav module
is anyone else finding that the UBLOX GPS needs to be powered off an on again to start sending its data to the I2C module?
I have tried mofiying EOSBandi's code to get the IC2 Nav module to send a warmboot to the ublox (3 seconds after sending all the baud rate and nav settings), but it didnt make a difference. powering off the quad and powering it up again gets me a fix within 10 seconds.

Do you think we need an external power switch to power off the ublox ? Or is it some serial port problem?

Some people are claiming, you need some solder between pin 13+14, otherwise the module does not start correctly every time. I can say for sure, I do not have *any* problem (I have the short between pin13+14). My GPS starts correctly every time.

[pm1]

I guess I have the older SE board with no extra I2C for the GPS, it just has the 4 I2C pins next to the FTDI, RC Timer pic shows the nav board plugged into these 4 pins.

If this is an "older" board (50x50mm), it has *no* I2C pins. Next to the FTDI is another serial connection (for bluetooth for example).

[dramida]

I found that after a period of inactivity, rctimer ublox 6M gps hangs up at first power up. I also have the pin 13 and 14 grounded (soldered to 15). It sends an error string related to low backup battery. To work arround this issue, first i plug the power to mwc for about 10 seconds, unplug and immediately re-plug power again. It works for me every time.

[scanman]

Patch: http://code.google.com/p/i2c-gps-nav/issues/detail?id=4
My one is better -> configures to 115200 baud with ublox binary protocol and 10 Hz.

pm1, thanks for that, i used yours it works every time, please can you also put in the commands to re-boot the ublox 10 seconds after power up to try and get rid of "dramida" and my ublox hanging problem.
Alternatively, can you send a hi to a digital pin on the ATMEL and i will solder on a transistor to cut the power.
Alternatively, If its complaining about low battery, i'm thinking of removing the battery completely, maybe it wont complain anymore.

[pm1]

mmmmh, I wonder, why the ublox refuses any commands after sending that low-battery issue. I think, it will then refuse the command to reset the ublox too.
You only have and advantage of the battery, if you have the GPS almanach stored to have a fast warm boot. So I would suggest to try to remove the battery, otherwise you only have an additional delay of 10s. I never had this low battery problem, so something must be different.

[dramida]

Removing the battery results in GPS hanging all the time at boot.

[bill516]

Is ths normal behaviour for a newly connected GPS module, what I mean it is hooked up to the Arduino and working but no PID tuning or arming of motors, oh and I'm in the house.

[pm1]

gps1.jpg

Is ths normal behaviour for a newly connected GPS module, what I mean it is hooked up to the Arduino and working but no PID tuning or arming of motors, oh and I'm in the house.

It is normal, if you are in a house. The satellite signal are reflected by other houses or walls. Therefore the calculation may be off for 50 m or more..

[pm1]

Hi,
I changed the GPS code a bit for poshold:

static void GPS_calc_poshold(int x_error, int y_error)
{
...
x_target_speed = pi_poshold_lon.get_p(x_error); // calculate desired speed from lon error
x_target_speed = constrain(x_target_speed,-100,100);
x_rate_error = x_target_speed - x_actual_speed; // calc the speed error

p = pid_poshold_rate_lon.get_p(x_rate_error);
i = pid_poshold_rate_lon.get_i(x_rate_error + x_error, dTnav);
d = pid_poshold_rate_lon.get_d(x_error, dTnav);
d = constrain(d, -2000, 2000);
output = p + i + d;
nav_lon = constrain(output, -NAV_BANK_MAX, NAV_BANK_MAX);
...

The PIDs:


The line in red was added to limit the possible velocity while adjusting within the radius of a waypoint. Then I made D term to 0 because of the following reason:
For some unknown reason the D term is dependent of x_error and not x_rate_error . Therefore it is proporational to the velocity. In fact, we have now 2 P terms.

This change works brilliant for my 10 Hz GPS. The position hold is now solid as a rock without visible movements short term (of course the position moves due to GPS error, but not within seconds, in minutes).

[Yellowboy63]

Hi,
I changed the GPS code a bit for poshold:

static void GPS_calc_poshold(int x_error, int y_error)
{
...
x_target_speed = pi_poshold_lon.get_p(x_error); // calculate desired speed from lon error
x_target_speed = constrain(x_target_speed,-100,100);
x_rate_error = x_target_speed - x_actual_speed; // calc the speed error

p = pid_poshold_rate_lon.get_p(x_rate_error);
i = pid_poshold_rate_lon.get_i(x_rate_error + x_error, dTnav);
d = pid_poshold_rate_lon.get_d(x_error, dTnav);
d = constrain(d, -2000, 2000);

So where exactly do I make this change? Am I adding this code to the config.h or gps in WMC, or am I adding this in my I2c-gps nav code?

[pm1]

So where exactly do I make this change? Am I adding this code to the config.h or gps in WMC, or am I adding this in my I2c-gps nav code?

If you have an i2c gps board, there in I2C_GPS_NAV.ino. You only have to add the line in red.

[penpen77]

Seems strange you constrain only x speed target value and not both x and y. What's the reason ?

[flyman777]

Hi,

I had drastic drifts about 200 meters with my i2cGPS+LLC from Drotek.
This was absolute unflyable.
So after reading pm1 post, I tried his solution:

x_target_speed = constrain(x_target_speed,-100,100);
...

I leaved my board in static position about 30 minutes, the result is bluffy !
Only drifts about 15 meters in a 1/2 hour.

Naturally, I upgraded also the y_target_speed : y_target_speed = constrain(y_target_speed,-100,100);

So I'm waiting for calm weather for testing that outside.

Cheers
Claude

[flyman777]

Here my settings for the GPS board
Claude

[pm1]

Seems strange you constrain only x speed target value and not both x and y. What's the reason ?

Sorry, I forgot to mention, that I did the same for y .

[pm1]

Hi,

I had drastic drifts about 200 meters with my i2cGPS+LLC from Drotek.
This was absolute unflyable.
So after reading pm1 post, I tried his solution:

x_target_speed = constrain(x_target_speed,-100,100);
...

I leaved my board in static position about 30 minutes, the result is bluffy !
Only drifts about 15 meters in a 1/2 hour.

Naturally, I upgraded also the y_target_speed : y_target_speed = constrain(y_target_speed,-100,100);

So I'm waiting for calm weather for testing that outside.

Cheers
Claude

It's a bit impossible, that that has something to to with my changes. This only works in the air while holding position...

[flyman777]

Hi

@pm1: perhaps your right
I tried the Poshold with genuine i2c_gps_nav rc2 from EOS but my copter speeded up after a few seconds forwards and backwards and begin to tilt so I must switch off the gps for avoiding a crash. In static conditions, there was also a huge drift over 50-100 meters in about few minutes.
That behaviour didn't after the modification.
As I said , I didn't for this time try this mod in flying conditions, but the static graph in wingui is very encouraging.

Regards
Claude

[pm1]

I tried the Poshold with genuine i2c_gps_nav rc2 from EOS but my copter speeded up after a few seconds forwards and backwards and begin to tilt so I must switch off the gps for avoiding a crash.

That's exactly the situation I met. Therefore I had a deeper look into the code. The lines I did put in limit the possible speed in PH. It didn't show the result I expected. The I saw, that D term was not related to change of speed, but to change of distance. I made D term to zero, then it worked as expected by me.

If you are using i2c GPS, make additionally following modification on the fc (GPS.ino):

void GPS_NewData() {
uint8_t axis;
#if defined(I2C_GPS)
static uint8_t GPS_pids_initialized;
static uint8_t _i2c_gps_status;

//Do not use i2c_writereg, since writing a register does not work if an i2c_stop command is issued at the end
...
...
if (_i2c_gps_status & I2C_GPS_STATUS_NEW_DATA) { //Check about new data
if (GPS_update) { GPS_update = 0;} else { GPS_update = 1;} //Fancy flash on GUI
if (!GPS_pids_initialized) {
GPS_set_pids();
GPS_pids_initialized = 1;
}


Without this modification, you may always use the default pids hard coded in the i2c board. Then try the pids from my post as a start.

[flyman777]

OK pm1, thanks for the reply.
I will try your mod in FC as soon as the weather will become better, it's stormy yet here.
Regards
Claude