GPS integration

[ApoC]

Those GUI buttons have always been buggy - you just have to keep trying them - click move to see if it took if not click move again.

Jep - i HATE this. Thats why i use the WinGUI, when its ported to the new Version.

The old GUI is outdated. Its frustating me every Time i use it.....plz rewrite, make it better plz. The damn Bottons (AUX) are not staying, if i clicked them. I have to hoover to check, if there on or off.....

What i hate too is, when i have some nice Code (Hexa Patch, Blink Codes and so on) and a new Version, like the new GPS Code, i have not this nice features anymore, because there are not in this Code.

Is it possible to merge the new GPS Code in my existing Code, that i fly atm? Im not a Coder, so i dont know, how it works.

[EOSBandi]

Guys,
I just would like to reminder everyone who tries this code... it's a development version, not synced with the current multiwii dev tree. I just took the 20120504 dev release and put the gps code there... once it proven to work i transfer it to alex to merge it into the actual dev trunk (Or I'll do if necessary). Till that, a programming knowledge and familiarity with MultiWii internal workings are recommended for testing.
Bandi

[EOSBandi]

dark got me so only 1 batt tested, works like it should,
needs PID tuning obviously, but good for first flight with new code. It didn't freeze mid-air

It's awesome to see Hexa turn around by itself and slowly crawl back to home position, and stops there, sick!

(changed max speed to 200cm/s, and min speed to 50cm/s, 400cm/s seemed to much to me for first test flight)

Good to hear that
I just find an excelent PID tuning simulator, which can help to understand the role of the POSHOLD and POSHOLD_RATE PID's. It's made by Jason Short from DiyDrones who is the genius behind arducopter loiter code. The simulator based on the latest arducopter code, which I ported to multiwii, so you can apply what you find in the simulator to real life...
http://diydrones.com/profiles/blogs/ac2 ... -tuner-sim

[ApoC]

(changed max speed to 200cm/s, and min speed to 50cm/s, 400cm/s seemed to much to me for first test flight)

Can u explain, where do u changed that?

Im not a Coder, but with my Testflights i hope i can help.

[GrAl]

Guy
please help me choose parts.
I have MWC MultiWii SE Standard Edition 4-axis Flight Control Board QUADX w/ FTDI Basic Breakout on plane, and want use GPS for RTH.
What me need buy additional?

[wolle]

Hello,
where you need to copy the PID libs go?
I get an error message when you compile the scetch.

Greetings Wolfgang

[wolle]

Ok, I got it back.

It works now! I'll test it later times.

[howardhb]

You should create 2 new folders inside the "libraries" folder (find where Arduino-1.0 is installed, typically C:\Program Files\arduino-1.0)

(1) C:\Program Files (x86)\arduino-1.0\libraries\AC_PID
Inside this folder, put: AC_PID.cpp and AC_PID.h

(2) C:\Program Files\arduino-1.0\libraries\APM_PI
Inside this folder, put: APM_PI.cpp and APM_PI.h

Then, in C:\Program Files\arduino-1.0\libraries\Wire:
replace Wire.cpp and Wire.h

H.

[wolle]

Thank you! I then understood it man would sometimes turn on the head.

Is it normal that the gps module without which I move, the speed jumps back and forth?

[wolle]

for those who need a FW for the PA6B to "115200 baud 10Hz" or "115200 baud 5 Hz", you can download it here:

http://www.wii-copter.de/forum/downloads.php?cat=8

I have let me create it from the manufacturer.

[Y.Mita]

Those GUI buttons have always been buggy - you just have to keep trying them - click move to see if it took if not click move again.

Thank you, Katch. But my problem is not AUX1,AUX2,AUX3,AUX4 setting. The button of "CALIB_MAG" and "CALIB_ACC" seems clicked, but not activate MAG calibration and ACC caribration.
I tried caribration from RC sticks, but ACC caribration not start, MAG caribration starts.

I just would like to reminder everyone who tries this code... it's a development version, not synced with the current multiwii dev tree. I just took the 20120504 dev release and put the gps code there... once it proven to work i transfer it to alex to merge it into the actual dev trunk (Or I'll do if necessary). Till that, a programming knowledge and familiarity with MultiWii internal workings are recommended for testing.

