GPS integration

EOSBandi · Post by **EOSBandi** » Sun Jan 01, 2012 6:35 pm

jevermeister wrote:Hi all,
I agree, that it is very annoying to place the mag way above the copter (think of crashing) How do the guys at mikrokopter do it??

Take a look at the mikrokopter power distribution board and esc placements. It's away from the fc, same level but sideways...

Alexinparis · Post by **Alexinparis** » Sun Jan 01, 2012 6:37 pm

jevermeister wrote:I agree, that it is very annoying to place the mag way above the copter (think of crashing) How do the guys at mikrokopter do it??

Nils

Hi,
You can read over the web that mikrokopter users encounter the same problem. It's not due to the software or mag sensor.
It's a frame + power distribution + ESCs disposition problem.
Needless to say also that a buzzer near the FC is forbidden.

EOSBandi · Post by **EOSBandi** » Sun Jan 01, 2012 7:03 pm

I posted pics at viewtopic.php?f=9&t=1002&p=7276#p7276 of my tricopter...

dramida · Post by **dramida** » Sun Jan 01, 2012 7:03 pm

Congrats EOSBandi for the GPS RTH explicit test and debuging the code. I prefer to set home position when arming motors.

1 Please share your ALT and VEL PID's of your copter, it works amazingly well on holding altitude.

2 Do you trust the Acc value on Z axis?

3 What is the weight in flight of your copter?

4 How are vibration of giro/ accelerometer dampened for trusting Z axis?

BIG THANK in advance!
/Mihai

EOSBandi · Post by **EOSBandi** » Sun Jan 01, 2012 7:14 pm

Hi, I put answers to the topic about my Tri, mentioned above...

jevermeister · Post by **jevermeister** » Sun Jan 01, 2012 7:16 pm

Hm,
I twisted the cables from LIPO->ESC but I think it made no difference.
The wires ESC->Motor are about 25 cm and are inside of the arms, should I twist them too?

Nils

dynai · Post by **dynai** » Thu Jan 05, 2012 9:39 pm

Hi everyone,

first thanks for you hard work on the gps integration

i have a small request / problem

my DIYdrones MTK 3329 GPS is fixed to 38400 Baud and 1 Hz.... at least after a firmware update it outputs NMEA but the mini-gps tool tells me that i cant save changed settings (10 Hz 115200 baud) to flash...
on the other hand i can change this via terminal and it will stay until i power down my gps then everything is set back to default.

as a work-around i inserted the following code lines into the dev20111220

in the setup()

Code: Select all

  #if defined(GPS)  
    SerialOpen(GPS_SERIAL,GPS_DEFAULT_BAUD);    
    delay(10);
    GPSprintChar("$PMTK251,115200*1F\r\n");      //baudrate 115200
    delay(10);
    SerialOpen(GPS_SERIAL,GPS_BAUD);
    //delay(10);
    //GPSprintChar("$PGCMD,16,1,1,1,1,1*6B\r\n");  //set to NMEA
    delay(10);
    GPSprintChar("$PMTK220,100*2F\r\n");         //Will set the GPS to 10hz (or updates every 100 milliseconds)
    delay(10);
  #endif

at the end of the GPS.h

Code: Select all

void GPSprintChar(const char *s) {
  while (*s) SerialWrite(GPS_SERIAL, *s++);
}

and last into config.h

Code: Select all

#define GPS
#define GPS_SERIAL 2 // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
#define GPS_BAUD   115200
//#define GPS_BAUD   9600
#define GPS_DEFAULT_BAUD 38400 // default speed of the gps after power-up

so now every time the arduino is reseted the speeds and refreshrates are set to 10hz 115200 baud.

maybee this helps others as well, but if there is a better solution for this problem... pretty please

kind regards

Christoph

nhadrian · Post by **nhadrian** » Sat Jan 07, 2012 9:24 am

Hi everyone,

I found Michael Maslik's work about i2c GPS integration.
I'm planning to use a separated arduino nano for GPS serial reading and then sending via i2c to main board. I found a useful code by Ben_der on fpv-community.de for this.
Unortunatelly, Michael's integration is only for the 1.8p1 code, so I'd need some help of integrating the gps i2c code into 1.9 or dev20111220. I tried but I still can't clearly understand the whole code for this.

I'm sure others would be interrested with Arduino mini boards!!!

Best regards
Adrian

ps.: I attached the files.

Bledi · Post by **Bledi** » Sat Jan 07, 2012 11:47 am

Excellent it's a good idea

nhadrian · Post by **nhadrian** » Sun Jan 08, 2012 8:06 am

Hi all,

