GPS integration

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
User avatar
Gaijin
Posts: 82
Joined: Sat Jan 14, 2012 8:00 am

Re: GPS integration

Post by Gaijin »

EOSBandi,

Just curious but I'm guessing that the I2C variant will require a combination of Co-ordinated I2C Gps (Navigatron in my case) and MultiWii sketches to function correctly.
One to provide the GPS co-ordinates and one to act on them, how much can you offload to the second processor?
Can the Atmega328 based GPS and I2C Bus provide sufficient resolution? (here's hoping)

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: GPS integration

Post by jevermeister »

Hi,
it should be an option to decide wheter the copter should rotate nose/back to home direction om rth or not.

I use RTH as a panic function to retrieve my copter when I am about to loose it or when I lost orientation.

So for me it would be best to return to me with the nose facing away from me to regain control.

But if you want a cool approch or a cam approch to home you would prefer nose ahead.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

Gaijin wrote:EOSBandi,

Just curious but I'm guessing that the I2C variant will require a combination of Co-ordinated I2C Gps (Navigatron in my case) and MultiWii sketches to function correctly.
One to provide the GPS co-ordinates and one to act on them, how much can you offload to the second processor?
Can the Atmega328 based GPS and I2C Bus provide sufficient resolution? (here's hoping)


In order to fit into the memory constraints of the 328 based flight controllers, I would like to offload as much calculations as possible to the i2cgps proc. All PID controls and most of the navigation calculations wil run on the i2cgps. The i2cgps will output a nav_lat and nav_lon which is the desired banking according to the lat/lon coordinate system. The only calculation which has to be on the FC is the rotation of this desired banking into a copter's frame of reference. (1sin,1 cos and same multiplications).

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

jevermeister wrote:Hi,
it should be an option to decide wheter the copter should rotate nose/back to home direction om rth or not.

I use RTH as a panic function to retrieve my copter when I am about to loose it or when I lost orientation.

So for me it would be best to return to me with the nose facing away from me to regain control.

But if you want a cool approch or a cam approch to home you would prefer nose ahead.


OK, input taken... this will be someting like this..

#define GPS_NAV_CONTROLS_HEADING //Copter heading is controlled by the navigation process, heading towards destination
#deifne GPS_NAV_YAW_REVERSE //Tail towards destination

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: GPS integration

Post by Katch »

Really looking forward to testing the i2c gps - keep up the good work.

User avatar
howardhb
Posts: 189
Joined: Tue Oct 11, 2011 7:10 pm
Location: Port Elizabeth, South Africa

Re: GPS integration

Post by howardhb »

EOSBandi wrote:OK, input taken... this will be someting like this..

#define GPS_NAV_CONTROLS_HEADING //Copter heading is controlled by the navigation process, heading towards destination
#deifne GPS_NAV_YAW_REVERSE //Tail towards destination


+1 :D

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: GPS integration

Post by LuFa »

+1 :mrgreen:

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: GPS integration

Post by jevermeister »

EOSBandi wrote:
jevermeister wrote:Hi,
it should be an option to decide wheter the copter should rotate nose/back to home direction om rth or not.

I use RTH as a panic function to retrieve my copter when I am about to loose it or when I lost orientation.

So for me it would be best to return to me with the nose facing away from me to regain control.

But if you want a cool approch or a cam approch to home you would prefer nose ahead.


OK, input taken... this will be someting like this..

#define GPS_NAV_CONTROLS_HEADING //Copter heading is controlled by the navigation process, heading towards destination
#deifne GPS_NAV_YAW_REVERSE //Tail towards destination



u rock mate!

rbirdie001
Posts: 178
Joined: Fri Apr 01, 2011 10:32 pm
Location: Czech Republic, Prague

Re: GPS integration

Post by rbirdie001 »

Hi EOSBandi,
nice to see you back and thanks for your great work!
I'm another one who can't wait for testing of new navigation functions but having 328 based FC and separate I2C GPS board I have to wait for I2C version :( .
So +1 for it :mrgreen: !
Roman

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: GPS integration

Post by shikra »

Awesome progress. Looking forward to testing soon.

In pos hold, is it possible to hold orientation in any direction - set by yaw input - for the AP guys...

I think in RTH, having in come in head first or tail first seems the natural way to go.

If this is as good as the GUI - will be great!!

User avatar
howardhb
Posts: 189
Joined: Tue Oct 11, 2011 7:10 pm
Location: Port Elizabeth, South Africa

Re: GPS integration

Post by howardhb »

@EOSBandi, thanks for your work on this new NAV thinking! I think you are on the the right course... :lol:

I've applied your new functions to dev20120504 (with the library functions APM_PI and AC_PID) and will test in the morning.
As I am using a serial GPS, for debuging the port to dev20120504, I needed to "see" (in the GUI) distance to home and direction to home....
So, in order to serialze the data, I added some original code:

In your GPS_NewData() function...

Code: Select all

    if (GPSModeHold == 1) {
           //*** experimental gps poshold
           .
           .     
           //Desired output is in nav_lat and nav_lon where 1deg inclination is 100
           GPS_distance(GPS_latitude_hold,GPS_longitude_hold,GPS_latitude,GPS_longitude, &GPS_distanceToHold, &GPS_directionToHold); // just for debugging
           .
           .
           .
          else if (GPSModeHome == 1) {
          //*** experimental gps loiter for
          //Desired output is in nav_lat and nav_lon where 1deg inclination is 100
          GPS_distance(GPS_latitude_home,GPS_longitude_home,GPS_latitude,GPS_longitude, &GPS_distanceToHome, &GPS_directionToHome); // just for debugging


The GUI will, no doubt, change to suit your new variables, you can then decide how to display them.

Howard.

User avatar
howardhb
Posts: 189
Joined: Tue Oct 11, 2011 7:10 pm
Location: Port Elizabeth, South Africa

Re: GPS integration

Post by howardhb »

And, I can now see the benefit of going to I2C for GPS... :o
My cycle-time has increased from 2800-3200 up to 3100-4500 !

Is anyone, other than Flytron making a I2C GPS board?

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS integration

Post by dramida »

My 2 cents:
When the copter reach its holding position, the copter should disable head first(or tail first) in order to avoid spinning around its tail.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

dramida wrote:My 2 cents:
When the copter reach its holding position, the copter should disable head first(or tail first) in order to avoid spinning around its tail.


Exactly, in addition to that there must be two sets of navigation controls, one for the pos hold, and one for the navigation between two points. Now as the pos hold is ok, i'll add the second one.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

howardhb wrote:And, I can now see the benefit of going to I2C for GPS... :o
My cycle-time has increased from 2800-3200 up to 3100-4500 !

Is anyone, other than Flytron making a I2C GPS board?


In flight you will not notice the inceased cycle time... (or at least I did not noticed...)

PatrikE
Posts: 1957
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: GPS integration

Post by PatrikE »

I just want to double check.
I'm working on RTH for Fixed wing and would like to use Gps for altitude, speed and heading.

I find in mwii file.
static int16_t GPS_altitude,GPS_speed; // altitude in 0.1m and speed in 0.1m/s

And in the GPS code.
varptr = (uint8_t *)&GPS_altitude; // altitude in meters for OSD


BaroAlt seems to use cm.
Can anyone confirm if meters is the Unit for GPS?

PatrikE
Posts: 1957
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: GPS integration

Post by PatrikE »

I found out that it's meters for Gps.

Next question...
Does this mean Gps altitude between 0 & 512 meters?
varptr = (uint8_t *)&GPS_altitude;

In that case this would be more correct.
varptr = (int16_t *)&GPS_altitude;

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

No,
the gps altitude is an int16, but since we read it out byte by byte, we need a byte pointer, the cast just make sure that the varptr will point to the first byte of the GPS_altitude variable, then we read the first byte to the position where varptr points, and increase the pointer and read the second bye.

PatrikE
Posts: 1957
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: GPS integration

Post by PatrikE »

Ok Thanks.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS integration

Post by dramida »

A video of Bandi's GPS serial patch working on atmega 328.
It is a big improvement over the MWC 2.0 but isn't perfect yet. Of corse, i played a little with PI velocity controller but those are my best results.

http://www.youtube.com/watch?v=giEBweK63Cc

Note that alt hold works good, but also, not perfect.

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: GPS integration

Post by LuFa »

your video is great :D
i think the code work 1000% better than the old GPS PH Code ;)
Cant wait to test it with my new board (my old board with the Flip proplem is now Totaly Crash)

witch GPS did you use and with how many hz ?

User avatar
howardhb
Posts: 189
Joined: Tue Oct 11, 2011 7:10 pm
Location: Port Elizabeth, South Africa

Re: GPS integration

Post by howardhb »

@EOSBandi, today applied your new code (with Library functions APM_PI and AC_PID) to DEV20120504. I think you are on the right track with this way of thinking about NAV...
I flew my copter today and did not notice any difference in flying characteristics, even with cycle time increase. :D

Positon hold is ok, but I need to tune the PID's.
I found the initial hold good (straight after switching Hold on), but after a minute, slow, lazy oscillation became more and more like over-shoot and over-compensation.
Which parameter should I change first?

I've added the new NAV PID's (HOLD and HOLD_RATE) to EEPROM and also to LCD config.
Now I will be able to easily / quickly tune the parameters :)

A question about NAV - return to home
The direction that the NAV indicator in the GUI shows.... (see below a snap-shot of GUI when my copter is facing directly towards a memorised HOME position)
Is this correct? (I recall a discussion about TO home or FROM home.....)
Compas and GPS.png

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

Hi,
The gui shows a correct values... toward home and 7 meters.
If it start oscillating then you should lover the HOLD P and increase the D a little bit.. my current parameters for my dev tri are

#define POSHOLD_P .11
#define POSHOLD_I 0.0
#define POSHOLD_IMAX 20 // degrees

#define POSHOLD_RATE_P 1.2 //
#define POSHOLD_RATE_I 0.2 // Wind control
#define POSHOLD_RATE_D 0.005
#define POSHOLD_RATE_IMAX 20 // degrees

It's still not rock solid, but stays within a couple of meters.

Btw, I just pushed a huge update to the repo. Now added navigation PID and RTH speed control with a cross track error correction. Now when RTH is activates it flies direcly towards the home position (controlling only the speed and the bearing) and when approaches the position it slows down and switch to POShold.

Unfortunately the code now is bigger than 32K.
Please note that the last update was not flight tested yet and it's very likely that there are some errors...
A

User avatar
howardhb
Posts: 189
Joined: Tue Oct 11, 2011 7:10 pm
Location: Port Elizabeth, South Africa

Re: GPS integration

Post by howardhb »

Yes, I saw your latest pushed update.... Nice!
You're developing it faster than I can adapt it to DEV20120504..... so think I'll stop doing that, for now.
I'm using a MEGA2560, so size is ok.
Thanks! I will try your PID's tomorrow.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS integration

Post by dramida »

LuFa wrote:your video is great :D
i think the code work 1000% better than the old GPS PH Code ;)
Cant wait to test it with my new board (my old board with the Flip proplem is now Totaly Crash)

witch GPS did you use and with how many hz ?

Thank you, Bandi did the codding, i just film the results.
I was using an NMEA serial GPS @38400 baud and 10 Hz update from an old remzibi OSD (mediatek chipset patch antenna, smd, GTPA010)
I hope that will be a MWC GPS version witch fits on 328 boards also.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

howardhb wrote:Yes, I saw your latest pushed update.... Nice!
You're developing it faster than I can adapt it to DEV20120504..... so think I'll stop doing that, for now.
I'm using a MEGA2560, so size is ok.
Thanks! I will try your PID's tomorrow.


Hi ,

Once algorithms are working, i'll adopt it to latest dev (including the i2c_gps) but first I have to have a working code (pos hold is OK now, and i'm closing on the RTH (waypoint navigation)...

Btw, I increased POSHOLD_RATE_D to 0.008 and it's siginificantly better.

ygl611
Posts: 9
Joined: Mon Mar 05, 2012 1:29 am

Re: GPS integration

Post by ygl611 »

Just test code R8, position hold is 'ok, but RTH seems worse than before. Maybe the RTH PID need to adjust more . THe R8 code still can be used on 328 board with serial port GPS ,"Binary sketch size: 28994 bytes (of a 30720 byte maximum)"

BrokenRotor
Posts: 9
Joined: Sat Mar 19, 2011 2:05 pm

Re: GPS integration

Post by BrokenRotor »

EOSBandi, I have tried your "multiwii-gps-work" SVN package and have a few weird issues.

My test copter is a standard home brew flat HEX with a Seedstudio Mega1280 board, FFIMU V2, and serial MTK PA6C GPS. Running the standard MW 2.0 code it flies OK, and the GPS presents data correctly to the WM-GUI.

However, when I load up your code, the GUI shows the GPS # of satellites found, but the course is locked at 180 degrees at 0 Meters to home and does not change. When I attempt to fly (with GPS disabled) it lifts off straight, but then starts spinning around like a top as soon as it lifts off.

I am doing the normal "config.h" settings. Is there something I am missing here?

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

ygl611 wrote:Just test code R8, position hold is 'ok, but RTH seems worse than before. Maybe the RTH PID need to adjust more . THe R8 code still can be used on 328 board with serial port GPS ,"Binary sketch size: 28994 bytes (of a 30720 byte maximum)"

check r9, there was an error in r8 which prevents the copter to enter into poshold once it arrived home..
Also Nav pid's have to lowered significantly...I flight tested R9 and it's working quite qood. Porting to I2cgps right now.

THere are also some issues when entering into poshold or RTH with too much speed. I still need to work in it... What I recommend for testing RTH, try to minimalise horizontal speed then enter into poshold for a couple seconds, then activate RTH.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

BrokenRotor wrote:EOSBandi, I have tried your "multiwii-gps-work" SVN package and have a few weird issues.

My test copter is a standard home brew flat HEX with a Seedstudio Mega1280 board, FFIMU V2, and serial MTK PA6C GPS. Running the standard MW 2.0 code it flies OK, and the GPS presents data correctly to the WM-GUI.

However, when I load up your code, the GUI shows the GPS # of satellites found, but the course is locked at 180 degrees at 0 Meters to home and does not change. When I attempt to fly (with GPS disabled) it lifts off straight, but then starts spinning around like a top as soon as it lifts off.

I am doing the normal "config.h" settings. Is there something I am missing here?


Gui is not updated yet, so it's normal if you not see distance and speed. If it's spinning that means that gps rth is enabled. Check RC settings. And check out R9, I fixed the spinning issue with RTH.

ygl611
Posts: 9
Joined: Mon Mar 05, 2012 1:29 am

Re: GPS integration

Post by ygl611 »

Tried R9, RTH works great!! When activate RTH ,Copter head turns back to home automaticly, It's realy funy and helpful when you get use to this . There is a obviously "brake" when the copter get close to home position(5 or 6 meter), Is it possible to select head to home or tail to home ,even like CF ,no tail or head when copter come home?
Last edited by ygl611 on Thu May 10, 2012 1:58 pm, edited 1 time in total.

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: GPS integration

Post by Katch »

very much looking forward to testing this out - will it be relatively simple to do the i2c version once serial is working or is that another huge chunk of work?

didlawowo69
Posts: 38
Joined: Tue Oct 11, 2011 1:42 pm

Re: GPS integration

Post by didlawowo69 »

any news on win-gui ?

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

Katch wrote:very much looking forward to testing this out - will it be relatively simple to do the i2c version once serial is working or is that another huge chunk of work?


Not as big as the poshold/rtl code. (I had to re-learn trigonometrics :D )
I can declare the algorithm finished now. I flew three packs (45min) in light breeze with good poshold and quite good rth. Will push the update R10 to google code and finish the integration to i2c codebase till monday. Then I take a look into winGui and the new serial protocol. :D
EOSBandi

BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: GPS integration

Post by Katch »

EOSBandi wrote:
BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?


I've flown quite a few packs on the 5th may dev version with i2c GPS enabled (but obviously not with usable RTH or POS) - absolutely no issues with it. I think quite a few other people are flying the latest dev.

Massive thanks and respect for all your work at this time. I wish there was more that I could contribute to the hard parts of this project - I have made some small additions to shared lately though.

Looking forward to trying your i2c code ;)

User avatar
Gaijin
Posts: 82
Joined: Sat Jan 14, 2012 8:00 am

Re: GPS integration

Post by Gaijin »

Katch wrote:
EOSBandi wrote:
BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?


I've flown quite a few packs on the 5th may dev version with i2c GPS enabled (but obviously not with usable RTH or POS) - absolutely no issues with it. I think quite a few other people are flying the latest dev.

Massive thanks and respect for all your work at this time. I wish there was more that I could contribute to the hard parts of this project - I have made some small additions to shared lately though.

Looking forward to trying your i2c code ;)


