GPS integration

Gaza07 · Post by **Gaza07** » Wed Sep 28, 2011 12:08 pm

Ive got a flyduino mega v1.1 with 1280 chip and a fmp-04 gps module on serial 2, the gps works with the latest multiwii dev, my gps works on the NMEA protocol and the baud set to 38400bps

cheers
Gazza

cob · Post by **cob** » Sat Oct 01, 2011 11:34 pm

I've got GPS working on Blackvortex board with Atmel 2560. It is a NEO-6Q Ublox GPS receiver.
I just configured like this in config.h MWII 1.8 by MichalM_sk:

Code: Select all

/* Serial GPS
   only available on MEGA boards 
   if enabled, define here the Arduino Serial port number and the UART speed
   note: only the RX PIN is used, the GPS is not configured by multiwii
   the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices)
*/
#define GPS_SER
#define GPS_SERIAL Serial2 // should be Serial2 for flyduino v2 ... and it is for Blackvortex
#define GPS_BAUD   38400

So i get the GPS values displaying nicely on the GUI

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Tue Oct 04, 2011 8:47 pm

Hi there,

is there a version were I can configure my GPS with? The current gps.pde does not allow to send configuration messages to the GPS, so were to find one which can do this?

I'm working on a GPS BOB which I want to test with the MultiWii software. The module runs on 4800baud, sending NMEA messages. I want to increase the baud rate by sending the appropriate command.

Thanks for answering.
aBUGSworstnightmare

P.S. Here's a picture of my current dev (in progress). Sry, no details on the module at the moment :?:

dramida · Post by **dramida** » Tue Oct 04, 2011 10:30 pm

I am ready to test GPS HOLD function with my multiwii octocopter, when it will be available?

didlawowo69 · Post by **didlawowo69** » Tue Oct 11, 2011 2:30 pm

any news about gps integration ?
HK gps with OSD have a good resolution ?

whowe · Post by **whowe** » Mon Oct 24, 2011 6:35 am

I don't like the idea of soft serial. I believe it takes too much CPU resource to do the UART simulation.
When flying, serial 0 is not in use. So I think sharing serial 0 with PC is a good idea.

ziss_dm · Post by **ziss_dm** » Mon Oct 24, 2011 6:55 am

Hi

And what about i2c modules, like this one:
http://www.dealextreme.com/p/eb-365-gps ... pset-80045
http://www.chinesegps.com/downloads/EB- ... 010719.pdf

regards,
ziss_dm

jevermeister · Post by **jevermeister** » Tue Nov 01, 2011 10:12 pm

Hi,
Paul from Flyduino sent me a GPS bob to test with but I have some startup problems.
I use a FLyduino v2.1 and I am unsure which serial I have to use with the 20111029 DEV version,
I need to use the serial Port with RX3 TX3 written on it, because the bob does not have the smal gps connector yet.

Which serial port is that? Serial3?

Nils

ps.: GPS TX to Flyduino RX?

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Wed Nov 02, 2011 1:53 pm

Hi there,

Nils, as already mentioned you need to do a 1:1 connection between the GPS and the Flyduino Mega.
I hope to have the connector at hands by the end of the week --> send me a PN with your address and I will mail one.

Well, I couldn't locate in the code which UART is assigned to the GPS.
Config.h only lets you choose

Code: Select all

/* GPS     only available on MEGA boards (this might be possible on 328 based boards in the future)     if enabled, define here the Arduino Serial port number and the UART speed     note: only the RX PIN is used, the GPS is not configured by multiwii     the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices)  */  //#define GPS  //#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2  //#define GPS_BAUD   4800  //#define GPS_BAUD   9600

with def.h redefines this to

Code: Select all

Def.h only gives

[code]#if defined(GPS)    #define GPSPRESENT 1  #else    #define GPSPRESENT 0  #endif  [/code]

But, were in the code is GPSPRESENT and GPS_BAUD used so far???

MultiWii.pde only has

Code: Select all

  #if defined(GPS)      GPS_SERIAL.begin(GPS_BAUD);    #endif

but were is GPS_SERIAL assigned?

Rgds
aBUGSworstnightmare

Alexinparis · Post by **Alexinparis** » Thu Nov 03, 2011 2:21 pm

Hi,

GPSPRESENT is used to set a bit in a variable (GUI communication) to indicate the presence of the GPS.
GPS_BAUD and GPS_SERIAL are defined in config.h and used in multiwii.pde

aBUGSworstnightmare wrote:Hi there,