Finally, we rewrote the whole i2c GPS code.

Here is how it works. There is a 10 byte block definied with GPS_fix, numsat, distToHome, dirToHome, distToPos, dirToPos. So it calculates the direction, distance from home position (home) and stored position (Pos, for position hold). On request from master it stores the home or pos coordinates.

But I need your help in integration into the multiwii dev20111220!!!

My idea is:

MWI sends request for home point store after AUX1_low position. Multiwii sends request for POS point after activating position hold, so generally it stores the position on every position hold activation.
GPS hold and RTH should work on the same way, only the point is the difference. I think both equation should include the condition Fix=1, so when fix is OK, the multicopter flies towards to the desired point, when fix is gone, it stops in autolevel and when fix returns, it continues the moving.

I made a first try to modify the multiwii code. It doesn't work at all, but shows my idea. I used wire library, it definitelly neds to be replaced with proper i2c code.

BR
Adrian

LenzGr · Post by **LenzGr** » Tue Jan 10, 2012 1:32 am

Very cool to see GPS support getting integrated into the MultiWii code base. I've just recently switched controllers in my quad (I was using an ArduIMU v2 flat with custom code before), first test flights look good! I'm thinking about adding a GPS module to my copter at some point. I recently purchased a SparkFun GPS Micro-Mini module - do you think it would be usable? The default baud rate is 4800bps (changeable), the update rate is 1Hz (fixed). It's probably too slow for accurately holding a position, but might be sufficient for simple return to home or waypoint navigation. What do you guys think?

nhadrian · Post by **nhadrian** » Tue Jan 10, 2012 7:26 am

I suggest this GPS receiver:
http://www.flytron.com/osd-headtrackers ... odule.html

cheap and works great, I already have three of them woth different OSDs.

So, could anybody help me integrate my i2c GPS idea into the multiwii code? I think many of us with arduino mini would be really interrested in because then they only need a receiver, an Arduino mini and some soldering... But I'm not as qualified programmer as this issue needs...

jevermeister · Post by **jevermeister** » Tue Jan 10, 2012 7:52 am

Do you guys think, that there is a possibility to send gps data to a sending device? IO currently use a hombing ebacon to find my copter if it is lost, I already lsot two copters and only found one.
I am very careful not to loose it right now an I use a GPS GSM beacon but it is very heavy. Maybe we can use the nmea data and a small gsm module/or another kind of tx/rx combi to send the data.

My current beacon sends the data via sms (text message) when I call it after I lost the model.

Nils

ps.: can someone give me a short overlook of the theory of position hold via GPS?

I want to try developing something into that direction for understanding it.

nhadrian · Post by **nhadrian** » Wed Jan 11, 2012 3:47 pm

Hi guys.

After many hours of trying I had to realize that I should spend on lot of time to learn the programming basics properly, and figure out how multiwii code works. In lack of this it is almost impossible to do finalize my idea. But also I think it would be 2-3 afternoon job for somebody who knows what to do, since even I had some success on i2c communication establisment between the two arduino panels (with some test modifications, I was able to turn on the LED of the secondary Arduino with an aux input of multiwii.....

), but I can't figure out how to read the data and import into the MW code properly, etc...

So here is the clear and final idea again, I wish somebody could do the programming job for the MWI community who uses Mini based boards...:

// legends: PRA - primary arduino with MW code, SEA - secondary arduino with GPS connected

- SEA and PRA are connected with i2c, SEA and GPS with serial
- SEA establishes serial communication with the gps and reads out GGA strings on 115200 baud (I have to use VTG too for my OSD because of airspeed, so the program should be able to read the GGA only from two type of sentences)
- SEA translates latitude, longitude, fix, satellite number values, and update these values continously if fix is OK (else leaves them unchanged)
- SEA learns home and hold coordinates and continously calculates the distance and direction between current position and home and hold coordinates (at initialization both should be the first fix, then changing regarding the followings)
- if PRA would read SEA, distance and direction to home; fix and numsat are available in 10 bytes from SEA. (fix 1byte, numsat 1 byte, distToHome 2 bytes, dirToHome 2 bytes, distToHold 2 bytes, dirToHold 2 bytes)
- I plan to put home position learning onto a spring-switch on my radio, so when spring state of switch is active in PRA, PRA asks SEA to learn the home position coordinates, but it could be linked to arming too.
- every time hold mode becomes active in PRA, it sends an order to SEA for learning the current position as hold. It is important to send the command only once per hold activation.
- PRA only uses the datas from SEA for positioning (distance, direction) to reduce PRA code size
- I think, for safety in both hold and home functions there should be a condition for fix=1, so when there is GPS fix, they are working, when fix takes away, hold and home deactivates, and copter stays in autolevel, and once fix returns, copter continues the way if option is still enabled.
- I think for both home and hold functions the same algorythm should used for first time since the task is almost the same, stay as close to the desired point as possible).
- as an addition, SEA led should light up when fix is OK (only some lines in code but great help for checking if GGA sentences are translated properly)

