Activate GPS navdata

[wiseman]

Even with the Flight Recorder GPS accessory, from a cold boot the AR.Drone doesn't send GPS data as part of navdata.

The following command will cause the drone to begin including GPS data (this is what the iOS app sends):

client.config('general:navdata_options', 777060865);
// 777060865 = 101110010100010000001000000001
// The default options value is
//     65537 = 000000000000010000000000000001

[andrew]

That's interesting, I guess once it's been sent by the phone it doesn't need to be sent again, as I've not experienced that (I can just plug it into one of my drones and start reading straight away)

[ahensley]

What drone/GPS firmware version was this with?

On 2.4.8 (drone) and 4.1.2-P6 (GPS/FlightRecorder) I actually can't get any navdata back at all unless 'general:navdata_optoions' is 'TRUE', which isn't particularly helpful. Setting it to 'FALSE' and/or your value don't seem to help. I'll get back a couple frames with just the header, droneState, sequenceNumber, and visionFlag, then none at all.

FreeFlight and QGroundControl seem to have no trouble though. Thoughts?

[timogiles]

I have found the exact same thing as ahensley. If there is any update on this or resolution I would love to know.

[wiseman]

I just tested again with AR.Drone firmware 2.4.7, GPS firmware 4.1.0-P1, and client.config('general:navdata_options', 777060865); still works to activate GPS navdata. I'll update everything to the latest firmware and try again.

QGroundControl uses a completely different protocol, mavlink, so I assume that's why it doesn't run into this problem. I got the 777060865 value by sniffing traffic sent from FreeFlight to the drone, but maybe this changed in later versions.

[wiseman]

Ouch. Using AR.Drone firmware 2.4.8, GPS firmware 4.1.2-P6, I see the behavior you're seeing: I stop receiving navdata almost immediately. This seems like a big problem.

[timogiles]

It seems that bit 27 of navdata_options is actually the GPS mask. Your 77060865 number enables that bit along with several others. The constants.js file in ar-drone/lib calls this bit "ZIMMU_3000", which is incorrect but no one would know that since Parrot hasn't released an updated SDK.

With the latest firmware the GPS packet seems to have changed. In the parseNavdata.js file in ar-drone/lib/navdata I changed the 'gps' parser to comment out everything after unk_2. With that changed the GPS works as it should.

'gps': function(reader) {
 return {
  // from https://github.com/paparazzi/paparazzi/blob/55e3d9d79119f81ed0b11a59487280becf13cf40/sw/airborne/boards/ardrone/at_com.h#L157
  latitude:             reader.double64(),
  longitude:            reader.double64(),
  elevation:            reader.double64(),
  hdop:                 reader.double64(),
  data_available:       reader.int32(),
  unk_0:                timesMap(8, reader.uint8, reader),
  lat0:                 reader.double64(),
  lon0:                 reader.double64(),
  lat_fuse:             reader.double64(),
  lon_fuse:             reader.double64(),
  gps_state:            reader.uint32(),
  unk_1:                timesMap(40, reader.uint8, reader),
  vdop:                 reader.double64(),
  pdop:                 reader.double64(),
  speed:                reader.float32(),
  last_frame_timestamp: droneTimeToMilliSeconds(reader.uint32()),
  degree:               reader.float32(),
  degree_mag:           reader.float32(),
  /*unk_2:                timesMap(16, reader.uint8, reader),
  channels:             timesMap(12, reader.satChannel, reader),
  gps_plugged:          reader.int32(),
  unk_3:                timesMap(108, reader.uint8, reader),
  gps_time:             reader.double64(),
  week:                 reader.uint16(),
  gps_fix:              reader.uint8(),
  num_satellites:       reader.uint8(),
  unk_4:                timesMap(24, reader.uint8, reader),
  ned_vel_c0:           reader.double64(),
  ned_vel_c1:           reader.double64(),
  ned_vel_c2:           reader.double64(),
  pos_accur_c0:         reader.double64(),
  pos_accur_c1:         reader.double64(),
  pos_accur_c2:         reader.double64(),
  speed_accur:          reader.float32(),
  time_accur:           reader.float32(),
  unk_5:                timesMap(72, reader.uint8, reader),
  temperature:          reader.float32(),
  pressure:             reader.float32()
  */
};

[wiseman]

Awesome, @timogiles. I found an updated description of the GPS fields at lesire/ardrone_autonomy@a986b33 and opened #93, and your tracking the issue of hanging navdata down to a bad definition should make for an easy fix, which I have in progress at https://github.com/felixge/node-ar-drone/tree/gps_2_4_8

And good catch on ZIMMU_3000 as well.

Once I do more testing I'll close this.

[wiseman]

To be clear, I've already confirmed that the gps_2_4_8 branch works with firmware 2.4.8 once you do client.config('general:navdata_options', 777060865);. I'll test with ZIMMU_3000 and add unit tests to that branch, then merge and close.

[wiseman]

FYI master has the fix for reading GPS data in firmware 2.4.8.

[felixge]

💖 thank you so much @wiseman . I just recently played with the GPS stuff for the first time - this will come in really handy!

[eschnou]

Grrrrr... no I really don't have any excuses left not to buy a gps dongle :-) Great work everyone!

[andrew]

@wiseman I'm just triaging some of the issues, is this ok to close now?

[wiseman]

Yes, I think the answer is to use the ZIMMU_3000 constant.

[lwsang13]

Hi @wiseman !!
I have Big problem! Please help me...
I'm using ARdrone1.0...I attatched gps to my ardrone. And i tested it using Arduino and linux....
but I don't know how to get data using Visual studio(c++).

1. Do you know how to get data from Ardrone 1.0??
2. And can you expain ZIMMU_3000 ?? is it similar with gps?
3. Is it right that the gps data are included in navdata?

• size of data are just 12 in my program, so I'm very confused.

Thank you!