Nils, as already mentioned you need to do a 1:1 connection between the GPS and the Flyduino Mega.
I hope to have the connector at hands by the end of the week --> send me a PN with your address and I will mail one.

Well, I couldn't locate in the code which UART is assigned to the GPS.
Config.h only lets you choose
Code: Select all
/* GPS     only available on MEGA boards (this might be possible on 328 based boards in the future)     if enabled, define here the Arduino Serial port number and the UART speed     note: only the RX PIN is used, the GPS is not configured by multiwii     the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices)  */  //#define GPS  //#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2  //#define GPS_BAUD   4800  //#define GPS_BAUD   9600  
with def.h redefines this to
Code: Select all
Def.h only gives

[code]#if defined(GPS)    #define GPSPRESENT 1  #else    #define GPSPRESENT 0  #endif  [/code]
But, were in the code is GPSPRESENT and GPS_BAUD used so far???

MultiWii.pde only has
Code: Select all
  #if defined(GPS)      GPS_SERIAL.begin(GPS_BAUD);    #endif  
but were is GPS_SERIAL assigned?

Rgds
aBUGSworstnightmare

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Thu Nov 03, 2011 3:14 pm

Hi Alex,

yes, that's clear! But were can I see which hardware UART is associated to/with GPS_SERIAL label?

Rgds
aBUGSworstnightmare

Alexinparis wrote:Hi,

GPSPRESENT is used to set a bit in a variable (GUI communication) to indicate the presence of the GPS.
GPS_BAUD and GPS_SERIAL are defined in config.h and used in multiwii.pde
aBUGSworstnightmare wrote:Hi there,

Nils, as already mentioned you need to do a 1:1 connection between the GPS and the Flyduino Mega.
I hope to have the connector at hands by the end of the week --> send me a PN with your address and I will mail one.

Well, I couldn't locate in the code which UART is assigned to the GPS.
Config.h only lets you choose
Code: Select all
/* GPS     only available on MEGA boards (this might be possible on 328 based boards in the future)     if enabled, define here the Arduino Serial port number and the UART speed     note: only the RX PIN is used, the GPS is not configured by multiwii     the GPS must be configured to output NMEA sentences (which is generally the default conf for most GPS devices)  */  //#define GPS  //#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2  //#define GPS_BAUD   4800  //#define GPS_BAUD   9600  
with def.h redefines this to
Code: Select all
Def.h only gives

[code]#if defined(GPS)    #define GPSPRESENT 1  #else    #define GPSPRESENT 0  #endif  [/code]
But, were in the code is GPSPRESENT and GPS_BAUD used so far???

MultiWii.pde only has
Code: Select all
  #if defined(GPS)      GPS_SERIAL.begin(GPS_BAUD);    #endif  
but were is GPS_SERIAL assigned?

Rgds
aBUGSworstnightmare

JohnyGab · Post by **JohnyGab** » Thu Nov 10, 2011 7:20 am

Did you guy see any problem working the gps at 115200 on mega board?

jevermeister · Post by **jevermeister** » Thu Nov 10, 2011 7:38 am

I tested it with 115200 on my flyduino, the data looked good, but I have not flown it yet...

Nils

Ben_der · Post by **Ben_der** » Thu Nov 10, 2011 1:40 pm

What about piping the NMEA-Frame delivered by I2C GOS Devices with UART-mimic?
Maybe the Fastrax IT 430 ?

something like :

Code: Select all

const int WANTED_NUMBER = 67; // A usual GPGGA NMEA frame, 67 bytes including $;<CR>;<LF>
static uint8_t datastring [WANTED_NUMBER];
static uint32_t gpscycle;

Code: Select all

#if defined (SOME_GPS_I2C)
  getData();
  while (Wire.available()) {
  if (GPS_newFrame(datastring [WANTED_NUMBER])){
      if (GPS_update == 1) GPS_update = 0; 
      else GPS_update = 1;
      if (GPS_fix == 1) {
        if (GPS_fix_home == 0) {
          GPS_fix_home = 1;
          GPS_latitude_home = GPS_latitude;
          GPS_longitude_home = GPS_longitude;
        }
        GPS_distance(GPS_latitude_home,GPS_longitude_home,GPS_latitude,GPS_longitude, &GPS_distanceToHome, &GPS_directionToHome);
      }
    }
  }

&

Code: Select all

