Closed wiseman closed 10 years ago
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)
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?
I have found the exact same thing as ahensley. If there is any update on this or resolution I would love to know.
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.
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.
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()
*/
};
Awesome, @timogiles. I found an updated description of the GPS fields at https://github.com/lesire/ardrone_autonomy/commit/a986b3380da8d9306407e2ebfe7e0f2cd5f97683 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.
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.
FYI master has the fix for reading GPS data in firmware 2.4.8.
:sparkling_heart: thank you so much @wiseman . I just recently played with the GPS stuff for the first time - this will come in really handy!
Grrrrr... no I really don't have any excuses left not to buy a gps dongle :-) Great work everyone!
@wiseman I'm just triaging some of the issues, is this ok to close now?
Yes, I think the answer is to use the ZIMMU_3000
constant.
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++).
Thank you!
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):