I wanted to analyze some data from a tlog file and figured that Excel would be the most flexible  way so I created a little utility to extract the data I was interested in and save it as a comma separated value (CSV) file. Each selected parameter is in a separate column, and Excel can open  the csv directly.

Note that it can't open the tlog file directly. You must use the Mission Planner to convert it to txt format. so:
1. From the APM Mission Planner Flight Data page select "Telemetry Logs", then "Tlog > Kml or Graph", then "Convert to Text". 

2. Select the tlog file you are interested in, and the Mission Planner will create a txt file in its log folder. 

3. Open the txt file in this program and it will parse the file and list the available parameters in the left tree control. Double click on the parameters you are interested in and they will be selected and displayed in the right tree control. If you want to remove a parameter from the selected list, double click it.

4."Save As" and provide an output file name. This will produce the csv file that you can open in Excel and plot as desired. The file will look like this, where each row was produced from one packet in the input file that contained at least one of the selected parameters.

If you want to re-use the list of parameters you can save and re-load them from the "configure" menu. These are simple text files you can edit directly if you like.

I am not familiar with the deloyment process for C# programs, so I have placed the entire project folder here. 

I would like to fly with live video and goggles, but this makes it tough to make any changes on the mission 
planner. To avoid any need to take off the goggles I integrated a series of menus in the OSD.

My setup, as reported here, uses a second APM on the ground.It monitors the MAVLink data stream with an XBee, drives a Remzibi OSD on a second serial port, and supports an Ardustation display and keyboard as a terminal on a third serial port. To make the menu selection as simple as possible I added a quadrature encoder using three of the unused inputs on the Ardustation (nominally the analog inputs, but setup as digital). The A phase of the encoder drives an interrupt, and the resulting ISR examines the A and B phase states to determine which direction the encoder know is being turned. The encoder includes a switch (push the knob in) that is connected to the third input.

The first time the knob is pushed the top level menu is displayed on the top line of the OSD with four selections plus an "exit". Turn the knob to choose the menu item, then push to select. Each selection, in turn, has up to four available menu options. Choices are:
1. Symbology - select between four symbology formats
2. WP - read waypoints from the Ardupilot, set to first WP to restart the mission, next to skip a WP, or previous to move back one.
3. NAV - set Auto, RTL, and loiter modes (yes, easier  to use the transmitter control, but I wanted to try out more of the MAVLink commands)
4. Timer - start, stop, and reset a stopwatch timer on the OSD.

The menus are turned off automatically after five seconds of no input.

I find that that this is a fairly easy way to control the system, and it can easily be expanded to include other commands.

All of the symbology is driven with the Remzibi "$M" command strings that are a bit limited in available  characters -  seems just to be letters, digits, and a couple of others. I can't use the leading and trailing character options for the strings as they take up more space. I would have preferred using something other than "X" to indicate which menu item is being selected, but that was all I could come up with. Hopefully the minimosd will have a more complete set of command strings, or be open source to allow me to improve the presentation.

You can find a video showing the system in operation here. I was in HIL mode so no satellite count, and the GPS time clock has random data (relies on a mod to the GPS library).

Latest code can be found here. It links with the Arduplane 2.27 libraries from the repository.

Andrew

While the progress on the APM Mission Planner makes it more and more attractive to bring the laptop out to the field for each flight, sometimes the simplicity and sunlight readability of the Ardustation is what I really need. The problem was that I kept adding more pages and busted the memory limit of the Ardustation. However, after upgrading to the APM2560 I had a spare APM1280 so decided to port the code over to that. While one approach would have been to directly interface an LCD panel to the APM I decided to re-use the Ardustation by writing some code to turn it into a dumb terminal. This code (“ArdustationTerm”) receives basic commands on its serial link from the APM to draw text and make beeps, and returns key presses. Someone recently suggested a shield for the APM to add Ardustation-like functionality – my approach basically gives that functionality using current H/W.

The code on the APM1280 (“ASMRemzibiOSDMAV”) runs all the page logic and communicates with the vehicle via the MAVLink xbee. It uses the markup format from the ArdustationMega code so fairly straightforward to change the layout. The only change I made to the code on the vehicle (starting from the current APM 2.21 load) was to pass the motor current via the gps hdop field as suggested by someone in these forums. If you don’t want to make the change just delete the current from the display definition code. The image at the top of this blog shows most of the screens, but there are a few more for parameters not shown. Lots of memory left to add more functionality as needed. Parameter adjustment pages are coded on a 4x4 grid of fields with either static text for a label, or a parameter name for dynamic data. I made pages for the parameters I am interested in, but easy enough to change them as you like. Parameters are automatically requested from the vehicle after the APM s started, and can be requested manually. Same thing for waypoints.

