Ardustation as a terminal

3689419449?profile=original

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.

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Missed the video link in the posting above - here it is.

    I should have pointed out that it happily intercepts the MAVLink traffic from the plane to the mission planner. I have them both running in parallel.

  • I have updated the code to version 1.22 - saved in the same location. Remzibi support is in good shape (example in this youtube video), and the antenna tracker is working well (being used in the video). 

    I have two 1.28GHz receivers, one with the "IBCrazy" biquad. There is an Oracle diversity receiver in the large box directly below the antenna. Azimuth uses a Servocity gear drive. It has a hollow shaft so I can get the power and video/audio up through the middle.

    Antenna tracker  pages can be can be found by pushing the right button a few times until you see the real time display of the various range/bearing/elevation values. Select up from there and you get the azimuth calibration, and down to the elevation calibration. Calibration is via two end points with selectable angle and corresponding pulse lengths. These values can be changed directly, and are stored once changed. The azimuth page includes an offset value - set it to the direction you will be pointing the system for a zero degree servo angle (in my case 203 degrees which is perpendicular to the runway). You need to set the home position once - go up from any of the monitoring pages. I bring the aircraft close to the tracker once the GPS has settled down, then do the save. The value is stored, so no need to do it again if you put the tracker in the same spot. I need to do some more work on the keystroke sequences when modifying the parameters (not entirely intuitive), but it is functional.

    3692313270?profile=original

  • Developer

    Nice update  Thanks

  • Updated version at the same location as in the link above.

    1. Updated airspeed to pitch parameter names to match current Arduplane code

    2. Updated FBW mode name logic to match current Arduplane code

    3. Lat/lon field widths corrected

    4. The zip file now has the complete set of libraries from Arduplane 2.24.  The code really only needs a few of the libraries, but it is easier to keep current if I have the complete set.

     

    Andrew

  • 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.

     

    Andrew 

     

  • How is the skywalker coming along ?

    Heve you done any mote on this code ?

    Earl

     

  • Earl,

     

    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?

     

    Andrew

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

    Earl

     

  • 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.

    Andrew
  • 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.

    Earl

     

This reply was deleted.