Interfacing Ardupilotmega with Labview with Mavlink Protocol

[Shadowclaw]

Ok, if you haven't already read through this page do so: http://qgroundcontrol.org/mavlink/crc_extra_calculation.  The field reordering caused me more then a few headaches.  (The fact that I had 3 three days to make this work before a group of highschool students would be using it for a robotics summer camp didn't help either).  Anyway, the gps parse may or may not be correct for the default gps message that is sent.  I remember I was messing around with the rover code as well to get everything working but that shouldn't be a big deal.  Also I had disabled all of the failsafes on the rover side because I didn't have time to implement the heartbeat.

Anyway on to the code.

Assuming you have read the table at the bottom of the "start" page on the wiki and understand the message header packet setup, lets begin.  

CRC VI:

First off, in my code it was easier for me to implement the checksum as a dll call, though I believe there are pure labview implementations of it around, Because of this and the fact that the checksum does not include the start bit (0xFE) the CRC vi accepts a message, determines the correct MAVLINK_CRC_EXTRA number, calculates the checksum and adds both the start bit and checksum to the output message.  The VI will also verify that a received message has a valid checksum

initialize VI:

all this one does is turn off all data streams, then turn on the ones that I needed.  Remember System ID 255 is a groundstation and my component ID was 190

Read VI:

First read one byte, if its a start byte read the next 5 (the message header), than read the rest of the message based on the payload length in the header plus 2 bytes for the checksum.  After a message is read check the CRC, if its valid put the message into the queue, if not ignore it.

Parse VI: (the one you probably care the most about)

Pull one message out the queue, add the ID to the list of received IDs if not already there.

Based on the message ID parse the message.  This is were things get hairy.  Because the messages are dealt with at bytewise level you have to convert the string to a byte array first.  After this you have to split the array based on what data type in the message it is. (uint8 is one byte, uint16 is two and so on)  Then you need to reconstruct the data into labview types that you can do something with.  This is were the field reordering and the fact that everything is little endian come into play.  This can be handled in any number of ways but the easiest in my opinion is using array subset, then reverse the subset array (I didn't always do this because as soon as something started working I moved on to the next one.), then typecast the array into the data type defined in the message.  I don't think the RAW IMU parse is correct because we didn't used it, so I never fixed it.  Heartbeat, System Status, RC, GPS, and Attitude should all be good though.

Also remember that any messages you send need to be little endian and field reordered as well.

[jose.r.linares@aero.org]

Great example Just diabled Joystick for me since I'm not using it. and it works right off the bat. Thank you for taking the time in replying I will study your code and get back to you if I have any questions.

Thanks aging

[SaidElshayeb]

gr8 help, thnxx 

[maxmus83]

ShadowClaw,

Thanks for the great example.

I am now able to read the entire message and parse it correctly, and starting to work on the implementation to front panel gauges with the various datas that are present.

Now, I am trying to send an "ARM" message, how would one structure a packet so the arducopter will accept the message and begin the arming sequence? I am doing this safely with props off, and a primary control transmitter near.

I am lost where I might need to produce my own message ID and sequence and etc... Any light on the subject would be appreciated.

[Shadowclaw]

So in my example I would suggest using an Event Structure in the loop with the RC OVERRIDE vi in it, but really it could go anywhere so long as you are keeping track of your sequence number correctly.  In order to send a message the data payload of the message must be packed as little endian hence why in the joystick message the low byte is added first.  Also you will have to make sure that you reorder the fields properly if there are multiple data fields.  If I remember correctly the larger fields are first then the smaller fields. (U32 then u16, etc) if there are multiple fields of the type then the order is whatever is listed on the Common Message Specs page. (Mavlink Messages) (Field Reordering) For example in the RC OVERRIDE Message (70) there are 8 uint16s (one per channel) and two uint8s (target system and component).  Therefore the 8 uint16 are first in the order listed (channel 1, channel 2, etc) then the two uint8s are next in the order listed (target system then target component).  My example was being used to control an rc car using channels 1 and 3 whose system ID was 1 and component ID was 1.

So for an "ARM" message you have to look through the MAV_CMD enum to locate the one you want, CMD ID 400 in this case, and we see that it only has one parameter: 1 to ARM, 0 to Disarm.

This enum is used with msg ID 76: Command Long through with this msg I believe that you can leave out the extra parameters that are not used but I can't remember so you may have to play with it a bit.

At this point its just a matter of building the byte array for your message with the correct field ordering, calculate the checksum, add the checksum, start byte, and sequence number, and send the constructed message to vehicle.

If you are using my checksum VI just remember that it will add the start byte to the message byte array so when you are building the array start with the payload length byte.

Good luck getting in the air!

[maxmus83]

So I'm using the labview program I've written to "sniff" the data in between the GCS and MAV. 

Thanks to your insight shadow, I was able to catch the arm packet. It looks like this:

21AF FFBE 4C00 0080 3F00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0090 0101 FA00 97B4

21C5 FFBE 4C00 0080 3F00 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0090 0101 FA00 DD8F

So I should be able to just send that over the serial modem to get it working....? 

[Shadowclaw]

Kind of, you will have replace the sequence number with the correct number and update the checksum accordingly but if that is the ARM message (Don't have any code in front of me to decode at the moment) then it should work.  Just remember that if it doesn't work after two or three tries stop sending the message as spamming your vehicle with an unknown command could put it into an unsafe state, it would be best (it this case) to power cycle APM and restart your control code every so often to ensure that there are no messages getting backed up.  This way you know exactly what message is being sent and received when you hit "send".  Once you get msgs/commands working between the vehicle and groundstation this will become less of an issue.

[daniel2222]

Hi,

thanx a lot to Shadowclaw for the nice clean code...

I´ve finde out some Meassages for Cam Gimbal ( Mount ) ... Maybe usefull for anybody...

I still work on a Primary Flight Display for this Project..

[SaidElshayeb]

please keep us updated, thnx

[SaidElshayeb]

MavLink CRC ??