QGroundControl with AR Drone 2.0 (w/Flight Recorder)? Does anyone here successfully use QGroundControl for autonomous flights with an AR Drone? Is there a site with better info than the QGroundControl site? I have an AR Drone 2.0, Flight Recorder, etc., and I'm trying to run the QGroundControl software.  The first snag I found is that, you have to power the drone and let it initialize, THEN plug in the Flight Recorder and let it settle, and connect via WiFi, before running QGroundControl!  This should have been obvious, since you have to plug in a thumbdrive after initialization too, but it took a while for me to ignore the instructions and do what works. Then, in QGroundControl, there are all sorts of ambiguous issues.  When you set "home", they ask for altitude, but is that in meters, or feet? And if the GPS is drifting, is it better to enter a lower or higher altitude as "home"? The flight data screen shows the GPS readout in meters, so I wondered why it doesn't just enter that as a default.

I've read that only some of the QGroundControl operands are recognized by the Flight Recorder, but no hint of which ones -- no list. When I set waypoints, I am prompted to enter the altitude as either absolute, or relative.  If I haven't set the absolute altitude of home, does relative work better, worse or not at all? Basically, I've tried a simple test: -Rise to 3 meters and loiter for 45 seconds -Descend to 1 meter waypoint and loiter for 45 seconds (I thought, to defeat letting go of a GPS lock and drifting, as happened to Kyle Tarpley in a video) It is very difficult to drop multiple waypoints at the exact same coordinates.  I've had to edit the lat lon entries to make them all the same, after dragging distant waypoints back to origin. The problem I've run into is that the quad will take off and ascend, but then stay there until the battery dies (drifting quite a bit, despite a good GPS lock).  And while I use the right-arrow "play" button to engage autonomous flight and start the "program", it never advances to the next waypoint, and the "stop" button does nothing -- the thing will not land until it runs out of power.