float getData ()
      {
      TWBR = ((16000000L / 400000L) - 16) / 2; 
      i2c_rep_start(0x60);                     //GPS sample I2c address
           for (byte i = 0; i < WANTED_NUMBER; i++)
           datastring [i] = i2c_readAck();
           datastring [WANTED_NUMBER]= i2c_readNak();            
           return datastring[WANTED_NUMBER];                 // maybe here we will need a terminating null 
             if ( (micros()-gpscycle )  < 250000 );    
                 gpscycle = micros();             //250ms = 4Hz refresh;
             getData();                                          
      }

roundabout...not tested..waiting for module but will have to switch with a I2C PCA.. least problem i think...

dialfonzo · Post by **dialfonzo** » Sun Nov 20, 2011 3:22 pm

Hi All,

I have hook a GPS to my Mega board yesterday.

Activate the code in config.h

Code: Select all

#define GPS
#define GPS_SERIAL Serial3 // should be Serial2 for flyduino v2
#define GPS_BAUD   4800

The GPS look to work since the GUI tell me that i have setellites...
Picture of GUI
http://static.rcgroups.net/forums/attachments/1/7/6/6/8/9/a4427740-182-MultiWii%20-%20Arduino%20Mega%201280%20-%20GPS.png

I wonder how do i know if it work.. or if i have position data ?

jevermeister · Post by **jevermeister** » Sun Nov 20, 2011 3:47 pm

If you have satellites: It works.

kataventos · Post by **kataventos** » Wed Nov 30, 2011 5:28 pm

Hi, is there any news about promini integration? I would like to have one on my Paris v4 board!

dramida · Post by **dramida** » Fri Dec 02, 2011 9:24 am

Hi guys, I need GPS Position hold for making aerial panoramas. Here you can see my albums.

http://caseta.ro/html/fotografie_aeriana.html

dialfonzo · Post by **dialfonzo** » Fri Dec 02, 2011 1:14 pm

I need a Ferrari...!

kataventos · Post by **kataventos** » Fri Dec 02, 2011 1:38 pm

dialfonzo wrote:I need a Ferrari...!

First the position hold then the Ferrari, one thing at a time!

dialfonzo · Post by **dialfonzo** » Fri Dec 02, 2011 10:25 pm

kataventos wrote:
dialfonzo wrote:I need a Ferrari...!

First the position hold then the Ferrari, one thing at a time!

LOL..

dramida · Post by **dramida** » Tue Dec 20, 2011 11:47 pm

I started dreaming at GPS position hold for a while. Please Santa, upload the CODE!

Alexinparis · Post by **Alexinparis** » Wed Dec 21, 2011 12:26 am

Hi,
I uploaded yesterday a dev snapshot with some GPS dev.
The GPS return to home function is coded.
Not yet tested, but in progress.

jevermeister · Post by **jevermeister** » Wed Dec 21, 2011 12:57 am

I like!!
Will test it asap

Noctaro · Post by **Noctaro** » Wed Dec 21, 2011 8:59 am

AHRG!
Great! Are there any wiring howtos for gps modules around? Am i limited to some special hardware?

greetings
Noctaro

kataventos · Post by **kataventos** » Wed Dec 21, 2011 10:43 am

Hi Alex,
great! Any news on promini? I think that exist some kind of "breakout" board that is able to convert serial to i2C! is that it? where can I find this and does it realy work?

Cheers,
Henrique

PatrikE · Post by **PatrikE** » Wed Dec 21, 2011 4:04 pm

Found a little Typo
Could not get it to work with serialport 3