That's all folks!

BR
Adrian

ps.: sorry for my english, I'm not using the language daily...

, and many thanks to EOSBandi for the basic idea...

Bledi · Post by **Bledi** » Wed Jan 11, 2012 4:17 pm

I love what you try to do it's an exellent idea. I can't help you ... but I follow this post

LenzGr · Post by **LenzGr** » Thu Jan 12, 2012 11:58 am

nhadrian wrote:So here is the clear and final idea again, I wish somebody could do the programming job for the MWI community who uses Mini based boards...

I'm not sure I'm getting the point on this. Why would you want to go with two Mini Boards, when you can get a Mega at roughly the same price, which provides the additional required serial port, and more?

EOSBandi · Post by **EOSBandi** » Thu Jan 12, 2012 12:04 pm

Simple, was majority of the boards available on the market are atmega384 based. So with an I2c gps you can use these boards for gps based functions. Plus, offloading computing and memory intensive tasks to a secondary processor frees up resources on the main proc, and helps keeping the cycle time low. That allows you to use higher precision calculations for navigation. (there are many tasks with gps handling. Parsing gps sentences, calculating bearing and distance, check cross track error, even calculating dead reconing with an 1Hz cheap gps....)

jevermeister · Post by **jevermeister** » Thu Jan 12, 2012 12:27 pm

Sorry for changing the topic, but what about Position Hold?

Isnt' Position Hold easier to develop than Retun Home?

I do not have the balls to try return home right now I would like tos tart with position hold.

Nils

nhadrian · Post by **nhadrian** » Thu Jan 12, 2012 12:33 pm

Following the idea with secondary processor and i2c, position hold and RTH is the same situation, only coordinates are changing, because once you reached the home point you should stay around there. So the excersise is the same but only when on hold mode (I meant position hold) you starts from the destination point. Thats easier but the main calculation is the same, maybe some PID tuning is neccessary for better holding.

BTW, for examle Mikrokopter is using dedicated processor for navigation calculations on a different panel too...

PatrikE · Post by **PatrikE** » Thu Jan 12, 2012 1:06 pm

Position hold and RTH.
The differense should be that.

Position hold should just keep the position in the sky.

RTH should start to climb to a safe heiht ex 50m over home pos to avoid colliding with trees and houses.
After reaching home it should hold positon an decend to a preset altitude over home.ex 5-10m
After some time attempt to land. and shut down engines.
Or just do Position hold

/Patrik

nhadrian · Post by **nhadrian** » Thu Jan 12, 2012 2:03 pm

My oppinion is that first should be more than enough if it would do the same as EOSBandi presented some posts earlier.
If RTH is activated, it starts to move towards to home position. When it reaches the home position it stays around there.
For position hold, it also has to be able to go back to position once a big wind ghust or so sweeps away by some meters. And then, the goal is the same...

Till now, alt hold works well alone without GPS, so when alt.hold activated via the same AUX as the GPS, then it will hold the altitude and the position too.

Then, later, of course, some more advanced features like flying stright between two points, altitude variation and others could be added... they are all really difficult programming jobs.

I think the first step is to establish connection between two arduino mini boards and GPS and have a basic function for RTH/HOLD.

EOSBandi · Post by **EOSBandi** » Thu Jan 12, 2012 2:50 pm

Will have some time during weekend, I hope i'll be able to finish the code alongside with the inflight data logging.

rbirdie001 · Post by **rbirdie001** » Thu Jan 12, 2012 8:40 pm

Hi all!
I agree with following EOSBandi and nhadrian idea!
Most multiwii users have ATMega 328 based boards - sometime nice complete boards with all sensors on one board (like me - I have very nice "crius" board) and don't want to exchange it for Mega board, but would like to play with GPS.
This I2C secondary arduino would be an easy, cheap and very smart solution allowing further growing in the future.
Secondary arduino can be any cheap promini or whatever you have in the drawer, it can work at any serial speed and refresh rate with any GPS you have, even configure the GPS and do all calculations to offload the primary arduino and provide only results to it. It can even "sniff" NMEA output from the OSD GPS on the given speed and use it. In future it can log flight data to micro SD card, keep there preprogrammed waypoints and provide to primary arduino just requested distance, heading (later also height, speed, etc.) for any kind of tasks you can imagine. It will have enough calculation time, memory and also necessary serial port for that tasks.
Unfortunately my programming skills are too bad for that so I can't write it. I can only support it with the electronic part, ideas, testing etc. I'd like to encourage someone to write the code.
In every case I vote for that brilliant idea!
Roman

