In this post I show videos of two real flights, the first above for FlightZoomer version 2.0 and another below with the freshly released version 2.1. Both videos show the same automatic flight including an ILS approach. In the videos the replay feature is used to sync the recorded video from the on-board Sony camera with the presentation of the groundstation.

While FlightZoomer 2.0 works nicely and was a huge step forward overall, the video also shows some areas, that leave room for improvement. In particular the LNAV, the VNAV and the ILS autopilot modes worked not as precisely as a Pixhawk based system in theory could.

All this was addressed with FlightZoomer version 2.1, so check out the following video to see how the behavior improved:

Version 2.1 is provided as a functional upgrade. It does not bring a single new button or any UI change, but under the hood a nice number of improvements have been implemented. Existing algorithms have been refined, new cascaded control layers have been added, the ILS can be captured much more robustly, flight plans are followed more precisely and a bunch of bugs have been ironed out.

The complete list of changes is here:

  1. The turn initiation time is considered now for the flight path calculations. The turn initiation time is the duration, during which the flight path over ground lags the ideal turn. This change increases significantly the precision, how the aircraft follows the planned flight track.
  2. For the LNAV and the ILS Localizer mode deviations along the straight legs are now actively corrected. Prior version 2.1 the aircraft always just pointed to the next waypoint and, as a result, deviations have not been corrected until the very end of each leg.
  3. A new algorithm has been implemented in LNAV mode to keep the turn radius constant even if the speed varies a bit. This was required because before the aircraft often deviated from the planned track during turns when the speed was dropping temporarily.
  4. Speed transitions have been abruptly prior version 2.1 but now are smooth as well. Every speed change happens over a period of 2 seconds.
  5. The vertical flight profile in VNAV mode has been improved. Due to inaccuracies in keeping the standard climb or descend rate, the actual altitude could deviate quite a bit from the correct altitude for a certain position. This is important especially during descends because we are moving towards the terrain and because the end of the descend and the end of the route should happen exactly at the same spot. The new VNAV algorithm in version 2.1 ensures this.
  6. Optimization and fine-tuning of the approach pattern calculation. The result is a more realistic and much more compact approach pattern, especially during the downwind and base.
  7. The ILS glideslope can now not only be captured from below and after having turned to the final approach course, but from below or even before the last turn.
  8. Totally 26 issues have been fixed.


In both videos basically the entire flight was flown with the autopilot. Along the route using the LNAV and the VNAV modes, using the TRACK OVER GROUND, ALTITUDE and FLCH modes for the downwind and base and finally using the ILS LOCALIZER and ILS GLIDESLOPE modes for the approach.


Some screenshots from the second video:

On the next image you can see how precisely the aircraft follows the planned track even during a turn. Consider that the turn radius first is a variable that depends on the cruise speed and the turn rate (angular velocity). In practice also the actual speed and the impact of the inertia on the actual track over ground have to be incorporated:


The second image shows the final approach to the runway 08 of my virtual airport. Consider how the runway elevation has been configured 5 m above the real road, in order to have some safety buffer:



Again I dont want to miss the opportunity to provide some high level information about FlightZoomer:

  • FlightZoomer is a top notch distributed avionics suite for drones
  • FlightZoomer is entirely a software solution. The hardware are COTS devices (Windows Phones smartphones).
  • Why distributed? Because there is an onboard device and a groundstation, both are connected via a Relay Server at home.
  • All the components are coupled with a cellular EDGE, 3G or 4G link.
  • The onboard smartphone is mated with an APM based flight controller via Bluetooth.
  • Currently supported is Arducopter 3.3 or higher.
  • Supporting Arduplane is on the to-do list.
  • For about 200$ you can get everything mentioned working (assumed, you need to buy two Windows Phones for the groundstation and the sensor device)


Much more details you can find on my homepage


The full documentation for version 1.5 is still valid for the basic functionality:

Version 1.5 full documentation


For the version 2.0 the additional features are described in this 50 page addendum:

Version 2.0 addendum