Code: Select all

   while (SerialAvailable(2)) {
     if (GPS_newFrame(SerialRead(2))) {

Should be if you want to switch port in config.

Code: Select all

   while (SerialAvailable(GPS_SERIAL)) {
     if (GPS_newFrame(SerialRead(GPS_SERIAL))) {

Now it's running smooth on the table.
Will test when it's not snowing so much..

/Patrik

mbrak · Post by **mbrak** » Wed Dec 21, 2011 6:01 pm

hi

a small question

is it possible to assign an output-pin if having a gps-link?
i think it is not bad to have a led when there are enough satelites.

Alexinparis · Post by **Alexinparis** » Wed Dec 21, 2011 8:42 pm

Hi,

Currently, there is a change of the status LED when a fix is obtained
When the motors are not armed, the status LED should stay off.
Once the fix is ok, there is a specific blink pattern.

dramida · Post by **dramida** » Thu Dec 22, 2011 4:19 am

Today I just crushed my octo and it will take me some time to fix it, i am sorry that i can't do the tests.

Alexinparis · Post by **Alexinparis** » Thu Dec 22, 2011 12:24 pm

Hi,

Just some precisions about the current GPS dev code:

1) hardware setup:

An arduino mega (might change in the future for a promini, but not yet) with the GPS connected on serial port 2 (customizable, but with the typo correction just mentionned by PatrikE). I'm currently using the flyduino MEGA.

You must configure the right baud speed of the GPS port according to your GPS device. (#define GPS + #define GPS_SERIAL 2 + #define GPS_BAUD 115200)

You need a NMEA GPS compatible (most serial GPS are compatible). Currently multiwii does not configure the GPS device (will change in the future). So your GPS device must be already configured to output these frames. A 5 or 10Hz is preferable. This update rate is not configurable inside multiwii, multiwii takes what it receives. I'm now using the 10Hz FMP04 GPS with the GPS BOB from flyduino.

All the sensors GYRO+ACC+MAG are mandatory. Your multi must be perfectly tuned in level and heading (mag) mode. Your mag direction should not be altered by running motors (this point is very important). Your MAG arrow must point the north direction.

Baro is not mandatory, but a working baro config in preferable.

2) visualization

If the GPS is correctly connected and configured. You should see the GPS blinking in the GUI (around the grey rosace N/S/E/W in the GUI) according to its update rate.

A specific Status LED blink pattern occurs when motors are disarmed and once a fix is ok.

Once a fix is ok, you should see the number of satellites and the distance to the first fix position (home) in the GUI.

3) activating the GPS

The GPS must be activated (via checkbox and AUX configuration) only if a fix is ok. The home will be set with the first fix.

The GPS can be only activated if level mode if also activated. (MAG mode activation or BARO mode activation are not mandatory)

The current implementation only supports Return To Home function (PH will be easy to add)

Once activated, the GPS will rely on 3 parameters to work
distance to the target point (calculation obtained from GPS device)
absolute direction to the target point (calculation obtained from GPS device)
heading direction (calculation obtained from MAG+ACC device)

The target point distance is used to determine an angle inclination.
A PID has been added to the GUI, but it's not currently a real PID.
P is used to tune the proportion of inclination regarding the distance to the target point.
I is not used
D is used to limit the max inclination

The combination of direction to the target point+heading direction is used to apply a mix on the motors to follow the right direction.

mbrak · Post by **mbrak** » Thu Dec 22, 2011 2:27 pm

Thanks Alex for this masterpice of software!

My copter has GPS now and it seems to work fine. (flyduino Mega with FMP04 GPS from Paul)

Will it be possible in future to reset the home-point an set a new one without power down the copter?

PatrikE · Post by **PatrikE** » Thu Dec 22, 2011 6:19 pm

mbrak wrote:Will it be possible in future to reset the home-point an set a new one without power down the copter?

It should be easy to do it now to..

Code: Select all

  #if defined(GPS)
    if ( (GPSModeHome == 1) && ( GPS_fix_home == 1)) {
      float radDiff = (GPS_directionToHome-heading) * 0.0174533f;
      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
    } else {
      GPS_angle[ROLL]  = 0;
      GPS_angle[PITCH] = 0;
      GPS_fix_home =0
    }
  #endif

If you set GPS_fix_home =0 when GPSModeHome isn't active it vill take a new position and use it as home when GPSModeHome is Reactivated.

dramida · Post by **dramida** » Mon Dec 26, 2011 7:47 pm

I tested R426 software with GPS return to home.

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

Mag was calibrated and checked in GUI, level mode working and GPS fix available because status led was blinking fast.
When activated GPS return to home, i programmed to activate the buzzer .

The results are not conclusive, i think something gone wrong because the quad is not going in right direction, but also CF mode was not working. Strange because i calibrated and checked the mag and on previous version, one day before, the CF mode was working well.
Also i observed short bursts of yaw when mag was active in Head hold.

Alexinparis · Post by **Alexinparis** » Tue Dec 27, 2011 7:31 pm

Hi dramida,

The CF (HeadFree) mode should work perfectly before testing the GPS, because the GPS will rely on the magnetic orientation.
Your mag is working well on the bench, but could you confirm it works also when the motors are running ?

I suspect some magnetic noise coming from ESCs or motors, and leading to a wrong heading information.

mbrak · Post by **mbrak** » Tue Dec 27, 2011 7:57 pm

hi

i tested the dev 20111220 today. the mag was well calibrated and the gui values good. the hf-mode was not working correctly! at yaw angles<90 degrees it worked fine but >90 degrees to the start orientation the copter was flying in other directions but not in that, i would like to have him.

after that i did not test gps.

what can we do in case of magnetic interference? any solutions?

dramida · Post by **dramida** » Tue Dec 27, 2011 9:20 pm

My tests were faulty because magnetometer goes crazy when motors are over 50% or more. I saw this behaviour on GUI wile holding in my hand with engines powered. So until the mag stays on position at any power, i cannot conclude about soft.

mbrak · Post by **mbrak** » Wed Dec 28, 2011 5:36 pm

Hi

my tests have the same result as that of dramida. MAG is going crazy over all 3 axis as soon as more like hover-throttle(aprox. 40%) is present.
motors : T-Motor2216/KV900 10x4.7 CF with robbe roxxy bl820 ESC

i increased the space between IMU (10 DOF AllinOne / Ebay from CSG_EU) and frame with powerlines (flyduino quadframe) up to 15mm. next test will show the result.

After increasing space the MAG is now more softly! much better than before!

Will do some testing tomorrow if there is no rain.....

UndCon · Post by **UndCon** » Wed Dec 28, 2011 6:28 pm

Can you try shielding things to verify it is the motors and mot ESC's that causes MAG errors?

//UndCon

mbrak · Post by **mbrak** » Wed Dec 28, 2011 7:36 pm

UndCon wrote:Can you try shielding things to verify it is the motors and mot ESC's that causes MAG errors?

//UndCon

Magnetic shielding you mean? what exactly do you think?

I should try to shield the electromagnetic compatibility of the ESC? how?

dramida · Post by **dramida** » Thu Dec 29, 2011 2:11 am

Today i repeated the tests with magnetometer elevated from its board position at about 10 cm.
The results you see here: http://www.youtube.com/watch?v=N38oGaBj7Xs

Alexinparis · Post by **Alexinparis** » Fri Dec 30, 2011 11:59 am

Hi dramida,

We can see in your video that Headfree mode does not work as expected. (sometime yes, sometime no)
I think we should work on this issue before trying to activate the GPS.
Does the mag arrow indicate the north ?
Headfree was reporting to work on some setup, it's maybe a version problem ?

If you want to test the GPS without solving this issue, I can maybe make a specific version assuming you activate the GPS only when the nose of your quad points the north.

dramida · Post by **dramida** » Sat Dec 31, 2011 5:56 pm

Hi Alex, now i can fly in care free mode with R426 code, same code i used in previous two tests. All i did was to elevate the mag 5883L at about 17 Cm above power distribution conductors. This is the advantage of individual sensors and a DIY TTH board.

Curiously, i tried to activate gps return to home last flight but i couldn't get the GPS FIX light. In the GUI the mag circle is flashing as it receives data from gps. I have to investigate further. I'll keep you updated.

Happy new year!

/Mihai

mbrak · Post by **mbrak** » Sun Jan 01, 2012 4:21 pm

hi

that sounds good dramida. but i don't think it is a practicable solution to elevate the mag for about 17cm. i have the same problems with my mag and i can't elevate the sensor because i have all sensors on the imu board.

the microcopter has the same function called headfree. and they solved it without evelate the mag i think! the microcopter board would produce the same amount of magnetic interference as the multiwii board. or not?

#alex could we filter the inputs of the mag to make it more smooth? maybe the same procedure as with the gyro?

EOSBandi · Post by **EOSBandi** » Sun Jan 01, 2012 4:43 pm

Hi !

Today I tested the GPS RTH mode. And I can confirm that it's working...
There is one bug in the code which must be corrected.. the orientation of the Pitch and Roll corrections are wrong, but changing the following line fixes it...

In MultiWii.ino change this

Code: Select all

  errorAngle = constrain(2*rcCommand[axis] + GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here

to this

Code: Select all

  errorAngle = constrain(2*rcCommand[axis] - GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here

The GPS I used is a MTK chipset LS20033 set for 5Hz update rate at 115200 bps.
Gyro : ITG3205, Acc: BMA150 with 8G setting, Mag: HMC5883L, Baro: BMP085
(Just to note, RTH tests were done in Alt hold mode.... which is working perfectly...)

Things to improve :
1. DO not trust the position when GPS is got its fix, move home position setting to an aux switch or store home position when arming. (The received position could change significantly after the first fix)
(for a quick fix I added AUX4 high position to store home position.)
change this line

Code: Select all

if (GPS_fix_home == 0) {

to this

Code: Select all

if (rcData[AUX4]>1800) {

2. Add magnetic inclination to the mag hold calculations, this will reduce the diameter of the circles around home position. (will do that)
3. Add a PID contoller to the gps calculations, so it will not overshoot when coming home from long distances with max RTH speed. (will try but, perhaps a little help needed)
4. Just for showing off, turn the copter's head towards the home position when RTH (will do that)

Here is the video of the test...http://www.youtube.com/watch?v=pJJKG6uWqv4

Alexinparis · Post by **Alexinparis** » Sun Jan 01, 2012 5:33 pm

waouh !
Thank you so much for this feedback

It's a nice way to begin the year.

1) I think a small timer once the first fix is ok should be added, or maybe some averaging on 10 or 20 positions.
2) and 3) To you think the circle are caused by heading inaccuracy ? I would say it's more due to the GPS correction which is currently very simple.
Once the target GPS position is achieved, the multi will continue to drift a little with the current implementation.
A full PID could maybe do the job.
4) for inflight visual debugging purpose ?

EOSBandi · Post by **EOSBandi** » Sun Jan 01, 2012 5:56 pm

Alexinparis wrote:waouh !
Thank you so much for this feedback
It's a nice way to begin the year.

1) I think a small timer once the first fix is ok should be added, or maybe some averaging on 10 or 20 positions.
2) and 3) To you think the circle are caused by heading inaccuracy ? I would say it's more due to the GPS correction which is currently very simple.
Once the target GPS position is achieved, the multi will continue to drift a little with the current implementation.
A full PID could maybe do the job.
4) for inflight visual debugging purpose ?

