An Autopilot in the clouds - part 6.5

An Autopilot in the clouds - part 6.


The loooong wait...

Weather here in Denmark is optimal right now, if you’re either a fish or create 110% waterproof hardware. So while waiting to get a decent chance for the UTV1 to get it’s maiden flight, I thought I’d shortly describe a little tool I made to ease mission planning and execution.

The UTV1 has the ability to send and receive telemetry through the GSM net, which make it very appealing to spend a little time on making a graphical front end that can reside on a laptop, that allows you to see the usual stuff the drone GUI’s show (position, status etc), and also allows you to control the craft to some extend.

I’ve build my little GUI with inspiration from the control center of the Apollo era, with a simple button based interface, were buttons light up on error events, state changes etc.

The GUI also allows you to directly chat with the drone (video is included). I’ve kept the voice feedback, because this has proven to be very useful when your eyes is on the sky and not the screen.



1 - A text area that shows the raw messages that is being sent from the vehicle - great for nerdy debugging.

2 - A map area that shows the last know location of the drone.

3 - A text input field that allows you to chat with the drone for mission planning etc..

4 - A representation of the autopilot statemachine - the row of buttons light up as the vehicle makes it through it’s mission.

5 - Button that lights up when connection is established

6 - Button that indicates if manual RC-controller flight has been activated

7 - Button that shows if the statemachine has been brought into terminate mode (which just means that a pleasent glide landing is being attempted), can be manually activated or activated by the range guard mechanism.

8 - A number of warning lights that lights up in various scenarios (pretty self-explaining)


Telemetry can be updated 4 times/second but I keep it to a minimum 1/s for the time being.

Below you'll se a short video of how a set of waypoints can be entered by using the built in chat client - in effect you are actually talking to the drone :) This is a rudimentary first version, with fixed altitudes etc..


E-mail me when people leave their comments –

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

Join diydrones


  • First off, I don't use ardupilot, but rather a heavily modified MultiWii code running off a 2$ arduino board + a sensor board. But yes, the PI takes care of the over all mission execution and PID controllers for turning, altitude maintining etc.. and talks to the Arduino through a serial connection (wireless if the autopilot is located on the ground or wired if both PI and Arduino resides on the airframe). From the tests I've conducted so far latency is not so a problem, neither between the arduino and the PI (wired or wireless, homemade very tiny protocol) or the PI and the ground control, but it all depends on what you want to achieve :)

    I use a Huawei 220 for the GSM part. The Amazon project sound interesting!

  • I see , so let me get this straight. The banana pi talks to the ardupilot which in-turn has sensors connected to it. The connection over GSM happens via banana pi's USB-3G-Modem/Dronecell over XMPP to your laptop?

    Cool , I can see how latency is going to be an issue. I'm trying to do a very similar project.

    Pixhawk's TELEM 2 = GPIO from pi2 (2015 model). Use Huawei 2200 for 3G/GSM connected to the internet.

    Amazon EC2 connects to several of drones running similar setup. Users can talk to EC2 via TCP and there will be a queue maintained as to what the drone will do next and basically this queue is managed by authorized users.

  • Hi Anderson and thank you.

    1 - You are almost correct - the good people that make BananaPi's, sent me a demo unit - and with a little tweaking it ran even the low level GPIO (i2c and serial) without a problem. So I have a BananaPi + an Arduino (sensors) on board, and I use the XMPP protocol for communication. Definitely not the most efficient protocol, but easy to use because the BananaPi and the laptop I use for control, cannot communicate directly (because they are on two very different networks). The series of posts have also described the decoupling of the autopilot from the airframe, so another scenario  that would look 100% identical to the user would be were the autopilot also resided on the laptop. The onboard sensors (on the drone) would then transmit their data through a radio link to the autopilot on the ground.'

    2 - The video is at the bottom of the post - it just shows how you use chat to interact with the drone while planning a mission (it shows how a drone connected to the internet, is capable of resolving addresses to coordinates etc.).

    I'll try to focus more on video in the next blog posts, but it's difficult to get some usable footage while flying..

  • Very interesting , 

    1- How are you talking to the UTV1 over GSM? Do you have something like a raspberry pi connected over telem2 port?

    2- What about the video feature you were talking about?

This reply was deleted.