Yes! of course I know! Thanks your development version, we can try and test it.

[Katch]

getting good results today.

Back on my Paris v4 GY_86 (FreeIMU 0.4.3 clone) after sorting out the messed up eeprom issue.

Still need to play with the PID settings to get it locked in. It's hard doing it out in the field as I can't use my Android phone like I usually do (GPS settings currently unsupported)

Hold and RTH definitely working now just need to decrease the loiter area some.

I am still noticing the Quad make some pretty jerky movements when in position hold. I'm sure it would reduce the pendulum effect and the loiter area if we could smooth those correction out a little.

[howardhb]

GY_86 (FreeIMU 0.4.3 clone)

Can you supply some more info. Please!

[howardhb]

@Katch, you can now edit GPS settings at the field. All GPS parameters are editable using LCD_CONFIG.

[Katch]

yup don't have one.

go read the Chinese IMUs thread in development for info on that GY_86.

eBay search mpu6050 10 dof

[EOSBandi]

Hi Guys,
Just flown three packs in a light breeze. Solid poshold and realible RTH. For poshold take a note about the entering speed, the larger the speed when you inter into poshold, the bigger the pendulum will be, but it slows down after two/three swings.

Since I crashed my quad with i2c gps (it wasn't the code, rather the 30mhp wind ), i switched back to the tri with serial gps. I also implemented Jason's latest changes to the PID algorithms. Will upload it to the repo this evening.

I'll rebuild my quad and continue testing of the i2c part.But Unless there are some serious bug, it should work the same as the serial code.

EOSBandi

[howardhb]

@ Katch, see this thread: viewtopic.php?f=7&t=1096
You don't need a specific MultiWii app. for your phone.
You can simply download an Android VT00 Terminal emulator for your phone.
http://www.androidzoom.com/android_appl ... boaja.html
In Config: #define #define LCD_CONF and #define LCD_VT100.
Voila!

[howardhb]

@EOSBandi, will the PID settings then be similar to the values used in the On-line Simulator?
If yes, then we will need to format the LCD / OLED values to suit the number of decimal places....
In LCD.ino, replace:

Code: Select all

#if GPS
 &lcd_param_text80, &P8[PIDPOS] , &__RC,
 &lcd_param_text81, &I8[PIDPOS] , &__I,
 &lcd_param_text82, &P8[PIDPOSR], &__P,
 &lcd_param_text83, &I8[PIDPOSR], &__RC,  
 &lcd_param_text84, &D8[PIDPOSR], &__I,
 &lcd_param_text85, &P8[PIDNAVR], &__P,
 &lcd_param_text86, &I8[PIDNAVR], &__RC, 
 &lcd_param_text87, &D8[PIDNAVR], &__I,
#endif

with this:

Code: Select all

#if GPS
 &lcd_param_text80, &P8[PIDPOS] , &__RC,
 &lcd_param_text81, &I8[PIDPOS] , &__I,
 &lcd_param_text82, &P8[PIDPOSR], &__P,
 &lcd_param_text83, &I8[PIDPOSR], &__RC,   
 &lcd_param_text84, &D8[PIDPOSR], &__RC,
 &lcd_param_text85, &P8[PIDNAVR], &__P,
 &lcd_param_text86, &I8[PIDNAVR], &__RC, 
 &lcd_param_text87, &D8[PIDNAVR], &__RC,
#endif

[EOSBandi]

But it's the same

The precision for the GPS nav parameters will be the same as they have in the GUI
POS : .01 for P and .1 for I
POSR and NAVR : .1 for P .01 for I and .001 for D

[wolle]

@EOSBandi
it not the same

Code: Select all

...  
&lcd_param_text84, &D8[PIDPOSR], &__RC,
...
&lcd_param_text87, &D8[PIDNAVR], &__RC,
...

Wolle

[dr.tom]

are those checkboxes properly defined somewhere in code?



asking because if I activate LEVEL(aux1 to 1500PWM), it turns green, but nothing really happens, like model is in gyro mode still
only if I activate the baro with it(aux1 high), the model goes into level mode?

I'm not 100% sure,
need more testing, but seems to me like there is a bug in checkboxes maybe, flown 4 packs today and noticed that.
Before( in dev0504) switching from modes worked OK.

[Y.Mita]

are those checkboxes properly defined somewhere in code?



asking because if I activate LEVEL(aux1 to 1500PWM), it turns green, but nothing really happens, like model is in gyro mode still
only if I activate the baro with it(aux1 high), the model goes into level mode?

I'm not 100% sure,
need more testing, but seems to me like there is a bug in checkboxes maybe, flown 4 packs today and noticed that.
Before( in dev0504) switching from modes worked OK.

I think this is in MultiWii.ino around line number710,

Code: Select all

    for(i=0;i<CHECKBOXITEMS;i++) {   
      rcOptions[i] = (
       ((rcData[AUX1]<1300)    | (1300<rcData[AUX1] && rcData[AUX1]<1700)<<1 | (rcData[AUX1]>1700)<<2
       |(rcData[AUX2]<1300)<<3 | (1300<rcData[AUX2] && rcData[AUX2]<1700)<<4 | (rcData[AUX2]>1700)<<5
       |(rcData[AUX3]<1300)<<6 | (1300<rcData[AUX3] && rcData[AUX3]<1700)<<7 | (rcData[AUX3]>1700)<<8
       |(rcData[AUX4]<1300)<<9 | (1300<rcData[AUX4] && rcData[AUX4]<1700)<<10| (rcData[AUX4]>1700)<<11) & activate[i])>0;
    }

Finally I find my mistake about activate ACC and MAG from MultiWiiConf.
I need very long time push of "CALIB_ACC" or "CALIB_MAG" to activate caribration. Thanks all!

[EOSBandi]

Well, I did not touch that part of the code at all. Did you erase your EEPROM before uploading latest dev code ?

[nhadrian]

I have just tested the r26 code of EOSBandi in my Mini hexa with i2c GPS (Arduino nano + Locosys 10Hz GPS) and it just works awesome with even stock PIDs!
I didn't make any modifications except I reduced the loiter speed to 250 instead of 400.
After activatind the position hold, it stays in stable hoovering positions, in gusts there is only some small and slow overruns, and when activating the RTH, it starts to mode to home position immediatelly and slows down near home then calms down over start point...
Currently, during RTH, it rotates toe head of the copter to the startup direction, not to the home point. If I remember right, somewhere I read that it should turn towards to home point and when home is reached, it turns to the startup direction. EOSBandi, could this be activated via Defines???

There is only one issue!!! For me, the MAC version of the gui doesn't work, it doesn't starts (OSX Lion).
Could somebody who has a MAC help and compile working one?

BR
Adrian

PS.: This code just rocks!!!!!! really good job!!!!!!!!!! THANKS

[EOSBandi]

Currently, during RTH, it rotates toe head of the copter to the startup direction, not to the home point. If I remember right, somewhere I read that it should turn towards to home point and when home is reached, it turns to the startup direction. EOSBandi, could this be activated via Defines???

In the config.h file there are three defines

#define NAV_CONTROLS_HEADING true // copter points to the actual navigational bearing during RTH - this is the bearing corrected with cross track error
#define NAV_TAIL_FIRST false // true - copter comes in with tail first, false-head first

#define NAV_SET_TAKEOFF_HEADING true // true - when copter arrives to home position it rotates it's head to takeoff direction

[marbalon]

I've try to fly with this dev but it is quite nervous. I've checked in qui and when quad is on the table with motors disabled I have a lot of noise on gyro. When I enable MMGYRO fittering (btw. this is really good filtering for gyro!) it is ok, but I tried to find why and I think I found. I printed annex650_overrun_count in debug and this happens very often. So idea with 650us is not working is not working, I don't have Idea why it is 650us because if we want to read two samples we need to wait 1250us between two samples. i know first is read to late and maybe this is the problem....

I think we should change long i2c read for gyro, there is about 30bytes to read and it will hake about > 600us so it is too much for MWC idle - it don't like jitter for cycle time, or fix IMU calculation.

But yesterday I've tested in really windy evening and works! make huge circles but it is reeeeally windy evening.

Thanks for your job EOSBandi.

Edit.
Fly test with MMGyro not helps Still a loot of random wooble. My setup:

#define L3G4200D
#define ADXL345
#define HMC5883
#define MS561101BA
#define MS561101BA_ADDRESS 0xEC
#define I2C_GPS //I2C GPS and Navi modul
#define MMGYRO
#define MMGYROVECTORLENGHT 10

#undef VBAT
#undef LCD_CONF

[Y.Mita]

R27, MultiWiiConf application.windows32 seems broken.
The electrocardiogram says copter dead

But can use R26.

[EOSBandi]

R27, MultiWiiConf application.windows32 seems broken.
The electrocardiogram says copter dead

But can use R26.

Sorry r27 is compiled for 57600 baud...

[EOSBandi]

I've try to fly with this dev but it is quite nervous. I've checked in qui and when quad is on the table with motors disabled I have a lot of noise on gyro. When I enable MMGYRO fittering (btw. this is really good filtering for gyro!) it is ok, but I tried to find why and I think I found. I printed annex650_overrun_count in debug and this happens very often. So idea with 650us is not working is not working, I don't have Idea why it is 650us because if we want to read two samples we need to wait 1250us between two samples. i know first is read to late and maybe this is the problem....

I think we should change long i2c read for gyro, there is about 30bytes to read and it will hake about > 600us so it is too much for MWC idle - it don't like jitter for cycle time, or fix IMU calculation.

But yesterday I've tested in really windy evening and works! make huge circles but it is reeeeally windy evening.

Edit.
Fly test with MMGyro not helps Still a loot of random wooble. My setup:

#define L3G4200D
#define ADXL345
#define HMC5883
#define MS561101BA
#define MS561101BA_ADDRESS 0xEC
#define I2C_GPS //I2C GPS and Navi modul
#define MMGYRO
#define MMGYROVECTORLENGHT 10

#undef VBAT
#undef LCD_CONF

Well, it's interesting theory, but the GPS code is not in the annexCode loop, but in the main loop. Yes, it increases the cycle time, but that cycle time is taken into consideration for IMU calculations automatically. Just to make it sure, did you tried the "vanilia" MultiWii20120504 release ? Is it flies without wobbles with that version?

[EOSBandi]

Btw, if you don't need GPS coordinate and home distance and orientation display, just try to comment out those reads... for navigation
the I2C_GPS_NAV_BEARING, I2C_GPS_NAV_LAT and I2C_GPS_NAV_LON registers are enough. Thats about 8 byte (including status)

[dr.tom]

My vids of GPS working are here,
I'm so happy, thanks guys for your effort

viewtopic.php?f=9&t=1696

[guru_florida]

Hi Eosbandi,

Thanks for putting my status indicator patch in there. I forgot to tell you to set the LED STATUS pin13 to output in setup() though. It worked after I added:

Code: Select all

  
void setup() {
...
  // enable status LED pin
  pinMode(13, OUTPUT);   
}

Your code works on a Trimble Condor C2626, and your startup code in init() places the device in 10Hz and 115200 bps...Nice! Can't wait to try PH and RTH tomorrow!

GPS speed : yes
NMEA sentences config : no, will put there soon, but it's not really an issue
LED indicator: improved thanks to Guru_Florida
* 3 short flash at startup
* 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

[Y.Mita]

Hi Eosbandi,

Thanks for putting my status indicator patch in there. I forgot to tell you to set the LED STATUS pin13 to output in setup() though. It worked after I added:

Code: Select all

  
void setup() {
...
  // enable status LED pin
  pinMode(13, OUTPUT);   
}

Mr.guru_florida, Search "LEDPIN_PINMODE" in def.h, I think you can find what you want to add.

[guru_florida]

Hi Y.Mita,

I am talking about the LED status indicator for eosbandi's i2c-gps code, not the MultiWii code. There is no def.h in the 92c-gps code. The status indicator for i2c-gps indicates if the gps module has (1) not found satellites yet (2) in 2D gps lock (3) in 3D gps lock.

Mr.guru_florida, Search "LEDPIN_PINMODE" in def.h, I think you can find what you want to add.

[/quote]

[Y.Mita]

Hi Y.Mita,

I am talking about the LED status indicator for eosbandi's i2c-gps code, not the MultiWii code. There is no def.h in the 92c-gps code. The status indicator for i2c-gps indicates if the gps module has (1) not found satellites yet (2) in 2D gps lock (3) in 3D gps lock.

Mr.guru_florida, Search "LEDPIN_PINMODE" in def.h, I think you can find what you want to add.

[/quote]

Oh! I see. Excuse me!

[Y.Mita]

Today, I try R27 on my Hexa.
It's seems good controll, but need more PID modification?

First, normal flight. Battery out crash finish. Record by GoProHD, but very far and small.
http://youtu.be/V9Yr9woxH6I

Second, FPV flight. Again battery out crash finish. The mobiDroneOSD not finish installation to R27.
It's difficult to modify serial.ino to me.
http://youtu.be/O3hvxDnfGTo

Both flight, Return Home seems work well, but Position Hold seems not good, the control seems hard action when copter go far.
Is it correct action? or GPS problem? PID parameter problem?

Sorry my poor english!

[wilco1967]

Hi Eosbandi,

Thanks for putting my status indicator patch in there. I forgot to tell you to set the LED STATUS pin13 to output in setup() though. It worked after I added:

Code: Select all

  
void setup() {
...
  // enable status LED pin
  pinMode(13, OUTPUT);   
}

Hi guru_florida

Could you explain a little how to get that flashing working ?
Nothing is flashing here , on r27 of EOSBandi GPS code...

Do I need to disable VBAT code or so ?, or enable anything else...
I've tried adding pinMode(13, OUTPUT); to the end of void setup() { as you suggested (all the way down, just before the closing bracket), but that did not seem to change anything.
I'm on a Mega, with serial GPS.

Thanks... Wilco

[guru_florida]

This status indicator is only for the i2c-gps version, not for the MEGA. So in i2c-gps you have the GPS device connected to a dedicated Atmel chip, then this atmel chip wired to the MultiWii controller via the i2c port. So in this sense, you have two Atmel chips, 1 running MutliWii, and the other running the i2c-gps code. They communicate via i2c.

One benefit to this way is the gps code for NEMA sentence processing, waypoints (when it is finished), position hold and return to home (RTH) calculations are done on a separate processor than the multiwii processor keeping your multiwii cycle time down. So using i2c-gps on a MEGA still has it's positives. But gps on MEGA is more mature at this point (I believe this to be so, but maybe I dont know).

Could you explain a little how to get that flashing working ?
Nothing is flashing here , on r27 of EOSBandi GPS code...

Do I need to disable VBAT code or so ?, or enable anything else...
I've tried adding pinMode(13, OUTPUT); to the end of void setup() { as you suggested (all the way down, just before the closing bracket), but that did not seem to change anything.
I'm on a Mega, with serial GPS.

Thanks... Wilco

[EOSBandi]

But gps on MEGA is more mature at this point (I believe this to be so, but maybe I dont know).

Currently the gps code is identical for i2cgps and serial gps. So if you fly with atmega and a serial gps you use the same code that runs in the i2c gps.

[dr.tom]

are cycle times better on MEGA?

asking because I'm thinking about going to mega because promini has some limitation when used on hexa + 2 axis gimbal
(lower resolution and so... viewtopic.php?f=8&t=1619&p=13395#p13486 )
and mega board is so damn cheap , with navigatron as i2c gps unit, it's still a reasonable cost for a hobbyst.

viewtopic.php?f=6&t=1672

[guru_florida]

No the MEGA has the same 8bit atmel core at 16MHz. It just has a whopping lot more I/O like serial ports, PWM, multiple i2c and other peripherals. I think there is some porting of MultiWii to STM32 underway...not sure though.

4are cycle times better on MEGA?

asking because I'm thinking about going to mega because promini has some limitation when used on hexa + 2 axis gimbal
(lower resolution and so... viewtopic.php?f=8&t=1619&p=13395#p13486 )
and mega board is so damn cheap , with navigatron as i2c gps unit, it's still a reasonable cost for a hobbyst.

viewtopic.php?f=6&t=1672

[flyrobot]

But gps on MEGA is more mature at this point (I believe this to be so, but maybe I dont know).

Currently the gps code is identical for i2cgps and serial gps. So if you fly with atmega and a serial gps you use the same code that runs in the i2c gps.

Hi EOSBandi,

Is identical means the gps code on r10 gps-work is identical with r27 i2cgps ? Is the Serial GPS (r10 gps-work) is using Jason work on PID as i2cgps R27 ?

Thanks,
John

[EOSBandi]

There are some changes in the r27 version, but the default pids are shows that changes r10dev is obsolated now....

[Gaijin]

are cycle times better on MEGA?

asking because I'm thinking about going to mega because promini has some limitation when used on hexa + 2 axis gimbal
(lower resolution and so... viewtopic.php?f=8&t=1619&p=13395#p13486 )
and mega board is so damn cheap , with navigatron as i2c gps unit, it's still a reasonable cost for a hobbyst.

viewtopic.php?f=6&t=1672

I fly my Hexa with TimeCops (Dongs) far more powerful STM32 / MultiWii Based AfroFlight32 (Naze32) board and Flytron Serial GPS and has a 72mhz core speed 128K eeprom, It has a few issues with Hexa + camstab and the GPS implementation is quite basic at the moment but this is purely a software thing, I can't recommend it enough.

Decide for yourself http://www.rcgroups.com/forums/showthread.php?t=1595761

http://abusemark.com/store/index.php?main_page=product_info&cPath=1&products_id=30&zenid=61f35a88f20067a8c7ded5748d0a6139

http://www.flytron.com/osd-headtrackers/15-simpleosd-gps-module.html

[wilco1967]

This status indicator is only for the i2c-gps version, not for the MEGA.

Aha..... that explains a lot....

Thanks for clearing that up

[ApoC]

Yesterday i had a Testflight with my Hexa.

Mega, Drotek IMU with ITG3200, BMA180, MS5611, HMC5883 FMP4@38,4k@10Hz, Keda 20-26M, 8 x 4,5" Props, HK Blueseries 25A ESCs.

RTH is working, need some PID Tuning. But if i Check PosHold, my Copter goes crazy. Flying far away with full Throttle. Have to check the PIDs, i think. Okay.

But...

As another Member here, ive big Problems to steer my Copter. Its so sluggish like Low Ps. Had inc my P to 10 , but it seems there is a Problem with the ACC. In the GUI, it shows all okay. But in the Air, it feels like Gyro only mode. I have ACC, but seems to be a low value.

After that r27 Testflight,I tested the latest DEV, and the ACC works fine.

EOSBandi, as u said, u dont touched the Code for that, what can it be?

Btw: Can someone explain, how to convert my declination in Decimal? My DEC is: 2° 23' EAST positive

[dr.tom]

2+(23/60)=2.38

double check your checkboxes, unplug and then plug again your ftdi and battery, then 'READ' in gui again,
it helped to solve my acc problem, checkbox was activated first, but not correctly written.
then when I 'read' several times, it turned off. so I enabled it again, and copter flew just fine. hope it helps

[ApoC]

Thx Tom

But...i saw in EOSBandi´s Sketch: #define MAG_DECLINIATION 3.96f //For Budapest Hungary.
What is the "f"?

In the Sketch i saw too: //Convert the degree+minutes into decimal degree by ==> degree+minutes*(1/60)
Should be with my dec: 2+23*(1/60)
Thats not, what uve done. So i was confused.

The Checkboxes are on, so thats not the Problem. The ACC is active, but sluggish as hell. I tried a high P to check this, but the ACC is always sluggish. With the latest DEV the Copter is crispy as i know before.

[PatrikE]

i saw in EOSBandi´s Sketch: #define MAG_DECLINIATION 3.96f //For Budapest Hungary.
What is the "f"?

It´s a define for float value = decimal value.

[dr.tom]

Thx Tom
In the Sketch i saw too: //Convert the degree+minutes into decimal degree by ==> degree+minutes*(1/60)
Should be with my dec: 2+23*(1/60)
Thats not, what uve done. So i was confused.
.

it's mathematical equation for converting degrees and minutes to decimal number.

like when you say 1:30 PM, it means half two. but in decimal world 0.30 is not a half, right?

half two(or half past one if you like) is because 1+30(1/60)=1+30/60=1+0.5=1.5, half way from 1 till 2, right?

so your 2.23 => 2+23(1/60)=2+23/60=2+0,38=2.38

you JUST input 2.38 in code, not whole equation...

edit bandi's default for Hungary -> 3.96f -> into 2.38f