Hi Alex,
First, Happy New Year to You !

1. Timer is OK, I just got the idea from the arducopter, which sets the home position when copter is armed..., but a timer will also do the trick. Averaging is not a good idea, perhaps it's worth to wait for 3D fix and not for 2D fix. (Checking GSA sentences from gps)

2,3. I checked the heading inaccuracy and it definitely there, again experiences from arducopter, without accurate mag orientation you will got circles in pos hold... will try to implement it and post the results... I think the current gps pos correction is simple but very elegant. A PID loop could improve it, but don't overengineer it..

4. Visual debugging, and for coolness factor.. it's cool and frightening when you flip a switch and the copter turns to a new direction and starts fly there. (This will be a perfect function for waypoint navigation, which is the next logical step.)

Regards,
Andras

mbrak · Post by **mbrak** » Sun Jan 01, 2012 6:12 pm

hi Andras

what imu or mag sensor do you use?
do you have flat mag-lines in gui when power on motors >30%
what esc and motors do you use?

thx michael

jevermeister · Post by **jevermeister** » Sun Jan 01, 2012 6:22 pm

Hi all,
good to hear about the gps solutions taking shape :-)

.

I am stuck with my shitty bma020 and my mag.

I have the z problem so I ordered a bma180 and hopefully this will fix the problem with AccZ.

