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.

Views: 1479

Comment by Mark Colwell on August 13, 2011 at 8:21am
Good Stuff, Looking at code now,
Comment by Earl on August 13, 2011 at 8:23pm

Great. Got it working here.

The lon is missing the first digit. A -sign then 06.197 not -106.197 ........

Other than that it seams to work fine.



Comment by Earl on August 14, 2011 at 12:59pm

I found the fix ! make field 10 not 9

        fieldWidth = 10;  //was 9 - Earl changed to 10 to accomadate -106.55555


Comment by Earl on August 14, 2011 at 3:04pm

Comment by Earl on August 14, 2011 at 6:16pm

I see why you had only 9 digits. Your at -73 long and I am at -106 needing 10 digits.

Your program is great. I may add some pages for xBee RSSI and a graphics screen showing the plane.



Comment by Andrew Fernie on August 15, 2011 at 6:30am
Sorry about that. I checked Montreal (-73) and the default xplane field (Innsbruck?)so missed the 3 digit scenario.

I don't have access to my PC this week,so thanks for tracking down the fix.

The xbee and graphics pages sound like a good idea.

Comment by Earl on September 6, 2011 at 8:36pm

Any more work done on this with the exception I implemented the xbee's in the data loop?



Comment by Andrew Fernie on September 7, 2011 at 6:46pm



The files I have posted have your fix for the longitude display, but that is about it. I crashed my plane (HK FPV) a few weeks ago when the elevator horn pulled off so all my time has been spent on putting a Skywalker together, My next priority is antenna tracking.


Has anybody else given it a try?



Comment by Earl on September 14, 2011 at 12:23pm

How is the skywalker coming along ?

Heve you done any mote on this code ?



Comment by Andrew Fernie on September 15, 2011 at 3:26pm

No more work on the code, but at least the Skywalker is flying. What a difference compared to the HK EPP FPV.

1. Loads more room. I had carved out much of the foam fluselage sides on the HK and replaced it with light ply to get some room but it was still tight. No problem with the Skywalker

2. I had been hearing that the CG should be aft of the aileron wire slot, but that was to far back for my liking. I am now slightly forward of the slot and it seems to be better. Not sure if the different versions have the slots at different locations.

3. Flys better than the HK. Generally better behaved (with the right CG), and less power required.


Couldn't get the xbee to work - continually getting bricked (with 2.24 from the planer). Must be something in my wiring.


Stablize and FBWA seemed fine, as was RTL, with the default gains. Some of the suggested Skywalker gains seem higher than I was expecting, so will work them up slowly.





You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service