nhadrian wrote:Hi guys.

After many hours of trying I had to realize that I should spend on lot of time to learn the programming basics properly, and figure out how multiwii code works. In lack of this it is almost impossible to do finalize my idea. But also I think it would be 2-3 afternoon job for somebody who knows what to do, since even I had some success on i2c communication establisment between the two arduino panels (with some test modifications, I was able to turn on the LED of the secondary Arduino with an aux input of multiwii..... ), but I can't figure out how to read the data and import into the MW code properly, etc...

So here is the clear and final idea again, I wish somebody could do the programming job for the MWI community who uses Mini based boards...:

// legends: PRA - primary arduino with MW code, SEA - secondary arduino with GPS connected

- SEA and PRA are connected with i2c, SEA and GPS with serial
- SEA establishes serial communication with the gps and reads out GGA strings on 115200 baud (I have to use VTG too for my OSD because of airspeed, so the program should be able to read the GGA only from two type of sentences)
- SEA translates latitude, longitude, fix, satellite number values, and update these values continously if fix is OK (else leaves them unchanged)
- SEA learns home and hold coordinates and continously calculates the distance and direction between current position and home and hold coordinates (at initialization both should be the first fix, then changing regarding the followings)
- if PRA would read SEA, distance and direction to home; fix and numsat are available in 10 bytes from SEA. (fix 1byte, numsat 1 byte, distToHome 2 bytes, dirToHome 2 bytes, distToHold 2 bytes, dirToHold 2 bytes)
- I plan to put home position learning onto a spring-switch on my radio, so when spring state of switch is active in PRA, PRA asks SEA to learn the home position coordinates, but it could be linked to arming too.
- every time hold mode becomes active in PRA, it sends an order to SEA for learning the current position as hold. It is important to send the command only once per hold activation.
- PRA only uses the datas from SEA for positioning (distance, direction) to reduce PRA code size
- I think, for safety in both hold and home functions there should be a condition for fix=1, so when there is GPS fix, they are working, when fix takes away, hold and home deactivates, and copter stays in autolevel, and once fix returns, copter continues the way if option is still enabled.
- I think for both home and hold functions the same algorythm should used for first time since the task is almost the same, stay as close to the desired point as possible).
- as an addition, SEA led should light up when fix is OK (only some lines in code but great help for checking if GGA sentences are translated properly)

That's all folks!

BR
Adrian

ps.: sorry for my english, I'm not using the language daily... , and many thanks to EOSBandi for the basic idea...

dramida · Post by **dramida** » Fri Jan 13, 2012 12:48 am

I remember that Alex said that it could program an extra serial RX pin controlled by software to connect the gps to (for Atmega 328). The same extra RX pin i saw it to Remzibi who took the serial output from mwc and plotted on OSD, in parallel with serial GPS communication.

So i think this is the elegant solution, no extra hardware needed.

dialfonzo · Post by **dialfonzo** » Fri Jan 13, 2012 12:53 am

If we use i2c we still have all pins availible for other things.. no ?

rbirdie001 · Post by **rbirdie001** » Fri Jan 13, 2012 9:20 am

Hi Dramida!
Yes, of course, I had originaly the same idea of direct GPS connection but after some reading in forums I got feeling that not only missing serial is the problem. It seems that MWC in 328 is also running out of RAM memory and processing time (BTW remzibi have the same problems with his OSD!). ATMega 328 is simply becoming too small for projects which have grown so much.
So if there is the way to support GPS directly in primary 328, it would be perfect, but if not, then secondary arduino is great idea which can provide a lot of space for future developement. Once you have connected SD card and free RAM, you can log your flights, fly on waypoints, even repeat the same flight you have once recorded including height and speed (great e.g. for filming! When you expect some ocassion in the night, you can prepare your flight in the day and then in the dark it will fly alone.)... Almost unlimited possibilites so for one little arduino it could be great "added value"

The only problem is that I'm unable to write it alone so I'm just trying to encourage someone who can do it.

Nice day!
Roman

jevermeister · Post by **jevermeister** » Fri Jan 13, 2012 9:33 am

Hi,
my first copter was a selfmade shrediquette based copter with 328 and then I upgraded to multiwii flyduino based.

I now build a Arduino pro mini basedone for everyday action.