The more serious problem in my opinion is the faulty behavior of my mag (HMC5883) I monted it next to the Gyro beneath the Flyduino board ontop of my centerplate.
Beneath the centerplate I mounted the escs the lipo and beneath the lipo there is the power distribution.
I have exactly the same problem dramida mentioned.
I first noticed that when I tried some altitude hold and direction hold, when I throttle up the copter yaws like crazy.
I am still not sure what is causing this EMV from the wires LIPO->ESC or ESC->Motor or is there a frequency in the whole system that influences the mag?

I will try to shield the mag with a faraday cage.
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

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

Hi !
It's a bunch of self made blobs... as I wrote. ITG3205 from a WMP clone (Wired directly) BMA150 salvaged from a broken smartphone. (It's basically the same as the BMA020), a BMP085 baro and a HMC5883L wired on a selfmade test board. FC is a selfmade ATMega2560 board, which is nothing more than a ArduinoMega but on a 10x10 board. Mag-lines are flat even at full throttle.
ESC's are Hobbyking Blue Series 20A, flashed with ziss_dm magnificant firmware (200step-normal pwm) motors are Dt750 with replaced high quality bearings. Prpps are GWS 3 blade 10x6.

Frame is based on the tricopter v2.5 from rcexplorer.se http://rcexplorer.se/projects/tricopter ... erv25.html the only significant difference, that I did not remove the copper foil from the PCB materials used for the frame. Since all power wires are routed between the two base plates, this provide a good shiled from emf interference. ESC's are attached to the arms, in a safe distance from magnetometer.

The GPS is enclosed in a plastic blob, and elevated about 15cm on a carbon fiber rod, and connected to the FC via a shielded cable).

Regards,
Bandi