GPS integration

EOSBandi · Post by **EOSBandi** » Mon Dec 10, 2012 12:10 pm

Crashpilot1000 wrote:@EOS Bandi:
Do you have any documentation for the AXN1.51_2722_3329_384.1151100.5.bin? I can't find it. It would be interesting to know what is turned on after switching to binary mode by default. From what i see here SBAS and 10HZ in binary is no-go: viewtopic.php?f=6&t=1881&start=10#p19325.

So long
Kraut Rob

It is unknown. the AXN 1.51 is a customized firmware and the settings depends on how this form (http://www.trenz-electronic.de/fileadmi ... 120828.pdf) was filled out by the company who ordered this customization. GlobalTek unfortunately does not disclose details of customized firmwares

Crashpilot1000 · Post by **Crashpilot1000** » Mon Dec 10, 2012 6:15 pm

@EOS Bandi: I understand.
Sorry to bother you again but do you think the mysterious AXN1.51_2722_3329_384.1151100.5.bin ("Sergey")is better than the original DIY Drones 1.6 (AXN1.30_2389_3329_384.1151100.1_v16.bin "3DRobotics")? At least for the 3drobotics fw the correct initialisation sequence is known.

So long

Kraut Rob

EOSBandi · Post by **EOSBandi** » Mon Dec 10, 2012 7:57 pm

Crashpilot1000 wrote:@EOS Bandi: I understand.
Sorry to bother you again but do you think the mysterious AXN1.51_2722_3329_384.1151100.5.bin ("Sergey")is better than the original DIY Drones 1.6 (AXN1.30_2389_3329_384.1151100.1_v16.bin "3DRobotics")? At least for the 3drobotics fw the correct initialisation sequence is known.

So long

Kraut Rob

According to this faq: http://forum.trenz-electronic.de/index. ... a49ffd8b27
With the firmware update from version AXN1.30 to AXN1.50, the navigation performance has been improved in terms of accuracy and consistency for the following unfavorable conditions:
•weak signal condition under a viaduct
•weak signal condition in deep urban areas
•weak signal condition in dense forest
•static drifting reduction

dramida · Post by **dramida** » Mon Dec 10, 2012 10:09 pm

Hello EosBandi, please bring Santa earlier this year and write a single way-point (x-y-alt) implementation with WinGui.

albertoLG · Post by **albertoLG** » Tue Dec 11, 2012 6:47 am

EOSBandi wrote:
Crashpilot1000 wrote:@EOS Bandi: I understand.
Sorry to bother you again but do you think the mysterious AXN1.51_2722_3329_384.1151100.5.bin ("Sergey")is better than the original DIY Drones 1.6 (AXN1.30_2389_3329_384.1151100.1_v16.bin "3DRobotics")? At least for the 3drobotics fw the correct initialisation sequence is known.

So long

Kraut Rob

According to this faq: http://forum.trenz-electronic.de/index. ... a49ffd8b27
......
•static drifting reduction

I have a strange problem with my GPS module, MT3329, and I think is because of this.... I can read the coordinates, then move(walk) 10 meters away and the coords are still the same, then after some more time they will change, with my gps's phone they change as soon as i move... probably is a feature of this firmware, but I think in the position hold it can give some problems if the multirotor move slow from his position and the multiwii reading the coords think is still in the same position, am I wrong? anyway I ordered an U-BLOX module, the CN-06 V2, hope will be better

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 11, 2012 10:22 am

@EOS Bandi: Thank you for your reply and the link!

@Alberto: Difficult to say, because your phone could do a integration of gps data with the imu data to detect movement and direction. But the FW 1.51 feature "static drifting reduction" could be a problem for PH. Without insight into the function it is difficult to say. I just did GPS tests with static copter (gps-difficult area) and with the FW 1.51 the Position is reported more precise and it gets more sats in a shorter time. Could you do a comparison with the 3drobotics FW in motion (before your ublox arrives

)??

So long
Kraut Rob

albertoLG · Post by **albertoLG** » Tue Dec 11, 2012 10:30 am

Crashpilot1000 wrote:@EOS Bandi: Thank you for your reply and the link!

@Alberto: Difficult to say, because your phone could do a integration of gps data with the imu data to detect movement and direction. But the FW 1.51 feature "static drifting reduction" could be a problem for PH. Without insight into the function it is difficult to say. I just did GPS tests with static copter (gps-difficult area) and with the FW 1.51 the Position is reported more precise and it gets more sats in a shorter time. Could you do a comparison with the 3drobotics FW in motion (before your ublox arrives )??

So long
Kraut Rob

i'll reflash my gps with diydrones firmware AXN1.30_2389_3329_384.1151100.1_v16.bin is this right? in a couple of hours i'll report back

edit:
flashed, max refresh rate is 5Hz with this firmware, need to wait for my notebook to test outside and see if changed something :geek:

albertoLG · Post by **albertoLG** » Tue Dec 11, 2012 11:01 am

Ok, tested it, 8/9 satellites, nothing has changed.... still don't update the data after 10/20 meters, in the car it works fine if moving... shelved it and waiting for the U-BLOX to arrive and do more tests

EOSBandi · Post by **EOSBandi** » Tue Dec 11, 2012 11:10 am

albertoLG wrote:Ok, tested it, 8/9 satellites, nothing has changed.... still don't update the data after 10/20 meters, in the car it works fine if moving... shelved it and waiting for the U-BLOX to arrive and do more tests

It seems that the nav threshold setting is active on your gps. Check it with $PMTK447*35<CR><LF> is must be 0.0
Regards,
EOS

albertoLG · Post by **albertoLG** » Tue Dec 11, 2012 12:03 pm

EOSBandi wrote:
albertoLG wrote:Ok, tested it, 8/9 satellites, nothing has changed.... still don't update the data after 10/20 meters, in the car it works fine if moving... shelved it and waiting for the U-BLOX to arrive and do more tests

It seems that the nav threshold setting is active on your gps. Check it with $PMTK447*35<CR><LF> is must be 0.0
Regards,
EOS

THAT FIXED IT!!

I modified the GPS.INO adding this line

previous

Code: Select all

// at this point we have GPS working at selected (via #define GPS_BAUD) baudrate
      SerialOpen(GPS_SERIAL,GPS_BAUD);
      SerialGpsPrint(PSTR("$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n")); // only GGA and RMC sentence
      SerialGpsPrint(PSTR("$PMTK220,200*2C\r\n"));           // 5 Hz update rate

new

Code: Select all

// at this point we have GPS working at selected (via #define GPS_BAUD) baudrate
      SerialOpen(GPS_SERIAL,GPS_BAUD);
      SerialGpsPrint(PSTR("$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n")); // only GGA and RMC sentence
      SerialGpsPrint(PSTR("$PMTK220,200*2C\r\n"));           // 5 Hz update rate
      SerialGpsPrint(PSTR("$PMTK397,0.2*3F\r\n"));           // Set threshold to 0.2

now it update the coordinates at every little movement.... thanks EOSBandi

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 11, 2012 1:02 pm

@EOS Bandi: Yes! Thank you for this info!
I did nearly the same thing like albertoLG with the same good result on 3drobotics FW(1.6). But i set the threshold to 0 with the command:

Code: Select all

  #define MTK_NAVTHRES_OFF      "$PMTK397,0*23\r\n"  // Turn off Navthreshold for sure, so every GPS is send

So long

Kraut Rob

albertoLG · Post by **albertoLG** » Tue Dec 11, 2012 1:25 pm

Crashpilot1000 wrote:@EOS Bandi: Yes! Thank you for this info!
I did nearly the same thing like albertoLG with the same good result on 3drobotics FW(1.6). But i set the threshold to 0 with the command:
Code: Select all
  #define MTK_NAVTHRES_OFF      "$PMTK397,0*23\r\n"  // Turn off Navthreshold for sure, so every GPS is send
So long

Kraut Rob

hhmm.. shouldn't be

Code: Select all

$PMTK397,0*3F\r\n

to zero threshold or I'm wrong?

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 11, 2012 1:31 pm

Nope! The number after " * " is the checksum. You can calculate it here: http://www.hhhh.org/wiml/proj/nmeaxor.html

albertoLG · Post by **albertoLG** » Tue Dec 11, 2012 1:36 pm

Crashpilot1000 wrote:Nope! The number after " * " is the checksum. You can calculate it here: http://www.hhhh.org/wiml/proj/nmeaxor.html

sorry but it gives me 3F as checksum in the link you posted, and in the GlobalTop PMTK command packet document http://www.adafruit.com/datasheets/PMTK_A08.pdf , page 14, the samples is

Code: Select all

$PMTK397,0.2*3F<CR><LF> (threshold to 0.2ms)?
$PMTK397,2.0*3F<CR><LF> (threshold to 2ms)?

so the 3F is always there

edit:
you are right, sorry

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 11, 2012 2:46 pm

@EOS Bandi:
I took your code http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q= and did my crazy changes to it. I want to post it "as it is" perhaps it is of some use perhaps an example of how not to do it...
The changes:
I put the multiwii serial part into your code, eliminating the arduino "Serial.begin" etc stuff. The inbuffer is set to 256 Bytes. The whole serial part is modular under the Tab "Serial". I implemented an experimental spikefilter wich i documented here (http://diydrones.com/forum/topics/perha ... pikefilter) it can be turned on/off in the config.h with #define SPIKEFILTER. It sits after the gps data aquisition and before your moving average filter. While playing around with your moving averagefilter i found it useful to be able to turn it off without recompiling the whole mwii code (since your filter is only recommended for 10Hz NMEA data). So i added "#define AFALWAYSOFF" in the config.h to turn off the averagefilter. Than i fiddled around to eliminate the sudden breakouts of the copter during PH etc. So far i couldn't test it because of the wheather. Here is what i did: In case of low sat count (default 5) the nav parameters are reset. In that case i set last_longitude and last_latitude to zero to force the velocity calculation to reset. I am not sure if it is done already. The next thing i did was to make the minimal sat number for gps functions accessible in the config.h "#define MINSAT 7" i set it to 7 because with 5 satellites i see errors in th 30+m range. So no breakouts due to wacky gps positions. I set this nmea parsing variable to unit_32 - i know that a positive effect is doubtful but it can not harm anyway...
Than i replaced the DIY Drones binary protocol parser with my own. Because i had it already done and wanted to put it to use:). I changed the initialization of MTK (binary mode) to the original apm sequence. I stumbled upon a crazy WAAS_ON sequence (http://diydrones.com/forum/topics/myste ... k-common-h). I let it in, perhaps it's some undocumented 3drobotics magic code. Currently i set the MTK to this:
Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

The config.h looks like this now (example config for mtk in binary and experimental spikefilter):

Code: Select all

// *********************************** GENERAL GPS TYPE
//#define NMEA
//#define UBLOX
#define MTK                            // Defined: Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

// *********************************** GENERAL FILTER VALUES
#define SPIKEFILTER                    // Turn on experimental spikefilter
#define AFALWAYSOFF                    // Always turn off the moving average filter("AF"), doesn't matter whats in mwii config.h defined

// *********************************** GENERAL GPS VALUES
#define MINSAT 7                       // 5 is default minimal number of sats for gps functions, i found valid data with 7 sats

// *********************************** MTK BINARY SPECIAL (FW:AXN1.51_2722_3329_384.1151100.5.bin)
//#define MTK10HZ                      // According to this post: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1881&start=10#p19325
                                       // when enabeling 10HZ in mtk binary mode, you will loose SBAS functionality!! That will just work at 5Hz (default).

So long
Kraut Rob

EOSBandi · Post by **EOSBandi** » Tue Dec 11, 2012 2:57 pm

Crashpilot1000 wrote:@EOS Bandi:
I took your code http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q= and did my crazy changes to it. I want to post it "as it is" perhaps it is of some use perhaps an example of how not to do it...
The changes:
I put the multiwii serial part into your code, eliminating the arduino "Serial.begin" etc stuff. The inbuffer is set to 256 Bytes. The whole serial part is modular under the Tab "Serial". I implemented an experimental spikefilter wich i documented here (http://diydrones.com/forum/topics/perha ... pikefilter) it can be turned on/off in the config.h with #define SPIKEFILTER. It sits after the gps data aquisition and before your moving average filter. While playing around with your moving averagefilter i found it useful to be able to turn it off without recompiling the whole mwii code (since your filter is only recommended for 10Hz NMEA data). So i added "#define AFALWAYSOFF" in the config.h to turn off the averagefilter. Than i fiddled around to eliminate the sudden breakouts of the copter during PH etc. So far i couldn't test it because of the wheather. Here is what i did: In case of low sat count (default 5) the nav parameters are reset. In that case i set last_longitude and last_latitude to zero to force the velocity calculation to reset. I am not sure if it is done already. The next thing i did was to make the minimal sat number for gps functions accessible in the config.h "#define MINSAT 7" i set it to 7 because with 5 satellites i see errors in th 30+m range. So no breakouts due to wacky gps positions. I set this nmea parsing variable to unit_32 - i know that a positive effect is doubtful but it can not harm anyway...
Than i replaced the DIY Drones binary protocol parser with my own. Because i had it already done and wanted to put it to use:). I changed the initialization of MTK (binary mode) to the original apm sequence. I stumbled upon a crazy WAAS_ON sequence (http://diydrones.com/forum/topics/myste ... k-common-h). I let it in, perhaps it's some undocumented 3drobotics magic code. Currently i set the MTK to this:
Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

The config.h looks like this now (example config for mtk in binary and experimental spikefilter):
Code: Select all
// *********************************** GENERAL GPS TYPE
//#define NMEA
//#define UBLOX
#define MTK                            // Defined: Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

// *********************************** GENERAL FILTER VALUES
#define SPIKEFILTER                    // Turn on experimental spikefilter
#define AFALWAYSOFF                    // Always turn off the moving average filter("AF"), doesn't matter whats in mwii config.h defined

// *********************************** GENERAL GPS VALUES
#define MINSAT 7                       // 5 is default minimal number of sats for gps functions, i found valid data with 7 sats

// *********************************** MTK BINARY SPECIAL (FW:AXN1.51_2722_3329_384.1151100.5.bin)
//#define MTK10HZ                      // According to this post: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1881&start=10#p19325
                                       // when enabeling 10HZ in mtk binary mode, you will loose SBAS functionality!! That will just work at 5Hz (default).
So long
Kraut Rob

I did not reviewed it yet, but what I know that $PSRF sentences are for the SIRF chipset, so the "mystery" init sequence very likely some leftover from transferring code segments between gps implementations. MTK chipsets definitely will not understand that.

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 11, 2012 7:26 pm

Ahh, thats why i couldn't find the command in the MTK reference. That might solve the PH issues with MTK and APM. I corrected the APM libs and posted them here http://diydrones.com/forum/topics/myste ... k-common-h.
Thanks a lot!

Cheers

Kraut
Rob

wilco1967 · Post by **wilco1967** » Tue Dec 11, 2012 8:04 pm

EOSBandi wrote:
albertoLG wrote:Ok, tested it, 8/9 satellites, nothing has changed.... still don't update the data after 10/20 meters, in the car it works fine if moving... shelved it and waiting for the U-BLOX to arrive and do more tests

It seems that the nav threshold setting is active on your gps. Check it with $PMTK447*35<CR><LF> is must be 0.0
Regards,
EOS

I suspected this could possibly be my problem as well..... Also noticed the GPS update seems slugish when walking long time ago.... (can see with FrSky telemetry from MWii when walking around.... could also be it does not update when not armed

)

So I connected my 3329 to realterm..... set it to 10 seconds of logging
then I send $PMTK447*35 with +CR and +LF ticked..... (is this correct) ?

Between all the data received, it seems I get a extra line $PMTK527,0.00*00 for each time I send the $PMTK447*35<CR><LF> string. This line never shows up if I dont send.....

Is this the 0.0 response I should be looking for?... So 0.0 means I should not have this problem ?
If I understand this correct http://forum.trenz-electronic.de/index.php?topic=44.0, I guess this is not my issue after all :cry:

My flyduino has a broken serial port... the Tx is not connected, only RX, so cannot use the INIT_MTK_GPS init script currently

(still need to repair).

Crashpilot1000 · Post by **Crashpilot1000** » Tue Dec 11, 2012 10:15 pm

@wilco67: "..So 0.0 means I should not have this problem..." You are right, $PMTK527,0.00*00 is the expected answer. Your assumptions are correct.

Cheers
Kraut Rob

wilco1967 · Post by **wilco1967** » Wed Dec 12, 2012 2:30 pm

Crashpilot1000 wrote:@wilco67: "..So 0.0 means I should not have this problem..." You are right, $PMTK527,0.00*00 is the expected answer. Your assumptions are correct.

Cheers
Kraut Rob

OK... thanks a lot for confirming.....

Now I still need to find out why my copter is drifting soo much in PH....... :roll:

for a moment I thought this would be the solution..... we'll find it sooner or later though 8-)

....

Thanks !

BTW: which firmware are you guys using (on NMEA that is....) ?
I'm using MTK3329_A1.5E_20110118_10Hz_115200.bin (which defaults to 115200 / 10 Hz)

copterrichie · Post by **copterrichie** » Wed Dec 12, 2012 8:44 pm

I was browsing YouTube and come upon this video. Seems someone has Waypoints working.

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

EOSBandi · Post by **EOSBandi** » Wed Dec 12, 2012 9:17 pm

Yeah, implementing waypoint nav is not a big deal. BUT before that, we need a solid MAG and BARO implementation. I'm working on the MAG right now since the current calibration is a joke, and I saw some interesting movements on the BARO part too. Adding new features without making simple functions solid is for the Ardu guys...

copterrichie · Post by **copterrichie** » Wed Dec 12, 2012 9:21 pm

Glad you are Back.

alexia · Post by **alexia** » Wed Dec 12, 2012 10:00 pm

EOSBandi wrote:Yeah, implementing waypoint nav is not a big deal. BUT before that, we need a solid MAG and BARO implementation. I'm working on the MAG right now since the current calibration is a joke, and I saw some interesting movements on the BARO part too. Adding new features without making simple functions solid is for the Ardu guys...

i am FULLY agree with you
we have an example with ardu code..so many features but too many bugs..so nothing interessing! we need to move step by step

scrat · Post by **scrat** » Thu Dec 13, 2012 7:57 am

EOSBandi wrote:Yeah, implementing waypoint nav is not a big deal. BUT before that, we need a solid MAG and BARO implementation. I'm working on the MAG right now since the current calibration is a joke, and I saw some interesting movements on the BARO part too. Adding new features without making simple functions solid is for the Ardu guys...

@EOSBandi: what do you mean with "current cal. is a joke"? How will we then calibrate MAG with your code? Do you mean it will be no dancing?

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 8:53 am

Mag calibration is a threefold process.
1. normalize the gain on each axis
2. adjust the zero offsets for each axis.
3. compensate hard and soft iron disturbances.

Visually when you plot the x,y,z values from the mag (rotated on each axis) without calibration you will got a nice potato

After calibration this potato must become a perfect sphere.

In current code the gain normalization is faulty (wrong gain setting and not enough samples). The offset adjusting is more or less ok (this is the dance part). However it does not adjust the disturbances, so eventually you got an ellipsoid instead of a sphere.

I'm experimenting with the algorithm used in Fabio's FreeIMU_GUI program, which is a nice implementation of an ellipsoid to sphere transformation. I think we will need a separated program for calibration which will either write the data into eeprom or generate a .h file which could be included in the multiwii code.

So is will look like this :
1. load calibration program
2. do the dance, got visual feedback and you can decide that the calibration was successful or not.
3. Write a calibration.h file
4. load Multiwii
5. fly

dramida · Post by **dramida** » Thu Dec 13, 2012 8:59 am

Hello Eos, a while ago someone called Mahowik achived to control the variation of altitude with a P-D loop.

Here is the result http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

The code used is in this archive:

download/file.php?id=1663

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 9:07 am

dramida wrote:Hello Eos, a while ago someone called Mahowik achived to control the variation of altitude with a P-D loop.

Here is the result http://www.youtube.com/watch?v=7Sa-oyJ4Ljs

The code used is in this archive:

download/file.php?id=1663

On step at a time... I saw some very promising baro code lately in the repo....

Crashpilot1000 · Post by **Crashpilot1000** » Thu Dec 13, 2012 11:32 am

@EOS Bandi: Improving the Mag is a terrific idea. Your approach seems to be a little bit too much action for the average user, but it is very reasonable. I am def. looking forward to this!
BTW: Did you risk an eye on my code? Is it pure crap or is there something of use? What is - from your experience - a safe delaytime between commands send to mtk without reading out it's returnmessage (@57KBaud). I am currently working with 1 sec...

Greetings
Kraut Rob

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 11:53 am

Crashpilot1000 wrote:@EOS Bandi: Improving the Mag is a terrific idea. Your approach seems to be a little bit too much action for the average user, but it is very reasonable. I am def. looking forward to this!
BTW: Did you risk an eye on my code? Is it pure crap or is there something of use? What is - from your experience - a safe delaytime between commands send to mtk without reading out it's returnmessage (@57KBaud). I am currently working with 1 sec...

Greetings
Kraut Rob

Perhaps it is too much, but this is the only way if we still want to use AtMega processors, the processing power is quite limited so sophisticated onboard algorithms are out of the question.

Regarding your code I took a quick look, not bad, I'll have to mix it with the ublox init which is quite sophisticated in the current multiwii_shared trunk. I would not wait more than 200ms between commands, that must be enough.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Dec 13, 2012 5:08 pm

@EOS Bandi:
Hi!
Thank you very much for your reply!
I did another version. This time i improved the documentation in the maincode and config.h. Besides this i figured that a different minimum sat-count for different gps functions could be a good idea. PosHold is more a luxury feature so a higher satcount can be set. RTH is a more emergency function where a bigger error/lower satcount is OK. I made these variables accessible in the config.h

Code: Select all

#define MINSATPH 7                     // 5 is default minimal number of sats for gps PosHold, i found valid data with 7 sats. Since PH is luxury we want more sats..
#define MINSATRTH 5                    // 5 is default minimal number of sats for gps Return to Home since this is more an emergency function a 20m error doesn't matter

Concerning the MTK Binary mode i activated everything beneficial i could find. The most of it will be probably already on. The delay between commands is still set to 500 ms

.....
The simple spikefilter seems to be very usable on 5Hz data.
Keep up your outstanding work !!!

Cheers

Kraut Rob

Crashpilot1000 · Post by **Crashpilot1000** » Thu Dec 13, 2012 8:16 pm

Oops ! Something went wrong. Test03 is better than test04 i am not sure if it is the modified ini sequence for the mtk or the satcount thing.

EOSBandi · Post by **EOSBandi** » Thu Dec 13, 2012 11:36 pm

I just committed some rework on the HMC5883L gain calibration (init). The code is based on Fabio's FreeIMU code and I think this is as good now as it could be on this platform. After some experimenting I decided to keep the current offset calibration method (MAG DANCE) since the ellipsoid to sphere method did not gave significantly better results, but added difficulty to the calibration process. I tested it but i would appriciate if somebody will took a look.

vpb · Post by **vpb** » Fri Dec 14, 2012 2:14 am

Hi EOSBandi, I see your new commit on latest r1284 dev. "No changes in the mag calibration dance, gain calibration is done automatically
at every startup". I want to test that new MAG calibration code, does the procedure change?

Thank you!

doppler · Post by **doppler** » Fri Dec 14, 2012 3:42 am

EOSBandi wrote:I just committed some rework on the HMC5883L gain calibration (init). The code is based on Fabio's FreeIMU code and I think this is as good now as it could be on this platform. After some experimenting I decided to keep the current offset calibration method (MAG DANCE) since the ellipsoid to sphere method did not gave significantly better results, but added difficulty to the calibration process. I tested it but i would appriciate if somebody will took a look.

Trying it now, seems fine, I didn't do any additional calibrations or anything, is there something special needed?

I do have a question about the magnometer it may be specific to the HMC5883L (I don't have any other ones). On a flat surface I have it indicating north when the IMU is pointing north, and when I spin the IMU around the indicator points correctly due to that spin. So far so good. But if I angle the board (pitch or roll), any amount, and hold the board in all other directions the compass starts to head elsewhere, this is best demonstrated when pointing the board East or West. I was playing with Headhold today (build 1240) and was watching my quad yaw every time i took it off being level to go in a direction, as you would expect from my description, the quad didn't go where it was supposed to. Left the quad level itself again (Angle mode on) and the quad returns to the direction I had it held too..... this seems to me to make mag hold, useless, I suspect headfree would be just as useless. Shouldn't there be some fancy math involving the ACC and/or GYRO's so that the X, Y, and Z are used to offset the changes the mag is experiencing?

I would expect this to completely break when doing flips, so I would only think it should work when MAG and ANGLE are used for instance.

crashlander · Post by **crashlander** » Fri Dec 14, 2012 8:58 am

Hello EOSBandi!
Nice to have you back.

Regarding baro code...

EOSBandi wrote:On step at a time... I saw some very promising baro code lately in the repo....

...that last published (and than removed but accessible as zip in forum) code from Mahovik actually works very good (and at least in my case stable) but I believe it is not included in official _shared. And since it includes variometric (constant speed) climb and descend based on TH stick offset from set-point it is probably very good start into GPS point to point navigation.

Best Regards
Andrej

fax8 · Post by **fax8** » Fri Dec 14, 2012 10:15 am

I also saw the magnetometer calibration implemented by EOSBandi .. while that is surely better than before, you should really have a look at my new code for ellipsoid into sphere approximation.. check out the FreeIMU GUI: http://www.varesano.net/blog/fabio/free ... ersion-out
It's been discussed also here but people didn't seem much interested.. viewtopic.php?f=8&t=2175

Ideally, the FreeIMU GUI code has been written with the idea of supporting different serial protocols.. so far it only supports the FreeIMU library code, but adding support for the MultiWii shouldn't be difficult.

EOSBandi · Post by **EOSBandi** » Fri Dec 14, 2012 12:37 pm

fax8 wrote:I also saw the magnetometer calibration implemented by EOSBandi .. while that is surely better than before, you should really have a look at my new code for ellipsoid into sphere approximation.. check out the FreeIMU GUI: http://www.varesano.net/blog/fabio/free ... ersion-out
It's been discussed also here but people didn't seem much interested.. viewtopic.php?f=8&t=2175

Ideally, the FreeIMU GUI code has been written with the idea of supporting different serial protocols.. so far it only supports the FreeIMU library code, but adding support for the MultiWii shouldn't be difficult.

Hi Fabio,
I spent quite a time and even implemented a calibration using calibration.h from FreeIMU GUI. At the end of the day, it seemed to me that the outcome was not significantly different from results of the current offset calibration method. I admit that the current method does not address soft iron distorsions, but the question is that do we really need soft iron calibration ? Or with the current precision of the other elements of MultiWii it is just fine...

BTW, my gain calibration code is vastly based on your code, so credits goes to you !

EOS

shikra · Post by **shikra** » Fri Dec 14, 2012 3:47 pm

Hi - very quick drop in as been tied up with new job...

FWIW, I think the current Mag calib is good enough for what we need - other bits need improving first really.

What I have noticed is that if the copter is moved correctly during calib it makes abig difference. Smooth mag readings as rotate, rather than fast in some directions and slow in others. Also less deviation when copter is tilted.

In hold/RTH, I've not really seen any issues due to mag deviation.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Dec 14, 2012 7:56 pm

Help!

Sorry to interrupt here, but i am still struggeling with the MTK 3329 module the AXN1.51_2722_3329_384.1151100.5.bin and a valid DGPS fix. I connected the modul directly (via FTDI) to realterm (very good tip - thanks to EOS Bandi

) and let it put out NMEA strings (not turned to binary mode) at just 1Hz and observed the GGA strings. I got 10 Sats but never a DGPS fix. I threw every command at it that could possibly activate waas/sbas - nothing. Has anyone DGPS fix running on a binary capable Firmware?
Any help would be very appreciated!
Probably some simple methodical error?

Cheers

Kraut Rob

List of acknowledged commands but without success:

Code: Select all

  #define MTK_SBAS_INTEGRITYMODE"$PMTK319,1*24\r\n"    // TEST:ACK 
  #define MTK_NAVTHRES_OFF      "$PMTK397,0*23\r\n"    // TEST:ACK Threshold was 1.00m before (PMTK447 returns 0.0 NOW)
  #define MTK_SBAS_ON      "$PMTK313,1*2E\r\n"    // Enable search SBAS sat // TEST:ACK
  #define MTK_WAAS_ON           "$PMTK301,2*2E\r\n"    // DGPS MODE WAAS // TEST:ACK

List of commands described in the A11 revision of the MTK commandset but returned "ERROR UNSUPPORTED COMMAND"

Code: Select all

  #define MTK__DT_NAVTHRES_OFF  "$PMTK527,0.00*00\r\n" // Turn off Navthreshold // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK__DT_NAVTHRES_OFF  "$PMTK527,0*2E\r\n" // Turn off Navthreshold // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK_DT_SBAS_ENABLED   "$PMTK513,1*28\r\n"  // Enable Search for SBAS Sats // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK_DT_DGPS_WAAS      "$PMTK501,2*28\r\n"  // DGPS data source mode: WAAS // TEST: ERROR UNSUPPORTED COMMAND

EOSBandi · Post by **EOSBandi** » Fri Dec 14, 2012 9:45 pm

To get SBAS (actually EGNOS in Europe) you have to see one of the following sats : 120, 124, 126. Sat number 124 is in usually in test mode. So you have to enable using of test mode packets with $PMTK319,0*25<CR><LF>. sat 120 and 126 should work in integrity mode.

My recommendation is still that you should abandon MTK3329 and get a Ublox. The config and diag software is better by lighthyears than miniGPS.

Crashpilot1000 · Post by **Crashpilot1000** » Fri Dec 21, 2012 1:09 am

Hi!
3drobotics just released a new firmware for MTK 3329 it is called 1.9 or "AXN1.51_2776_3329_384.1151100.5_v19.bin". You can grab it here: http://code.google.com/p/ardupilot-mega ... n&can=2&q=

This FW 1.9 responds in binary mode with one decimal more precision(!)than current mtk binary or nmea and has therefor an altered syncword.
I added a slightly modified I2C_GPS_NAV-v2.1rc2 from EOS Bandi (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The config.h is already set to go for mtk binary with the FW 1.9 mentioned above. It is not compatible to the old mtk binary firmwares. In the config.h you will come across my spikefilter wich i find very useful, but you can deactivate it there. You can also alter the minimum sats required for gps functions there. You can now /will have to increase the "P" of your current GPS Pids.

Cheers

Kraut Rob

EOSBandi · Post by **EOSBandi** » Fri Dec 21, 2012 9:37 am

Crashpilot1000 wrote:Hi!
3drobotics just released a new firmware for MTK 3329 it is called 1.9 or "AXN1.51_2776_3329_384.1151100.5_v19.bin". You can grab it here: http://code.google.com/p/ardupilot-mega ... n&can=2&q=

This FW 1.9 responds in binary mode with one decimal more precision(!)than current mtk binary or nmea and has therefor an altered syncword.
I added a slightly modified I2C_GPS_NAV-v2.1rc2 from EOS Bandi (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The config.h is already set to go for mtk binary with the FW 1.9 mentioned above. It is not compatible to the old mtk binary firmwares. In the config.h you will come across my spikefilter wich i find very useful, but you can deactivate it there. You can also alter the minimum sats required for gps functions there. You can now /will have to increase the "P" of your current GPS Pids.

Cheers

Kraut Rob

One significant note. GlobalTop firmwares (which is used by 3Dr) are vendor protected from version 1.5 and up. This means that you can upload this firmware only to a Pa6B or other Global-Top made MT3329 chip based modules.

I'll incorporate Rob's changes during the festive season.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Dec 22, 2012 2:00 am

Thank you very much for being so active, supportive and helpful all the time in your scarce free time!
Since apm is struggeling with their autodetection code (confusion starts here: http://diydrones.com/xn/detail/705844:Comment:1062391) it may be an idea to make the mtk binary support depending on firmware selectable in the config.h. So the user should know what FW is running on his mtk3329 gps (running MiniGPS will give him clarification of that) a fw before 1.9 or 1.9 and define it in config.h. Mwii users got more guts

- i guess. My C/Arduino Coding abilities are very limited, i just coded on my purely loved Amiga1000 some Demos 22 years ago, so i am definately not the person to give you any coding advice at all. BUT i am very excited about your work on 2.2 of your gps code!

Since the world didn't destroy itself already I want to wish you and your family a very happy christmas!

Yours
Kraut Rob

dramida · Post by **dramida** » Wed Dec 26, 2012 11:48 am

EOSBandi wrote:I just committed some rework on the HMC5883L gain calibration (init). The code is based on Fabio's FreeIMU code and I think this is as good now as it could be on this platform. After some experimenting I decided to keep the current offset calibration method (MAG DANCE) since the ellipsoid to sphere method did not gave significantly better results, but added difficulty to the calibration process. I tested it but i would appriciate if somebody will took a look.

Hi Eos, just uploaded the code on the controller, i'll calibrate it on the field and then fly it on PosHold. I''ll give the results later in the evening.
/Mihai

EOSBandi · Post by **EOSBandi** » Thu Dec 27, 2012 12:42 am

Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.

albertoLG · Post by **albertoLG** » Thu Dec 27, 2012 9:01 am

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.

uumm... updated my gps firmware to "AXN1.51_2776_3329_384.1151100.5_v19.bin", EOSBandi, tested your revision, gps show in the gui and the leds flash so i have a 3Dfix, but seems more unstable than previous revision I used... with the previous when I switched to PH the quad just was in position with no big swings... now it just go away, try to go back but with big error in position... like was without changing my threshold settings

EDIT:
tested again and seems better now... probably was a poor satellite reception, first test was with very cloudy sky... second test with no clouds... poor MTK antenna? overall... fast 3Dfix than previously and better position and nav (tested a couple of RTH, ah.... wobble a little too much in navigation, need probably to tune PID, I use defaults)

EOSBandi · Post by **EOSBandi** » Thu Dec 27, 2012 9:24 am

Try to comment out the gps_lead_filter define in config, see if it is the gps or the filter. Also try 4hz updaate rate...

albertoLG · Post by **albertoLG** » Thu Dec 27, 2012 9:27 am

EOSBandi wrote:Try to comment out the gps_lead_filter define in config, see if it is the gps or the filter. Also try 4hz updaate rate...

edited my post when you were writing yours.. :-)

I'll do this test also to see if change something

dramida · Post by **dramida** » Thu Dec 27, 2012 10:37 am

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.

Great work Eos

I'll test it along with the new mag calibration procedure and Adrian new altitudevario implementatio viewtopic.php?f=8&t=2371&p=28353#p28352

The Christmas presents are coming later this year