IMHO the flyduino copter is my mercedes with every feature I want: BARO,MAG,GPS,NICK/ROLL-Compensation, etc.
And the Arduino Mini copter is my action copter with only the neccesary stuff. I can live with that pretty well.

If I were you I would wait a couple of weeks until GPS is finished and get myself a mega board, it is worth every penny, is is very convenient and open for future development.

Nils

dramida · Post by **dramida** » Fri Jan 13, 2012 10:47 pm

rbirdie001 wrote:Hi Dramida!
It seems that MWC in 328 is also running out of RAM memory and processing time (BTW remzibi have the same problems with his OSD!). ATMega 328 is simply becoming too small for projects which have grown so much.

Remzibi uses Atmega 168 that means half of multiwii 328 based RAM .
If you read deeply in Alex's posts, he agrees that mwc has enough resources to make gps working with Atmega 328.

rbirdie001 · Post by **rbirdie001** » Sat Jan 14, 2012 10:21 pm

dramida wrote:
rbirdie001 wrote:Hi Dramida!
It seems that MWC in 328 is also running out of RAM memory and processing time (BTW remzibi have the same problems with his OSD!). ATMega 328 is simply becoming too small for projects which have grown so much.

Remzibi uses Atmega 168 that means half of multiwii 328 based RAM .
If you read deeply in Alex's posts, he agrees that mwc has enough resources to make gps working with Atmega 328.

OK, let's agree that both have some advantages - having GPS on one chip or two. For me it's more important which way will be earlier passable. I can't write code for any of those solutions so I can just try encourage people who can do it.
Anyway I guess that flight controller in 328 will not have enough resources to additionally connect SD card, write there logs, read POI, calculate vectors and navigate by side of controlling the copter so for future it's a good idea. I use (and like) remzibi OSD but I know he is now having troubles with the processor resources, mainly RAM.
Roman

cardboard · Post by **cardboard** » Sun Jan 15, 2012 3:20 am

I was skimming over bits an d pieces and started to play join the dots in my head.
multiwii has support for flying wings (which i fly via fpv but recently lost in teh middle of nowhere) and now gps support is being built in.
If i read correctly there is plans for RTH.
Would i be safe in saying that multiwii set in flying wing mode would be able to utilize the RTH function??
I would then like to ask if that works does someone with knowledge of the Rushduino OSD know if it would also utilize the gps data??
This would make a very powerful and cheap OSD RTH stabilization package.

Alexinparis · Post by **Alexinparis** » Sun Jan 15, 2012 10:48 am

Hi,

It think it's important to proceed step by step

Before working on other combos than MEGA+serial GPS, my aim is to bring a working GPS code.
according to EOSBandi video, we are not too far form this aim.

We can still have many ideas besides :

- a 328p is definitively powerful enough (speed and ram size) to handle GPS data + 10DOF sensors

- I2C GPS is a good solution:
* either in a transparent way (where the slave device does nothing more than translating serial to I2C data)
* or in a offload way (where the slave device could compute some GPS things)
* this should allow to see very cheap GPS FC solutions

NikTheGreek · Post by **NikTheGreek** » Sun Jan 15, 2012 1:32 pm

I know that probably i ' m the last one that i sould speak about this since i'm totaly new and unexperienced .
On the other hand i think it wont harm iff i say my opinion.

