GPS lock ups

[arne]

I have played a little bit with my Naze32 copter and GPS during the weekend. I've read that this is kind of dangerous and can cause crashes, but i did tried it anyway...That results in 3 crashes: One with RTH, one with POSHOLD and another one with POSHOLD after some code changes. The good thing, despite of some broken props nothing really happens.

Each crash was pretty much the same: activate a RTH or POSHOLD, wait 1-10 sec, watch the copter tilt about 30-45° and then the controller becomes unresponsive and the motors keep the same RPM. Ones the copter has crashed, you have to pull the battery.

I was able to reproduce the behavior without props and the copter standing still on the ground, but unfortunately it does not happens always or it takes much longer. The strange thing is, that most people say POSHOLD works for them. I use a 10 HZ MT3329 GPS module with NMEA output and the copter is working fine, as long as I don't touch any GPS function. The GUI shows lan/lon correctly.

Does anyone has an ideas what's the reason for the lock ups? I thought it might be a div/0 problem or something like that!?

[timecop]

Seems MTK is the common scenario here.

[Crashpilot1000]

It is called the Self Destruction Feature .
There might be some software problem concerning mtk binary and nmea parsing. If MTK would produce such jerky data by default they wouldn't sell one unit.
With I2C GPS running gps code on extra arduino i never had lockups of the whole flightcontrol (still on arduino ) but a lot of twitches. I changed one variable of NMEA parsing to 32 Bit:

Code: Select all