For the most part my code is just monitoring traffic on the MAVLink, so it will co-exist with the mission planner. You can also hook up a Remzibi OSD and generate symbology on the ground. I have limited success with this as the symbology tends to drop off if the video gets noisy – need to work on a better antenna and add the tracking logic.

The APM1280 uses Serial0 for standard loading and debug via an FTDI cable. Serial1 is for the xbee, Serial2 is for the ArdustationTerm and Serial3 is for the Remzibi.

I have made use of a fair bit of code from the Ardustation and APM codebases. I have tried to acknowledge this in the headers, but if I have missed something I apologize. Let me know and I will correct it. You can find the code at my Skydrive.

I won’t have much access to email for the next week or so, but will be able to get back to this the last week of August.

I am just starting out in FPV, putting together a HK airplane with video, Ardupilot Mega (APM) and a ground station. My end goal is to overlay computer generated symbology with camera video and/or a synthetic representation of the terrain - not quite there yet, but the flexibility of the APM with the availability of source code has convinced me that it is the right platform to build on.

However, I have got the APM running with xbee modules to communicate with an Ardustation Mega running the load from Colin as described here (http://diydrones.com/profiles/blogs/ardustation-twoway-telemetry). I made a couple of mods to get a display of GPS satelite count but this was primarily as a first Arduino programming exercise - the rest would have worked fine wthout the mod. The Ardustation is self contained with a LiPo in the box for power with the balance connector pinouts taken through the 9 pin D connector on the side for charging.

I then tried to figure out how to integrate a Remzibi OSD, but didin't find much on the web about using it with the APM (as opposed to the standard Ardupilot), and quickly realized I was out of comm ports if I wanted to have the xbees running at the same time. However, I had a spare APM (no IMU) so came up with a protocol converter - basically it reads the serial stream running through the xbees and sends out Remzibi 1.71 data on a second comm port. For the data that is coming out of the APM using the GCS_Standard protocol it works with the standard APM S/W load - S/W changes are required only to get access to data that is not already on the telemetry link. The Remizibi output code is derived from the Ardupilot 2.6 code posted by HappyKillmore for Remizibi integration as described in his thread here http://www.rcgroups.com/forums/showthread.php?t=1234310.

It was getting a bit tight in my HK FPV (even after cutting out a fair bit of the foam and gluing 1/16 ply for new sides), and while figuring out how to handle that I realized that the OSD does not need to be on the aircraft - it can equally well be on the ground. I packed the OSD and second APM into a little box, and hooked on to the Ardustation serial data from the xbee. As of today I have all the standard GPS data (lat,long,GS, altitude, date, time, etc.), APM mode, and artificial horizon.Date and time took some mods in the APM code, everything else was available.

Next is to use one of the spare inputs on the IMU to add a current sensor input and hook up the battery balance connector to the IMU for voltage monitoring.

One downside of moving the OSD to the ground station is that you lose the mAh counter built in to the Remzibi. It doesn't look like there is any way to send a command that substitutes for the ADC6 (default current sensor) input, so will need to add some code to either the main or ground station APM code to integrate the current sensor input. An alternative might be to run one of the PWM output pins of the APM through an RC filter and send that to the Remzibi ADC6 input.

Apart from simplifying the wiring in the aircraft, this approach means that I keep the OSD symbology even if the video link has problems (of course, I would lose the symbology if the telemetry link goes down). I  also have the standard video (no symbology) and the version with symbology available simultaneously, flying on one while recording the other if desired. Nothing in the implementation is dependent on the Ardustation beyond access to the xbee data (and that could always be handled by an FTDI to xbee adapter board), so I can move the Remizibi back and forth between the ground station and the aircraft without needing to change the code.

If I had thought this all the way through before starting the build I think that I would have used a larger box and integrated everything (Ardustation, Remzibi, second APM) into one unit.

From a quick look at the 2.0 code it appears that the "GCS_Standard" protocol has gone, so will require some rework to integrate the MAV link protocol, but I think that the basic approach will still be valid.

Won't get to test fly it for a couple of weeks, but it has been fun so far.