So far you have done exelent job with the Multiwii code.
Seems that working perfectly without significant problems(pls correct me if i'm wrong)
NOW you want to "add" some new features like GPS guidance - data recordings..etc...right ? :?:

From my point of view i think that is much better to keep the two "projects" separate. but at the same time working together.
How can be done ?
By adding a new board that will take signals from the RC receiver - calculate the GPS readings and waypoints - and then produce encoded signals ( one pin) in order to feed the second board exactly the same way you are doing now.
The first board...lets say it GPS Guidance Module ... needs only additionaly a magnetometer in order to produce the correct signnals....right ? :?:

This way the user..like me .. will be able to fly his "plane" with the basic features using the basic module and whenever he likes to advance by adding the second GGM module.
The additional cost is insignificant since with 10-20$ you can build a simple arduino .

I hope that you ll forgive me if i said something wrong.. :oops:

and i hope to understand what i'm trying to say. :oops:

rbirdie001 · Post by **rbirdie001** » Sun Jan 15, 2012 2:20 pm

Alexinparis wrote:Hi,

It think it's important to proceed step by step
Before working on other combos than MEGA+serial GPS, my aim is to bring a working GPS code.
according to EOSBandi video, we are not too far form this aim.

We can still have many ideas besides :

- a 328p is definitively powerful enough (speed and ram size) to handle GPS data + 10DOF sensors

- I2C GPS is a good solution:
* either in a transparent way (where the slave device does nothing more than translating serial to I2C data)
* or in a offload way (where the slave device could compute some GPS things)
* this should allow to see very cheap GPS FC solutions

Sorry for maybe stupid questions but I want to completely understand alex's post.
-What is ment 10DOF sensors, does it mean ONLY 10DOF or any supported set of gyro, acc, mag and baro + GPS wil work?
-What means GPS FC solution? (I can't find what is it).
-Additionally - is it expeted to support even faster GPS modules (like "to listen" GPS NMEA parallel at input of Remzibi OSD 38400bps, 5Hz)? Will there be enough processing time?
Thanks!
Roman

EOSBandi · Post by **EOSBandi** » Sun Jan 15, 2012 10:49 pm

Ok Guys,
It was a long weekend but finally it’s working (at least on the desk with GPS simulator).
It’s a standalone I2C GPS and NAV module which can offload navigational calculations from the main FC. After a waypoint is set and activated, the Multiwii FC only needs to read the distance and direction from the I2CGPS. Navigation can be suspended for holding current position and resumed later, by a simple command. The module can store up to 15 waypoints, and it’s also can give back gps speed, altitude and time if requested by the FC. Since calculation speed is not a real issue, I increased the precision for position calculation it’s 1/10 000 000 instead of 1/100 000. According to my test, the lower precision caused +/-5M errors in distance calculations in short ranges. Future plans are to add cross track error calculations and wind estimation, and eventually a pid controller for pos hold and waypoint nav.

The attached zip file contains the arduino sketch for the module. You can use a normal arduino nano or mini, GPS connected to the serial port, I2c connected to the 5V i2c bus on the FC. GPS must be configured for NMEA protocol at 115200 baud. GPGGA, GPGSA and GPRMC frames are decoded, but It’s easy to extend the decoder part. You can also find a TWI part of the Wire library in the zip file, this must be placed into the libraries/wire/utilities folder because the actual version of the Wire library does not handle repeated start in Slave mode. (this one does)
In Multiwii I implemented only the basic gps functionality. Home position is set when a 3d fix is reached, and when RTH is activated it comes back to the home position. If it works then I will go after the fancy parts.

Code now lives at http://code.google.com/p/i2c-gps-nav/ please go there and use the latest

marbalon · Post by **marbalon** » Sun Jan 15, 2012 11:07 pm

Hi,
Today I run first test on my custom board with Atmega 328.

my sensor setup is:
- L3G4200D
- ADXL345
- HMC5883
-BMP085
- and Mediatek GPS Gms‐u1LP - 10Hz + 115200 baud with custom firmware from GlobalTop.
http://download.maritex.com.pl/pdfs/wi/GPS-GMS-U1LP.pdf

First I've made some changes to get it work on Atmegs328. I decide to create detecting procedure at startup. If MWC receive NMEA frames in first two seconds I set flag GPSdetected, then use this flag to dissable qui and enable GPS transmition. If I don't miss anything here are all changes:

Code: Select all

global declaration
...
static uint8_t  GPSDetected = 0;

//--------------------------------------
annexCode()
...
  if (!GPSDetected)
    serialCom();

//--------------------------------------
setup() function
...
  #if defined(GPS)
  
  if (GPS_SERIAL != 0)
    SerialOpen(GPS_SERIAL,GPS_BAUD);
     
  //init GPS and detect GPS
  GPS_init();
  currentTime = micros();
  while(1)
  {
    if (SerialAvailable(GPS_SERIAL))


//-----------------------------------

loop() function
...
      if (rcData[YAW] < MINCHECK && rcData[PITCH] < MINCHECK && armed == 0) {
        if (rcDelayCommand == 20) calibratingG=400;
        GPS_fix_home = 0; //save home position again if gyro calibration occurs 

...
  #if defined(GPS)
    if (GPSDetected)
    while (SerialAvailable(GPS_SERIAL)) {
     if (GPS_newFrame(SerialRead(GPS_SERIAL))) {
        if (GPS_update == 1) 
        {
          GPS_update = 0; 
          STABLEPIN_ON; //toggle led to see NMEA frames
        }
        else 
        {
          GPS_update = 1;
          STABLEPIN_OFF;
        }
        if (GPS_fix == 1 && GPS_numSat > 4) {
     if (GPS_newFrame(SerialRead(GPS_SERIAL)))
     {
       GPSDetected = 1;
       break;
     }
     if (micros() - currentTime > 2000000)
        break;
  }  

...

in GPS file:
void GPS_init()
{ 
  char init1[] = "$PMTK314,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n"; //disable all messages except GPGGA
  //char init2[] = "$PGCMD,21,1*6F\r\n"; <-binary mode
  int i;
  
  delay (50);  
  for (i = 0; i < sizeof(init1); i++)
    SerialWrite(GPS_SERIAL,init1[i]);
}

Then I setup PID's for GPS: P=5 and D=5

Then I go outside. First I test head free mode and it works fine. Compass was tested using classic compass before and it show North correctly. then I fly forward me so about 20m and enable RTH. My quad start to fly right

Second test my quad start to fly left.

Conclusion:
GPS should works fine on arduino pro mini without any problems. My tests fails but the source of problems may be my setup. I try to isolate my MAG and GPS form other electronics, or I will try to test GPS when motors are running. Will try to read values on the PC.

Idea:
My module and many others have binary protocol too. I write function to parse binary frames and it is relay worth to switch to this frames. Code use less internal memory and ram works faster etc. But to be sure I've run this tests on NMEA protocol.
I also disable all frames except GPGGA it is correct ?
I will try to run more tests soon but today start snowing here (Poland) so it is to cold - maybe this is source of problem??? (all electronics are covered of course). I need to add MAG calibration patch from another post.

Marcin.

EOSBandi · Post by **EOSBandi** » Sun Jan 15, 2012 11:12 pm

Did you added the fix which described here? viewtopic.php?f=8&t=649&start=90#p7261

marbalon · Post by **marbalon** » Sun Jan 15, 2012 11:21 pm

EOSBandi wrote:Did you added the fix which described here? viewtopic.php?f=8&t=649&start=90#p7261

No. Just fixed and go to test outside. See you soon.

marbalon · Post by **marbalon** » Sun Jan 15, 2012 11:50 pm

Ok, now it works like on EOSBandi video. Overshot position, etc but work on Atmega328

I saw that when I read frames in binary format i have bigger precision so I need to modify code to work with higher resolution.

Marcin.

EOSBandi · Post by **EOSBandi** » Sun Jan 15, 2012 11:58 pm

Welcome to the club !
You can get the higher precision routines from the i2c code. I made same test and the position resolution of the current calculation is ~80cm, and it's not the low resolution of the gps data but the parsing and converting to degrees code limitation. Perhaps it's worth to try increasing the resolution from 1/100 000 to 1/10 000 000 as I did in i2c.

jevermeister · Post by **jevermeister** » Mon Jan 16, 2012 9:42 am

Hi,
I badly want to test the GPS feature but I am a little afraid of a runaway copter. So I want to test position hold first, can I test it by saving home position and stay above this position and active "return to home"?

To compile the multiwii.ino I need the new Arduino version right? Can I run them both on the same computer?

Thanks Nils

EOSBandi · Post by **EOSBandi** » Mon Jan 16, 2012 9:52 am

jevermeister wrote:Hi,
I badly want to test the GPS feature but I am a little afraid of a runaway copter. So I want to test position hold first, can I test it by saving home position and stay above this position and active "return to home"?

To compile the multiwii.ino I need the new Arduino version right? Can I run them both on the same computer?

Thanks Nils

You can, but if gps is not workin you will have a runaway copter anyway. So test it first with around 10 meter distance from home position and keep your finger on the rth disable switch. Also limit the max angle in gui to keep things under control.

marbalon · Post by **marbalon** » Mon Jan 16, 2012 10:03 am

Don't worry about copter. If you see that it start to fly in wrong direction you can always disable RTH function and you can control your quad. BTW you can use your sticks when RTH is enabled. GPS only insert correction. I will try to make i2c_gps_nav module today like described above and will give you more feedback.

@EOSBandi - What PID's are you using to test GPS?

Regards,
Marcin.

EOSBandi · Post by **EOSBandi** » Mon Jan 16, 2012 1:43 pm

marbalon wrote:@EOSBandi - What PID's are you using to test GPS?

My PID's are here viewtopic.php?f=9&t=1002#p7304

marbalon · Post by **marbalon** » Mon Jan 16, 2012 10:03 pm

Hi again,
I can say only wow. I just fallow EOSBandi instruction for i2c_gps_nav and everything works without any problems! So it is time to create separate small PCB for Atmega168 + GPS + MAG + Baro (i know baro can be one the main board but I have two quads so I can move this sensors between this models). I have one question. Waht values are you using in Dist to home box ?

Thanks again for this perfect solution!

Marcin.

jevermeister · Post by **jevermeister** » Mon Jan 16, 2012 10:57 pm

Hi,
call me stupid but I have a problem, I tried to merge the current dev with my code (1.9 Multiwii.PDE compiled with Arduino 022) and I used the Conf of 22.12.2011 but I have no vis.

No graphs, no Bars, and no values, I can save the Values but not see them. I almost crashed the copter becaus I forgot to calibrate the ACC d'oh.

Can you give me a hint what is wrong here?
Is it the wrong conf I am using or is the conf incompatible to code compiled with the old arduino tool.

Thank You!!!
Nils

btw: Headfree seems to work very well...

Alexinparis · Post by **Alexinparis** » Tue Jan 17, 2012 12:26 am

Hi EOS,
you did a great job !

Since calculation speed is not a real issue, I increased the precision for position calculation it’s 1/10 000 000 instead of 1/100 000. According to my test, the lower precision caused +/-5M errors in distance calculations in short ranges.

Could you explain more ?
According to the current accuracy (1/100 000), the distance step is around 1.11m
6372795 / 100000.0 * PI/180 = 1.11m

With 1/10 000 000, it would be 1.1cm
Are the GPS nowadays more accurate than 1m ?

EOSBandi · Post by **EOSBandi** » Tue Jan 17, 2012 1:27 am

Hi Alex,
Well, the issue is not in the distance calculation, but whith the lat/lon conversion routine. In the distance calculation I just followed the increased resolution of the coordinates.
Here is what I found:
Take a GPS coordinate, for example 47 34.2841N, 19 2.211E (This is my test field

)
Convert it to decimal degrees with 10e5 prec, and we got 47.5714N 19.0368E This point is 3.7meters away from the gps coordinate.
Now convert it with 10e7 precision and we got 47.571402N 19.03685E This is pretty much at the same point.

marbalon · Post by **marbalon** » Tue Jan 17, 2012 9:55 pm

Hi,
Today I made another fly test but with a little different setup:

- my bigger quad wit 11"x4,5 popeller
- KDA 20-22L
- weight about 1kg RTF
- GPS using i2c_gps_nav
- GPS PID P=2, D=5

Thanks to heavier electronics with GPS etc. and new dumpering method this quad become really stable. But it is quite heavy so it overshot position more. I will try to made another test with smaller PID values but this evening it starts snowing again - maybe my children will be happy tomorrow but how can I test GPS ?

I also try to add patch for real MAG calibration for RTH but it is not working on pro mini. After calibration board seems to reset when saving data to eprom.

Now I think we should think about RTH implementation. I think we need full PID because quad should have some software brakes to reduce speed when reached home position. I don't know if PID is enough but now it overshot position everytime.

End of report - I hope this winter will be really short

Edit.

Another test with smaller PID values. P = 0.8 and D=3. Works much better now. But I think we should change this lines from:

Code: Select all

      GPS_angle[ROLL]  = constrain(P8[PIDGPS] * sin(radDiff) * GPS_distanceToHome / 10,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // with P=5, 1 meter = 0.5deg inclination
      GPS_angle[PITCH] = constrain(P8[PIDGPS] * cos(radDiff) * GPS_distanceToHome / 10,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // max inclination = D deg

to

Code: Select all

      GPS_angle[ROLL]  = constrain(P8[PIDGPS] * sin(radDiff) * GPS_distanceToHome / 100,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // with P=5, 1 meter = 0.5deg inclination
      GPS_angle[PITCH] = constrain(P8[PIDGPS] * cos(radDiff) * GPS_distanceToHome / 100,-D8[PIDGPS]*10,+D8[PIDGPS]*10); // max inclination = D deg

But I think if we implement full PID result should be satisfied. All batteries are empty so today I can test anything.

ps. Sorry for my English - I almost sure I made many...

PatrikE · Post by **PatrikE** » Fri Jan 20, 2012 6:23 pm

@EOSBandi.
What does the Dist home show? CM,DM or meters?
Looks like cm for me!
While sitting inside with 5 sats Dist home soon shows a value of 70-100.
With serial connection it only shows 1-2.

But it works!..
Haven't tested it in flight yet.

copterrichie · Post by **copterrichie** » Fri Jan 20, 2012 6:44 pm

This may be a dumb suggestion to some but why not add a second arduino to handle all of the housekeeping items sure as GPS, Ultrasonic and Batteries monitoring? I purchased two of the Pro-Minis on Ebay a few days ago for 12 bucks each and I think the shipping was something like two bucks. I am sure some gifted enterprising person will come up with a shield to handle the job, wish I could but hopefully it will get done.

Here is a reference to connecting the two Arduinos.

http://hackaday.com/2011/11/08/a-simple ... -capacity/