So, I'm developing a ground station for iOS devices (iPhone/iPad) and after making a lot of progress, I came upon a major stumbling block. I can not wrap my head around how the mavlink protocol works. The iOS side of the project is easy but i'm stuck on how the messages are generated/formatted. 

Btw, I already worked out how to send serial communications to and from the iPhone (Jailbroken) and I'm finishing up an xbee docking prototype that attaches to the back. I just don't have an ardupilot mega yet and won't have one for a couple months. I really want to start working on the program so I need any help that anyone can offer.



Views: 10321

Reply to This

Replies to This Discussion

It may not help much, but I wrote a mavLink wrapper for android phones. Looking at that stripped down code might give you the insight you need to do the same on iphones copter-gcs/jni/

parseFunctions.h is a good start

The basic idea is that you receive a byte, and push it into mavlink, until it says good decode (gets you a mavlink_message_t& message), at which point you would (example is for a heartbeat packet):

message.msgid gives you a constant, i.e., MAVLINK_MSG_ID_HEARTBEAT so you know what type to decode


mavlink_heartbeat_t inp;

mavlink_msg_heartbeat_decode(&message, &inp)

and read the appropriate fields from inp struct.

on the way out (to send), simply pass the fields as (again for a heartbeat):

mavlink_message_t& msg

uint8_t system_id = 255;

uint8_t component_id = 0;


mavlink_msg_heartbeat_pack(system_id, component_id, &msg,type, autopilot);" where 


and any remaining parameters are what is being sent out, as per the headers. After that you can just bang out the bytes over the xbee.

Anyway, might be worth a look, as it does exactly what you want, except it does it on android.

Looking forward to seeing a GCS for iOS:)



Thank you so so much!!!! its like a lightbulb just went off in my head! 

But basically, I would interpret the heartbeat message using the parameters defined in all the xmls? 

 <message name="HEARTBEAT" id="0">
     The heartbeat message just shows that a system is present.
     <field name="type" type="uint8_t">Type of the MAV (quadrotor, helicopter, etc., up to 15 types, defined in MAV_TYPE ENUM)</field>
     <field name="autopilot" type="uint8_t">Type of the Autopilot: 0: Generic, 1: PIXHAWK, 2: SLUGS, 3: Ardupilot (up to 15 types), defined in MAV_AUTOPILOT_TYPE ENUM</field>

And I would write code for each type of message I receive? Like if i got a heartbeat message I would make make sure the GCS is setup for that type of aircraft and the type of autopilot? and set a timer so that if I don't get a heartbeat ever "x about of time" passed, I alert the user to take manual control immediately?

P.S.- I am planning on making the Xcode project open source on my website but do you think it would be asking too much to charge $0.99 or $1.99 for the prepackaged version on Cydia?

Have a look at the autogenerated implementations of Mavlink, there is C and Python already - and I have an unofficial (but working) .Net 2.0 version in a clone. If you are going to do a obj-c version, then you should aim to write a generator rather than hand implementing. There may be one out there already, who knows

As learning - apart from the wiki & docs, there are a few 'sundry' python tools which process mavlink log files etc which are worth looking into.

I don't really understand what your are trying to say. What do you mean by a "generator"?

I think I understand it all now and I am starting on an Obj-C wrapper for the MavLink protocol. It would be a lot simpler to implement into my app versus using C/C++. I was thinking of creating an object that handles all of the receiving and sending inside its class and can get/send messages with one method call. This is what i was thinking:

MavlinkIO autoPilotLink = [[MavlinkIO alloc] init]; // create autoPilotLink object of MavlinkIO class and initiate link

[autoPilotLink sendMessage: messageToSend]; //Send Message

mavlink_message_t  message = [autoPilotLink getMessage]; //Recieve Message

What he means is that the MAVLink protocol is specified using a file, which states message ids and fields /sizes for each packet. The generator takes that specification, and generates code for it.

For me, it was much easier to leave the c++ code alone, and using JNI (c++ code in java), simply wrap the functionality. I created a generator that took the C++ mavlink functions and generated additional JNI code as a go between. I'm not familiar with Obj-C/iOS, so can't really comment on the specifics for that.

Yeah like Bart says - the mavlink protocol is defined in an XML file - there is a generator written in python that takes that XML definition and spits out mavlink parsing/generating code for C++/C, and python (and my one does C#). That way, changes to the mavlink protocol only have to be made to one file (the master XML definitions file), not multiple different implementations. Also it means that it is easier to generate a library for the different 'flavours' and versions of Mavlink - i.e Arducopter, PixHawk, etc

You should really look into this, it will generate what you are proposing to write, except it will be a lot less work for you, and probably less buggy too. 

oh, i see what you mean now! And yes, I plan on it! I feel stupid now ;)

If you do an iOS app I'll be the first to buy it :-) But please include a Bluetooth-Serial option - I use Bluetooth-APC220 convertor (no need for a XBee dock) - the same can be done with XBee and it's much more universal (you can connect anything that has bluetooth - which is, well, everything :-))

Making a convertor costs $8, dock is clumsy and connector specific...

Thanks for the interest!

I'm going to release the first version that only supports plugging in a custom dock connector that I am going to post plans for on my website. The cost would be about $30 in parts to make it (I think at least).  After that I am going add support for bluetooth and wifi also. 

Since the phone will have to be jailbroken it make it a deal breaker for most people and to fix that I will release a wifi only version that will be available in the official app store. (the dock connector requires root access and apple charges tens of thousands of dollars to have a iPhone bluetooth device but wifi is allowed)

Also, what features would be good ones to implement? I'm thinking just status monitoring and simple commands on the iPhone while a full ground station on iPad.



Hmm, and do they allow Bluetooth Serial? That should at least be easy with root access if they don't (IMO).

For now I use Copter GCS on Android - I think this one needs to be at least as good or it's just more feasible to get an android phone.

Personally, I'm not getting a dock, not even for $1, sorry, and you can get an old android phone for $30 nowadays :/ I'm going to give you $20 for the app alone easily.

I use something like this: just smaller powered by USB or 18650 battery - easy to carry around. And with bluetooth - you can connect with laptop just as easily as any phone. No dock for me, sorry.

First, I don't really plan on many people using the dock method, as it is mostly for my testing purposes(simpler, easier to trace problems) and for people who have a old iOS device and want to permanently attach the dock to the device. The iPhone/ipad powers the xbee so its a very reliable solution.

But, Apple doesn't allow bluetooth serial but there are bluetooth stacks available from Cydia that can be used. And I was actually planning on making it with bluesmirf compatible as soon as I can get the basic features working. Also, I want to try and get it working with a WiFly because the cost about the same as a bluesmirf, will work with a laptop also, and don't require root access(non jailbroken phones can run it). 

Basically, I will implement as many different ways to connect to the xbee so that more people can use the app. And, since i'm just starting development, my app will be behind Copter GCS but i hope to catch up!


Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service