Seconded, Sunday looks fine and dry here,it's a bit cheeky but any chance of I2C GPS by then?

P.s What is the method used to set the home position in your current codebase, is it the Gyro Cal stick combo?

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: GPS integration

Post by mbrak »

EOSBandi wrote:...

BTW, What is the consesus? Is it OK to fly the post MW2.0 dev code ?



if you mean the 20120430 and newer DEV i will say yes :)
this DEV is working very well i think. had no problems with both quads.

good work andras !!!

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: GPS integration

Post by guru_florida »

Hi Eosbandi,

Thanks for doing such a great job on the i2c-gps code. Well done! I made a little mod that turns the STATUS light (pin 13) into a GPS lock status light. It:
* blinks once per second if gps is sending data but no position lock yet
* blinks twice fast, then off for a second if gps 2D position is available
* blinks 3 times fast, then off for a second if gps 3D position is available
* or goes on for a second, off for a second, (long pulse) if not getting any NEMA sentences for over 5 seconds

First, add this block before "loop()"

Code: Select all

#define BLINK_INTERVAL  90

static uint32_t lastframe_time = 0;

static uint32_t _statusled_timer = 0;
static int8_t _statusled_blinks = 0;
static boolean _statusled_state = 0;

void blink_update()
{
  uint32_t now = millis();
  if(_statusled_timer < now) {
    if(lastframe_time+5000 < now) {
      // no gps communication 
      _statusled_state = !_statusled_state;
      digitalWrite(13, _statusled_state ? HIGH : LOW);   // set the LED off
      _statusled_timer = now + 1000;
      return;
    }
       
    if(_statusled_blinks==0) {
      if(i2c_dataset.status.gps3dfix == 1)
        _statusled_blinks=3;
      else if(i2c_dataset.status.gps2dfix == 1)
        _statusled_blinks=2;
      else
        _statusled_blinks=1;     
    }
   
    if(_statusled_state) {
      _statusled_blinks--;
      _statusled_state = false;
      _statusled_timer = now + ((_statusled_blinks>0) ? BLINK_INTERVAL : 1000);
      digitalWrite(13, LOW);   // set the LED off
    } else {
      _statusled_state = true;
      _statusled_timer = now + BLINK_INTERVAL;
      digitalWrite(13, HIGH);   // set the LED on
    }
  }
}