In fact, there is no way to stop it short of pulling it out of the air by hand and unplugging the battery WHILE THE PROPS SPIN! I'm sure I just didn't emerge from the womb with the knowledge of how to steer QGroundControl!  The documentation is roughly as sparse as most we've all seen.  There is some setting that makes the difference between success and failure, and I just don't know what it is.  I've found no YouTube video that goes into detail on it either. 0 members like this If they put GPS inside the BeBop by default, they should just integrate the guts from the Flight Recorder, then future firmware should apply to both internal and USB-external GPS units. My comments were specific to QGroundControl, which isn't a Parrot product, but an open source effort.  I consider the software from Parrot to be next to useless as it will not fly the drone beyond WiFi range. which is around 50 meters. (I'm routinely getting less than 30 meters) People are having successful flights with QGroundControl, but there is no step-by-step guide that documents how that software works. 

There are all sorts of questions -- what is "guided mode" vs. auto-guided mode?  How do you setup "home" and base altitude?  How do you get it to actually RUN the flight... I now have three other quads besides the Parrot, so I'm not buying another Parrot product (most likely ever).  parrot ar drone firmware downgradeThe 2.0 will do whatever it's capable of, and I'll leave it at that.ar drone 2 idigital I just want to achieve the same success others have with the 2.0, Flight Recorder and QGroundControl.  parrot ar drone ucuzI think the GPS in the Flight Recorder is probably adequate, and most problems people have had come from a poor GPS fix, or obstructed sky view.  parrot ar drone ssh

After using an actual radio to fly something, I would rather not use a phone or tablet again in my life.  So it's autonomous success or a suicide mission for this 2.0! Given that Parrot is charging $150 for its GPS "Flight Recorder," I would expect Parrot to provide better firmware and software support for this unit, at some point. ar drone 2 prisjaktAfter all, it is a common industry practice to ship hardware with no software, or, crappy software, with the goal providing updated and upgraded software, after the hardware is in the market: much the same way NASA launches a satellite first, and then develops and uploads the software to the satellite, while the satellite is en route to its destination. parrot ar drone precio media marktParrot seems to be unaware of this practice.If cars were sold like technology, they'd limp off the lot and you'd be mailed parts for years.

There are enough pre-Bebop Parrots out there and Flight Recorders, that I think some clever geeks will try to implement firmware improvements at some point. I hope you are right. I would like to eventually be able to get some proper use out of my $150 Parrot Flight Recorder and GPS waypoint guidance system. I have found that using a WIFI range extender (EDIMAX EW-7416AP) on a 30 foot tower makes a huge difference in range so I would highly recommend that. The GPS guidance provided by FreeFlight works within the 3 meter error of the GPS to a tee. Note: 3 meter radius of course. I agree the GPS fight recorder  is expensive and absolutely should be built in which all in all should reduce the price. But back to the subject of this thread. Hugh did you ever get answers to you questions?MAVLink is a very lightweight, header-only message marshalling library for micro air vehicles. It can pack C-structs over serial channels with high effiency and send these packets to the ground control station.

It is extensively tested on the PX4, PIXHAWK, APM and Parrot AR.Drone platforms and serves there as communication backbone for the MCU/IMU communication as well as for Linux interprocess and ground link communication. The MAVLink generator was first released early 2009 by Lorenz Meier under LGPL license. The generated output was always considered equal to the input message spec and has since been clarified to be MIT. The current MAVLink Protocol Version can be looked up here: Common MAVLink Message Documentation These tutorials show how to integrate MAVLink with your autopilot or Linux robot. Message documentation is generated for all MAVLink messages automatically and always up-to-date. To get the details of a MAVLink message, please refer to the message lists below. You can additionally generate Doxygen API docs from the MAVLink source. Create a new MAVLink Message On-the-wire format and extra CRC calculation –HIGHLY RECOMMENDED ARTICLE EXPLAINING API vs INTERNAL FORMATS

MAVLink Release 1.1 Compatibility and Features MAVLink Data Types and Conventions QGroundControl users: Although MAVLink itself does not rely on it, QGroundControl adjusts its views and settings based on the HEARTBEAT MAVLink message. QGroundControl uses this message also to track if a system is alive or if the connection broke. Therefore make sure to send a heartbeat every 60, 30, 10 or 1 second (1 Hz is recommended, but not required) There is a “common message set” containing widely used messages, which is distributed as header-only C library. If you like to use your own custom messages, you can generate these with the MAVLink Generator (C/C++, Python) or QGroundControl. The MAVLink message definitions and generator code is hosted at: Installation / usage instructions can be found at: Downloading / Installing MAVLink Instructions how to use the generator can be found at: MAVLink Generator (C/C++, Python) Instructions how to package MAVLink releases (developers only) can be found here:

There are by now many systems and software packages using MAVLink: Maintainer: Lorenz Meier, lm@inf.ethz.ch pxIMU Autopilot (main protocol) SLUGS Autopilot (main protocol) SenseSoar Autopilot (main protocol) SmartAP Autopilot (main protocol) AutoQuad 6 AutoPilot (main protocol) HK Ground Control Station (Windows) QGroundControl w/ AutoQuad MainWidget (Windows/Mac/Linux) MAVCONN Lightweight Aerial Middleware http://pixhawk.ethz.ch/software/middleware/start MAVProxy (allows to connect multiple UDP/serial links, including flightgear): ETH Flying Machine Arena http://www.idsc.ethz.ch/Research_DAndrea/FMA ETH SenseSoar Solar Airplane Project http://www.sensesoar.ethz.ch/doku.php?id=news ETH Skye Blimp Project http://www.projectskye.ch/ UC Santa Cruz SLUGS http://slugsuav.soe.ucsc.edu/index.html The MAVLink generator is LGPL licensed and its output is MIT licensed and can therefore be used as a library royalty-free in closed-source and open-source applications.

Q: Is the upgrade easily done? - Yes, v.1.0.0 is almost fully API-compatible with v.0.9.0. Only a few messages have changed, all protocol-functions like the message parsing (mavlink_parse_char) are fully compatible. Q: What are the main benefits from upgrading? Q: Is the new version to be used soon? Q: How many aircraft does MAVLink support? Q: How efficient is MAVLink? Q: Where can I use MAVLink? Q: How safe is MAVLink? Q: Can I use MAVLink in a closed source application without copyright issues? - Yes, without any limitations. The LGPL license only requires you to contribute changes to MAVLink itself to the community, not any code that uses MAVLink. So you are not required to publish any of your application code. Q: MAVLink uses only one start sign - isn't this less safe than using two or three start signs? Q: How does MAVLink detect and decode messages in the byte stream?n Q: What use do the system and component IDs have? Q: MAVLink contains a sequence number in the header - is this really necessary?

Q: I would like to help improve the decoding/encoding routines or other features. Can MAVLink be changed? - Yes, but only very, very carefully with safety testing. MAVLink is by now used as a safety-critical component in many autopilot systems and has undergone more than two years of testing. Please suggest new features on the MAVLink mailing list. This is the anatomy of one packet. It is inspired by the CAN and SAE AS-4 standards. Byte Index Content Value Explanation 0 Packet start sign v1.0: 0xFE (v0.9: 0x55) Indicates the start of a new packet. 1 Payload length 0 - 255 Indicates length of the following payload. 2 Packet sequence 0 - 255 Each component counts up his send sequence. Allows to detect packet loss 3 System ID 1 - 255 ID of the SENDING system. Allows to differentiate different MAVs on the same network. 4 Component ID 0 - 255 ID of the SENDING component. Allows to differentiate different components of the same system, e.g. the IMU and the autopilot.

5 Message ID 0 - 255 ID of the message - the id defines what the payload “means” and how it should be correctly decoded. 6 to (n+6) Data (0 - 255) bytes Data of the message, depends on the message id. (n+7) to (n+8) Checksum (low byte, high byte) ITU X.25/SAE AS-4 hash, excluding packet start sign, so bytes 1..Note: The checksum also includes MAVLINK_CRC_EXTRA (Number computed from message fields. Protects the packet from decoding a different version of the same packet but with different variables). The checksum is the same as used in ITU X.25 and SAE AS-4 standards (CRC-16-CCITT), documented in SAE AS5669A. Please see the MAVLink source code for a documented C-implementation of it. MAVLink supports fixed-size integer data types, IEEE 754 single precision floating point numbers, arrays of these data types (e.g. char[10]) and the special mavlink_version field, which is added automatically by the protocol. These types are available: This protocol was totally geared towards two properties: Transmission speed and safety.