For version 2.1 there is currently no separate documentation (beside this post :D ) 

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • This looks awesome. I'll try it out soon.
  • Hi Simon

    We sure are from the same country! I live in Klingnau.

    The system architecture you describe would be possible. It would require a medium change in the software but in principal, it would be possible (with Bluetooth instead of USB to connect the groundstation though).

    There are some weak areas of such a design however:

    • My FlightZoomer sensorics app (the onboard one) is really an additional abstraction layer above the FC. It has 14 independent autopilot modes additionaly. It achieves a level of control not possible with any of the FCs (as far as I am aware). This autopilot is currently designed as a split design (UI layer on the ground and the processing engine onboard). The onboard processing engine benefits from short and reliable communication links with the FC. If the processing engine would be located within the groundstation on the other hand, we would not only add the lag time of the up- and downlink but would also loose the capability to fly autonomously even in case of interupted or impaired communication.
    • FlightZoomer by nature is a Internet based design. The relay server is not only needed as relay between the two links, it also hosts the navigation database. So we would anyway need the link between groundstation and relay server. The Internet based design is also one of the great promises for future extensions. I could e.g. easily feed ADS-B data into my "network" by regularily calling FlightAware webservices. So at some point, FlightZoomer needs to be in contact with the Internet. Ok, that would be possible also with your suggested setup.
    • How much payload are you currently using? A light smartphone without battery would weight maybe 50-100g more than the hardware of a comparable communication chain. Is that really too much? The weight penalty would be even less if you e.g. substitute a separate camera by the phone's camera.
  • Excellent app. Judging by your accent and name I guess we live in the same country.

    I guess many APM users which are interested in this app would like to get rid of the extra phone in the Aircraft (dead weight, most use a sophisticated FC and payload). Would it be possible to use the a serial mobile/RF modem (as is usually used with apm/pix*) and connect it via usb on the ground to the smartphone. Similar to the aproach with android applications and an OTG connector?

  • The advantages of the FlightZoomer approach:

    - Have a software solution only, the hardware is off the shelf. No config stress, superior ease of use.

    - Also the onboard device has a UI and requires occasional user action. There is no nicer user interface than a ultra bright color touchscreen

    - Almost any of the "ingredients" of a smartphone is useful onboard of a UAS. The CPU, the camera, the networking capabilities, Bluetooth, WiFi, cell networks, and even the sensor suite can be used as fallback.

    - There is no more compact solution for the computational power and everything else you get than a smartphone.

    - There is also no cheaper solution for what you get than a smartphone (by a long shot).

    - On my copter's sensor device, I make good use of the CPU power, the touchscreen UI, the cell network to the groundstation, the Bluetooth to the flightcontroller and the WiFi to the Sony camera. If I would install separate hardware units for all these tasks it would a) weight more b) cost much more c) drive up the complexity d) reduce the reliability

    - If weight is critical I could still strip off the phone battery and power the device from the onboard power distribution. Depending on the actual model you use, even the case could be removed.

    - The software components are deployed on homogenous hardware. This allows easy and straight forward modularization of the software, as well as component re-use.

  • MR60

    Ah ok thx for the really clear explanation. So the main advantage is unlimited range for telemetry via 3/4G, now I get it.

    But why use a smartphone onboard as you carry the extra weight of its glass screen, battery and shell : couldn't you develop a companion board with 3/4G module ?

  • Hi Hugues

    This is the FlightZoomer system architecture:

    3702275073?profile=originalWith FlightZoomer 1.0 the onboard smartphone was indeed the sole source of sensor data, that was then transmitted to and shown on the groundstation. This approach lacked precision and is abandoned by now.

    Since FlightZoomer 1.5 I fetch the sensor data via Bluetooth (physically)/Mavlink (protocol-wise) from the flight controller. Via this Bluetooth/Mavlink connection I also let the autopilot control the flight path of the aircraft.

    So the primary purpose of the onboard device is to act as a companion computer with EDGE/3G/4G connectivity to the groundstation. Additionally (but optionally) it can serve as onboard camera and failover source for IMU & GPS & compass.

  • MR60

    I do not understand what is flightzoomer and why you need two smartphones ? Do you mean you use a smartphone onboard for its IMUs and the one on the ground as a HUD display of the onboard IMUs ? Can you explain in two words ?

This reply was deleted.