Then add the call to blink_update() to the main loop (like before the watchdog check):

Code: Select all

  blink_update();              <---- add this!!!

if (_watchdog_timer != 0)

  if (_watchdog_timer+1200 < millis())
     {
  . . .


and this line just after the GPS_newFrame() call returns. I had to create a lastframe_time variable so I could know when the last NEMA sentence came through.

Code: Select all

  //Get gps data and parse
  while (Serial.available()) {
    if (GPS_newFrame(Serial.read())) {

      lastframe_time = millis();       <--- add this!!!

      if (i2c_dataset.status.gps2dfix == 1) {
        //Set current target after fix, this is for safety
        if (GPS_fix_home == 0) {

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: GPS integration

Post by guru_florida »

So I have the i2c GPS working, using latest R10 eosbandi release, and also using MultiWii 2.0 May5th dev (latest). I configured the GPS HOME and GPS HOLD switched. But I have no idea what those switches actually do? I flight tested and flipped the switches but no response. I cant find info on how to RTH or gps hold.

So if someone can enlighten me:
1. How do we set the HOME position?
2. How do we tell the copter to RTH?

Thanks guys, I am sure it's been answered somewhere in the big list of messages, but I cant find it.

Colin

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

guru_florida wrote:So I have the i2c GPS working, using latest R10 eosbandi release, and also using MultiWii 2.0 May5th dev (latest). I configured the GPS HOME and GPS HOLD switched. But I have no idea what those switches actually do? I flight tested and flipped the switches but no response. I cant find info on how to RTH or gps hold.

So if someone can enlighten me:
1. How do we set the HOME position?
2. How do we tell the copter to RTH?

Thanks guys, I am sure it's been answered somewhere in the big list of messages, but I cant find it.

Colin


i2c gps does not work with the r10, it's a dev version for testing the algorithms and works only with serial gps. Currently i'm porting it to the i2c gps and to latest dev MultiWii code... stay tuned

sandmen
Posts: 24
Joined: Mon Feb 21, 2011 3:26 pm

Re: GPS integration

Post by sandmen »

Already flash your code.
Changed the DECLINIATION, and some parameter.
Which GUI do you use or can I use?
Is there something special, to test GPS Pos Hold or Return To Home?
Normal switch config?

Thanks
Peter

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: GPS integration

Post by EOSBandi »

OK, it's for R10 with serial GPS. Please note again it's a DEV/Proof of Concept so fly it on your own risk :D

Normal switch config is fine. Use v2.0 gui or 1.04 WinGUI.
I recommend to use headfree mode, in case you lost orientation...

First test poshold then RTH.
Home position is set when copter is armed. So plug your battery and fly to your home position (I recommend at least 5/10 meters away from you) land, disarm and arm again. This sets the home position. Copter must be well trimmed and in level mode. Good mag is also a must, if you can, check your mag orientation with a compass, it must be dead on.

Now takeoff, and try pos hold. It works best if there is minimal horizontal speed when activating. If copter is moving you should exept a couple of swings before copter settles. You can try increasing poshold_rate D only by 0.001-0.002 at a time. If hold is not good enough you can increase P terms, also by 0.01-0.02 at a time. if copter swings or circles thet lower it, or increase D.

Once Poshold is ok, then you can try RTH.
There are three defines which controls orientation during RTH
#define NAV_CONTROLS_HEADING true // copter faces toward the navigation point, maghold must be enabled for it
#define NAV_TAIL_FIRST false // true - copter comes in with tail first
#define NAV_SET_TAKEOFF_HEADING true // true - when copter arrives to home position it rotates it's head to takeoff direction
It's working when magHold is enabled, so if your copter start spinning just disable magHold and take over the yaw. (having headfree mode is very usefull, i managed to bring home a constantly spinning copter during an earlier test)

So fly away some distance and at first try activate poshold, let the copter settle for a couple of seconds, and then activate RTH. With the above settings your copter should turn towards the home point and start approaching. Once it's arrived it will change to a poshold and rotate it's head to the same direction as it was when armed.

I'm progressing with i2c port, expect to have it flight tested during the weekend.

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: GPS integration

Post by Katch »

woop woop!

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: GPS integration

Post by guru_florida »

i2c gps does not work with the r10, it's a dev version for testing the algorithms and works only with serial gps. Currently i'm porting it to the i2c gps and to latest dev MultiWii code... stay tuned


I think I misunderstand something. R10 is the release version of the i2c-gps-nav project right? Is it the i2c-gps-nav project that needs updating/porting, or is it the MultiWii algorithms that need updating (to talk to i2c-gps-nav)?

MultiWii reports a good GPS position and approx 9 satellites. Do you mean the MultiWii RTH algorithms only work with a directly connected serial unit (on a Mega)? I have a serial gps (Trimble - Condor C2626) hooked into an atmel running your i2c-gps-nav code (r10), then that hooked into MultiWii using the i2c.

Thanks,
Colin

Katch
Posts: 280
Joined: Thu Aug 04, 2011 1:44 pm

Re: GPS integration

Post by Katch »

guru_florida wrote:
i2c gps does not work with the r10, it's a dev version for testing the algorithms and works only with serial gps. Currently i'm porting it to the i2c gps and to latest dev MultiWii code... stay tuned


I think I misunderstand something. R10 is the release version of the i2c-gps-nav project right? Is it the i2c-gps-nav project that needs updating/porting, or is it the MultiWii algorithms that need updating (to talk to i2c-gps-nav)?

MultiWii reports a good GPS position and approx 9 satellites. Do you mean the MultiWii RTH algorithms only work with a directly connected serial unit (on a Mega)? I have a serial gps (Trimble - Condor C2626) hooked into an atmel running your i2c-gps-nav code (r10), then that hooked into MultiWii using the i2c.

Thanks,
Colin


I2C GPS requires code on the Arduino on the GPS board to do all the POS hold and RTH calculations. r10 is only implementing serial GPS at the moment. EOSBandi needs to port that code across to be a stand alone sketch that runs on the I2C GPS board .

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS integration

Post by dramida »

Last Edit: I was wrong about R10, my setup was faulty. Excuse me.

Upgrading from R6 to R10 Eos_Bandi GPS serial Nav branch.
The good results of GPS position Hold R6 vanished........................
Hardware:

Crius SE 328 multiwii board with NMEA serial GPS @ 10HZ MediaTek cipset from remzibi OSD and R10 Bandi MWC 2.0 branch.
Last edited by dramida on Sun May 13, 2012 9:41 am, edited 3 times in total.

User avatar
Jonit
Posts: 37
Joined: Sat May 12, 2012 10:12 pm
Location: Slovakia

Re: GPS integration

Post by Jonit »

Hi everybody, i have a quesion. I have this BT GPS module. Image It is possible to make it working with MWC ? I wanna try features that GPS offers on my hexa, but i dont wanna buy a new GPS module if there is a way to make it works with this BT module. So, it is possible? Thanks.
Jonit

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: GPS integration

Post by Tommie »

Yes, I used my TinyGPS chip with a bluetooth GPS once. Most BT GPS devices are just plain old serial GPS receivers with an additional BT module slapped on. If you can identify the TTL-TX wire inside the device, you can just use it like any serial GPS.

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: GPS integration

Post by dramida »

Tested MWC R10 GPS pos Hold on windy day, it has a maximum error radius about 5. If there is no wind, the results are better.
Also there is a small bug, giro calibration dosen't work anymore if done from the sticks.
Now i am preparing to go on the field and make a few movies with GPS RTH and Pos Hold.

LuFa
Posts: 160
Joined: Fri Jan 27, 2012 7:56 pm

Re: GPS integration

Post by LuFa »

5m at Wind is brilliant !
cant wait to see a video from your PH and RTH

edit : wich GPS Modul did you use ?

Post Reply