...
#define DIGIT_TO_VAL(_x)   (_x - '0')
uint32_t GPS_coord_to_degrees(char* s)
{
   char *p, *q;
   uint8_t deg = 0, min = 0;
   unsigned int frac_min = 0;
....

to

Code: Select all

...
#define DIGIT_TO_VAL(_x)   (_x - '0')
uint32_t GPS_coord_to_degrees(char* s)
{
   char *p, *q;
   uint8_t deg = 0, min = 0;
   uint32_t frac_min = 0;
....

That solved a lot of twitching for me. Eos Bandi says that there is no overflow possible with 16 Bit. Hmm.. perhaps it is a compiler issue. I don't know, but it works for me (MTK/ NMEA parsing) on arduino. You should be able to try out the same on naze and recompile the code.
Just my thoughts about this.

So long
Kraut Rob

[arne]

I did a test with a u-blox GPS receiver on the same quad today. Soon it started to rain, so I could do only a short test. That test worked without a problem.

Afterwards I tried the mod from crashpilot1000, but due to the rain, I could only do a indoor test. That was fine too. What I don't get is that the frame decoding function is executed with or without the GPSHOLD or RTH function activated. Why do the lock ups only occur after enabling GPSHOLD or RTH?

[timecop]

Does lockup mean - motors stop and it drops out of the sky? (i.e. hardfault, whose handler does shutdown and idles in a endless loop), or does lockup mean it does some other weird shit - like flying back home to north korea etc

[arne]

The motors keeps on with the same speed. No inputs possible anymore, no disarm and no usb/serial connection possible. It just kind of freezes.

btw: Changing frac_min doesn't help. I had another lock up after changing it.

[LeoWie]

Testing GPS_UBLOX (with set nav_controls_heading = 0, all GPS related values r237 defaults) I had a little problems with my Naze32 HEX6X ~1200g-:
- POSHOLD works fine,
- RTH (switched on ~25m away from home) makes troubles after some seconds: the copter begins to wobble und RTH has to be switched off (then control was here immediately = no crash or pilots stress).

It looks like there is a D missing in a PID but I dont’ know what one (gps_pos_... gps_posr_...gps_nav_...?) or maybe should I change nav_speed_... and/or nav_slew_rate?

… or the wobble-problem mode is case NAV and not WAYPOINT? ... because it looks like next to a hold point everything is ok but not far away from home, so maybe there is a problem when sending the copter from somewhere (out of the home area) to the home point?

>>> Thanks in advance for your kind assistance. <<<

In the meanwhile I’ll try to understand the GPS related Src a little more (In the moment I know almost nothing, eg. not in what circle the copter is in Waypoint mode or in Nav ...)

My GPS related software customizing / my CLI's in the moment (r237):

Code: Select all

gps_type = 1 #orig 0
gps_baudrate = 38400 #orig 115200
gps_pos_p = 11
gps_pos_i = 0
gps_pos_d = 0
gps_posr_p = 20
gps_posr_i = 8
gps_posr_d = 4
gps_nav_p = 14
gps_nav_i = 20
gps_nav_d = 8
gps_wp_radius = 200
nav_controls_heading = 1 #orig  0
nav_speed_min = 100
nav_speed_max = 300
nav_slew_rate = 30

I think it's a good idea to read / share this great link again (from "Naze32 hardware discussion thread" by rotary65 on Tue Sep 25 2012):

While looking into the magnetic declination question, I came across this nice (PDF) introduction into MWC GPS by EOSBandi. Although it's not really Naze32, it explains the GPS related MWC parameters and I thought I'd pass the link along to those of you experimenting with GPS. He includes a link to a neat GPS PID simulator(for Arducopter, but still useful) on the DYIDrones site.

Here the very important info "nav_controls_heading = 1" is from. Many thx again.

[LeoWie]

Still have no "Big Picture" of what's going on in the GPS related src / not much time to look into the src.
But after reading EOSBandis docu (see "...") and because weather was ok to fly (+ 3,5 deg celsius, but too cold for handling my laptop outdoor) so I wantet to try some things:

--- modis b (copy template) ---

Code: Select all

set gps_baudrate = 57600
set gps_pos_i = 4
set gps_posr_p = 15 
set gps_posr_d = 2 
set nav_speed_max = 200 
set d_pitch = 24
set gimbal_pitch_gain = 15
set gimbal_roll_gain = 31

Comments modis b:
GPS:
gps_baudrate = 57600 #orig 115200, later 38400, b>57600 maybe a little faster comm?
gps_pos_i = 4 #orig 0, b>4 see "wind is pushing away ..."
gps_posr_p = 15 #orig 20, b>15 see "copter overshots the target"
gps_posr_d = 2 #orig4, b>2 see "start at 0 ...oscillations die down?"
nav_speed_max = 200 #orig 300, b>200 see "recommend 200cm/sec ... increase it later".
Other:
set d_pitch = 24 #b>
set gimbal_pitch_gain = 15 #b>
set gimbal_roll_gain = 31 #>b

Result:
Copter reaches the targets better, RTH too. Had to switch off GPS Hold (not RTH this time) only once because of wobbles at one WP (out of about 20 tries in total).
... not a big conclusio, but: the software customizing params / CLI work.

Maybe I'll only try change to "gps_posr_d = 6" next time(?)

[LeoWie]

Update: made a cable-salad cleanup + extra cable tree form ubec to cam stab servos ... and will test this
w no/little cli changes soon.

[brm]

It is called the Self Destruction Feature .
There might be some software problem concerning mtk binary and nmea parsing. If MTK would produce such jerky data by default they wouldn't sell one unit.
With I2C GPS running gps code on extra arduino i never had lockups of the whole flightcontrol (still on arduino ) but a lot of twitches. I changed one variable of NMEA parsing to 32 Bit:

Code: Select all

...
#define DIGIT_TO_VAL(_x)   (_x - '0')
uint32_t GPS_coord_to_degrees(char* s)
{
   char *p, *q;
   uint8_t deg = 0, min = 0;
   unsigned int frac_min = 0;
....

to

Code: Select all

...
#define DIGIT_TO_VAL(_x)   (_x - '0')
uint32_t GPS_coord_to_degrees(char* s)
{
   char *p, *q;
   uint8_t deg = 0, min = 0;
   uint32_t frac_min = 0;
....

That solved a lot of twitching for me. Eos Bandi says that there is no overflow possible with 16 Bit. Hmm.. perhaps it is a compiler issue. I don't know, but it works for me (MTK/ NMEA parsing) on arduino. You should be able to try out the same on naze and recompile the code.
Just my thoughts about this.

So long
Kraut Rob

you are on a 32 bit micro.
an int and int32 type on an arm is the same.

[LeoWie]

Update: all my Naze32 HEX6X GPS - look like software - problems are solved now.

95% of my GPS hold / home copter wobbles were caused by / depended on:

1. Where the GPS antenna is mounted (not ok: not high enough and/or distance to FC less than 80 mm),
2. If there is an extra cable tree from ubec to cam sevos + FC or not (not ok: 2 servos + ubec plugged to FC without cable tree),
3. "Cable salad" near the FC (not ok: eg. if even low amp 5V(!) ESC - RX cables touch the FC. ok: everything ~ 15+mm distance to the chips, high amp+volt cables as far away as possible).

Other little sw customizing / CLI changes before an now just set gps_posr_d = 6 (from 4) for sure did not slove my GPS problems.

[thebgrian]

Hi, LeoWie

Can you post a picture of your setup? Are you using a u-blox GPS module and what exactly do you mean with a "cable tree".
Thank you for doing all this tests!

[LeoWie]

In the moment I use an old Rabbit GPS module (1). On other Naze32 FC copters "Crius CN-06 GPS Receiver v2.0 Module" does the same. I also have some other no name Ublox CN-6 modules (not testet, but look like can be used).
Cable tree: see (2): from UBEC +- goes to a tree that forkes to 3 branches: +- to FC, +- to servo 1, +- to servo 2 (the servo cables are split: only white goes to the FC. +- goes to tree). This tree is far away from the FC (bevore this mod ubec +- was plugged to FC and 2 servos also to FC (without this tree) ... this was not good).
Cable salad: see (3): no ESC - RX cable touches the FC. All high volt + amp cables are far away / under the FC (not on the pic).

PS: In the meantime I had 10 (lipos) flight time without any GPS wobble. I am sure: the problem was (1) + (2) + (3) .
PPS: sorry for the stocking + pixels: I want to keep some foto quality relevant secrets.

[thebgrian]

Thank you!
Cable tree should also help with ground loops. DO you have the ECS BECs connected also?

[LeoWie]

Thank you!
Cable tree should also help with ground loops. DO you have the ECS BECs connected also?

No - ESCs BECs are not in use: all red cables are plugged off, see left (3): useless red ESC cables are isulated / shrinked red / not connected to the FC (variant: do not modify ESC cables, simply turn plug 180 degrees = connect white only).