What would you want in a mission programming language?

[FirmamentFX]

Hi everyone,

Just a general question to throw to the floor :-)

If you were to have a programming/scripting language for an autopilot, how would you want it to appear (at a code level - obviously GUIs could be then built around it)? The aims are to keep it relatively simple, so that you don't have to be a master programmer to plan a mission (although there would of course be a learning curve...)

As far as I can see there are 2 main ways of doing it: an XML based markup, or an object oriented language.

XML markup has the advantage of simplicity:


<mission>
<general>
<name>My Test Mission</name>
<date month="dec" day="22" year="2006" />
<pilotInfo>
<pilotName>Joe Bloggs</pilotName>
</pilotInfo>
</general>
<plan type="waypoint">
<takeoff>
<alt>2000</alt>
<ias>120</ias>
</takeoff>
<waypoints>
<wp id="1">
<gpsCoord lat="hhmmss" lon="hhmmss" />
<flightData alt="2500" ias="200" />
</wp>
<wp id="2">
<gpsCoord lat="hhmmss" lon="hhmmss" />
<flightData alt="2300" ias="170" />
</wp>
</waypoints>
</plan>
</mission>


etc... (this is horribly simplified but you get the point).

The problems I can see with this are:
- verbosity: having to define each tag and then close it adds a lot of data, which would mean that either a significant amount of extraneous data has to be uploaded to the UAV, or the plan has to be run through a compiler before it is uploaded. Either way it adds a lot of overhead.

The other way of doing it would be to use an object oriented instance-based language like javascript, where objects like $waypoint are defined:


define $waypoint(1) = array(lat,long,targetALT,targetIAS)
define $waypoint(2) = array(lat,long,targetALT,targetIAS)


It would then be possible to complete tasks based on conditionals (using IF, OR and ELSE parameters to determine if a certain set of conditions has been met before proceding to the next waypoint or taking a photo).

For example IF waypoint has been reached AND the aircraft is flying straight and level THEN take the photo, ELSE get straight and level. THENIF the waypoint has been passed return to the waypoint ELSE move on to the next waypoint.

It would also be easier to switch in and out of different autopilot modes and to define ILS landings etc.

This also has the benefit of being more succinct - "objects" such as waypoints and "functions" which can contain a whole sequence of events (you could write $approach or $finals functions for a certain airfield for example) which can then be reused. Also, updates to the aircraft mid flight would be easier as only certain objects need to be referenced.

You could go the whole hog and in the autopilot software itself (or the bridge between the scripting language and the autopilot) write an "Aircraft Object Model", mimicing the Document Object Model (DOM) in web browsers.

The drawbacks of this method are that it is a more complex syntax to learn and not as intuitive, although I believe it is far more powerful.

Of course, if a graphical frontend were developed that would ease the process somewhat.

Let me know your comments!

Best,

Martin

[Tom Harper]

Martin,

Interesting thoughts.

As you point out computer languages are verbose. Most of ones time is spent learning and correcting syntax and grammar. In this day of point and shoot wouldn't it make more sense to have a map up on the screen. Use the mouse to select a waypoint then select an action from a menu to associate with that waypoint. The on board system would store the waypoint and an associated command word, or just a word of flag bits that are evaluated by the flight processor.

Tom

[clolson]

Hi everyone,

Just a general question to throw to the floor :-)

If you were to have a programming/scripting language for an autopilot, how would you want it to appear (at a code level - obviously GUIs could be then built around it)? The aims are to keep it relatively simple, so that you don't have to be a master programmer to plan a mission (although there would of course be a learning curve...)

As far as I can see there are 2 main ways of doing it: an XML based markup, or an object oriented language.


I don't want to pretend to be too much of an expert in this stuff, but here's my view based on my experience.

XML is a great way to represent structured data, but it is a *horrible* way to represent procedures and logic. Yes, XML can be abused into a programming language, but it is extremely cumbersome, difficult to read the logic, and forces you into uncomfortable and unweildy constructs. You'll probably get halfway into it and start thinking about variable scoping and think, "Aha, I'll just embed javascript to handle that stuff" and now you end up with such a horrible mishmash, it becomes nearly impossible to program, read, debug, or understand what you are doing. If you want to be horrified, go look at VoiceXML which does exactly this form of XML abuse. You are supposed to script automated telephone systems with this stuff and it quickly becomes horribly incomprehensible.

If you want a really clean, really quick, really small footprint scripting language, take a look at "Nasal":

http://www.plausible.org/nasal/

This is has a "C" like syntax, it has some nice object oriented features, it's really tight and clean and small, and I highly recommend it.

I know the author and he writes the tightest, cleanest, well conceived code of anyone I've ever met in my entire life.

Just one more word of advice. Designing a well conceived, orthogonal scripting language with sensible variable scoping rules and a tight, efficient interpreter is not a trivial task. There are a lot of pitfalls and issues you will run into. I'm not saying don't do it, but just trying to advise you on the scope of what you are proposing.

I would recommend at least looking into some existing embedded scripting languages to see what they offer. There are quite a few out there, but there aren't many that are tight and clean and powerful and well conceived all at the same time.

Regards,

Curt.

[FirmamentFX]

In this day of point and shoot wouldn't it make more sense to have a map up on the screen. Use the mouse to select a waypoint then select an action from a menu to associate with that waypoint. The on board system would store the waypoint and an associated command word, or just a word of flag bits that are evaluated by the flight processor.


That would be possible for a waypoint autopilot system, but how extensible is it? It would be hard to store, for example, ILS landing procedures (which necessarily involve the complete range of funtions the pilot would do manually - set flaps, trim, get the correct rate of descent etc - especially as these are so dependent on outside variables like wind speed and direction etc).

I do like the idea of the point-and-right-click interface, but I think that would be a frontend and there would have to be some kind of scripting going on in the background. I will definitely look into it more - the simpler the better really.

I suppose you could just store data as flags in word bits and have the flags operate on commands that are already built into the flight control system.

Curt - thanks for the info on Nasal. I will take a look at it.

My flight control system is going to have several modules - the autopilot (which operates in several modes - waypoint, auto takeoff to cruise, cruise control, ILS, landing autothrottle, heading etc), the Automatic Flight Stablity System (which makes constant changes to the configuration of the aircraft to keep it stable), and the Response Control System (which adjusts the response of the aircraft to commands, so, for example, a trainee pilot could have the response of the control surfaces dampened, or a pilot who preferred the stick to have an exponential response rather than a linear one could set that up).

I only really want one language operating all those modes, but I want the system to be easily adaptable to other aircraft.

Martin

[clolson]

In this day of point and shoot wouldn't it make more sense to have a map up on the screen. Use the mouse to select a waypoint then select an action from a menu to associate with that waypoint. The on board system would store the waypoint and an associated command word, or just a word of flag bits that are evaluated by the flight processor.


Tom,

It seems like 99.99% of the autopilots are geared towards following a series of waypoints so I suppose that is what 99.9% of the people out there want to do, so your suggestion makes a lot of sense.

However, a full featured mission scripting language would allow the onboard autopilot to suddenly have a large amount of onboard intelligence. It could conditionally and dynamically react to external events or it's environment. Now I just have to come up with a convincing example of why a person would want to do this. :-)

Hmmm, imagine an autopilot that can be scripted to fly in formation with a lead aircraft. Perhaps you might want to script a series of flight test manuevers to collect data about the behavior of your aircraft so you could plug that into a flight simulator to do further refinement or testing or training. Maybe you want to set up a situation where the uav flies some search pattern, but if it finds or detects some condition or event along the way, then it could automatically start doing something else. Perhaps you could script out smart responses to problems ... such as what to do in an engine out situation, what to do if an onboard battery drops to a critical level. What situations do you panic and try to simply minimize ground contact force, what situations do you try to limp home, what situations should you abort the mission, but getting home is not a problem. A capable scripting language could do must or most or all of that automatically.

It's probably only of interest to 0.1% of the people doing uav work, but those people need some sort of alternative to a canned waypoint sequencing system.

Curt.

[LukeZ]

This is a very interesting discussion. I agree that an object-oriented language would be better suited than XML for this type of purpose. Though XML is still very handy, for configuration files and the like.

Nasal looks nice, but it seems to me perhaps that Javascript, being more universally used, may offer some advantages. For example, if multiple developers were to collaborate, it would be easier to find five of them with JS experience than with Nasal. Not that they couldn't learn it.

But if we're throwing out scripting languages ;) , here's another good one to look at: Lua (http://www.lua.org/about.html). The Windows automation tool Girder (http://www.promixis.com/products.php?section=girder) has made extensive use of it. In fact, the method that Girder uses to set up conditions, events, and actions in a graphical way would be good to look at in a project such as this. However I don't think the application itself was programmed in Lua (Visual C++ if I recall correctly), but Lua allows advanced users to "extend" the basic application in essentially unlimited ways.

Anyways, that's a bit off topic. I like the idea of a mission-definition-program-thingy, but here's the thing - I don't see it being too awfully useful in the absence of the end piece of hardware. No matter how easy and intuitive you make it, a person still has to translate whatever its output is into something their autopilot can run. That's not easy or intuitive. So I think you'd kind of need to develop it in tandem with some hardware, or else have a unit in mind perhaps.

But this is a very interesting topic, and a good one to discuss, even if it goes nowhere.


Luke

[clolson]

Nasal looks nice, but it seems to me perhaps that Javascript, being more universally used, may offer some advantages.
But if we're throwing out scripting languages ;) , here's another good one to look at: Lua (http://www.lua.org/about.html).

Anyways, that's a bit off topic. I like the idea of a mission-definition-program-thingy, but here's the thing - I don't see it being too awfully useful in the absence of the end piece of hardware. No matter how easy and intuitive you make it, a person still has to translate whatever its output is into something their autopilot can run. That's not easy or intuitive. So I think you'd kind of need to develop it in tandem with some hardware, or else have a unit in mind perhaps.


I envision the script interpreter running *on* the autopilot itself, embedded/included in the autopilot functionality ... i.e. the script interpreter would be flying onboard the aircraft.

I've never seen Lua, but I know it is popular. The downside to Javascript is that it has a large foot print.

Nasal is *very* C/perl like in it's syntax so it is not hard to learn.

I'm sure 99.9% of the folks out there who know anything about embedded computing think I'm crazy for even proposing the idea of running a script onboard the flight computer. I might just have to try it later this fall. :-)

[JeffElecRC]

The Paparazzi autopilot uses XML to script configurations and flightplans very similar to what you've described. The XML is compiled into processor-native code so that it can run on Atmel AVR or ARM7 MCUs.

[Tom Harper]

I think it would make sense to 'compile' the script into something compact for the on board system. Also the notation could be cleaner than XML. Something closer to C or Basic derivatives. A structure like:

Select Case "Waypoint"

Case = 1

Camera.Operate = True

Case = 2

Camera.Operate = False
Camera.Lens.Retract
Craft.Control.Circle Radius, Altitude, Number

Case = n

Else

Craft.Command.Home

End Select

Something like that - less punctuation.

[FirmamentFX]

Excellent! Thank you for your responses everybody.

In point of fact - I *am* developing hardware to go with this :D As far as needing a convincing reason to do it, I'm recuperating from an illness at the moment and have ALL the time in the world to work out my plans for total world domination!

Curt - I agree that the traditional "waypoint" method of automation is the most common, and that if an autopilot system were to be developed it should be far more open-ended and versatile. I do think that a form of waypoint management shopuld be implemented - if only to make it simple to set up common tasks in the autopilot.

One thought I had was to have a pre configured database in the aircraft of UAV airfields, their circuits, approaches, and departures (very much like the SIDs and STARs used in commercial aviation). That way, instead of having to program a departure and approach for every flight, the airfield could just be referenced (perhaps using ann $include function like that found in PHP).

For the database - again I had considered XML, bt it is still verbose, so I was perhaps thinking about MySQL. The entire flight control system of my proposed UAV will run on Windows XP SP2 Embedded (using solid state memory and micro-motherboards), and MySQL is a proven database system for speed, small footprint, and indexing ability.

Yes the script will be "server executed" - that is run on the aircraft itself. I would like if possible not to have to compile it, because that would complicate mid-flight updating.

The general idea is to devbelop a system that can be extended andmodified to fit almost any UAV. That would make the development time worthwhile. To that end I think the system needs to be modular.

Keep the ideas coming guys! :D

Martin

[FirmamentFX]

Another thing I had considered was trying to develop, in tandem, a localisation system for the airfield that could be used to fly circuits, approaches, land the aircraft, and keep it on the centerline. There is a lot of information out there (on the web) about localisation of robots using ultrasound, and I though that might be a way to implement it. I want to keep as far as possible away from Tx/Rx formats that commercial aviation use - like radio beacons and DF equipment.

The system would have to be simple - so that beacons can literally be put on the ground at points around the airfield. These beacons would have to be self-powering (battery or solar).

M

[Tom Harper]

Martin,

Hope things are going well.

I usually work with minimum systems. The bottom feeders of the UAV world.

Your scripting language sounds great for the mid to high end. After all a PC motherboard would fit in my Telemaster. Sounds like you are assuming up links and down links while in flight.

[FirmamentFX]

Hi Tom,

Yes I am assuming a telemetry link up and down in flight, using a custom RS232 protocol based on ASCII (so even using 19200baud comms, using 7-bit ASCII will give a wide potential bandwidth).

The idea of this is proof-of-concept (actually, a bet with a friend who wants to do it but reckons it's impossible...!).

M

[FirmamentFX]

Or perhaps use a "microwave landing system" instead of the ILS?

I'm just reading the JAA ATPL radio navigation manual.

What is necessary is a Tx/Rx system that uses unlicensed frequencies, and can be easily installed and derigged. Perhaps instead of using a glideslope indicator, the glideslope information could be mathematically worked out by a series of localiser beacons and the radalt in the aircraft. While this wouldn;t be acceptable for commericial aviation, for UAVs the safety features are less critical (but still important nonetheless).

This has the disadvantage that the beacons have to be placed away from the airfield, but then so do the circuit localisers.

Any ideas about another way to do this?

M

[LukeZ]

For the database - again I had considered XML, bt it is still verbose, so I was perhaps thinking about MySQL. The entire flight control system of my proposed UAV will run on Windows XP SP2 Embedded (using solid state memory and micro-motherboards), and MySQL is a proven database system for speed, small footprint, and indexing ability. :eek: This is an approach not typically taken. But I think it could have its advantages.

Another thing I had considered was trying to develop, in tandem, a localisation system for the airfield that could be used to fly circuits, approaches, land the aircraft, and keep it on the centerline. There is a lot of information out there (on the web) about localisation of robots using ultrasound, and I though that might be a way to implement it.This topic could probably be an entire thread to itself. It would be really cool to see someone develop this.


Luke

[FirmamentFX]

Hi Luke,

I came across these computer systems at http://www.mini-itx.com . My ground control station will be programmed for the win32 platform (I was considering win64, but I don't know if the support is out there for it yet...) so in the name of compatibility I think it would be best to keep it the same.

Having said that, the only communication protocaol is RS232, so theoretically linux or any other OS could be used. Linux could be more stable, but my experience of it is limited.

The MySQL database could be used to store any number of other things - performance envelope, parameters, whatever you want. The general architecture of my Flight Control System

I think I'm going to make this whole thing an open source effort. Those of us involved want to develop this thing properly and I think the best way is to get ideas and info from as many people as we can.

We have registered http://www.tornado-uav-project.co.uk . There's nothing uploaded at the moment, but eventually we are going to have a complete description of the Flight Control System (air and ground) and all the subsystems implemented.

A note on the name: The aircraft is a large scale model of the Panavia Tornado GR.4. We chose this because we have an inate love of all things RAF, we wanted to implement something unique (originally it was V/STOL, but that is very tricky at the moment so we went for swing-wing and fowler double-slotted flaps instead!), and the tornado can carry fuel in tanks under the wings, which leaves a lot of room in the fuse and on additional units that can be carried on pylons for the electronics. It is also an inherently stable high wing aircraft with slight dihedral...

I will start a thread on ILS/MLS and all things navigational.

Martin

[LukeZ]

My immediate concern with mini-itx, or any traditional "small mobo" is the current draw requirements, both for the motherboard itself as well as for peripherals (hard drives, etc). Of course the tradeoff is basically unlimited space and processing power (for this application anyways). But the battery drain will make this application a challenge for duration/long distance UAVs - though I suppose those are in the minority. This is one reason why I don't think I'm going to go with my original plan of using a PC-104 on my UAV (thinking of turning it into a music server for my car instead ;) )

Do you have an idea of how many mA your board might draw?

Not trying to poo-poo your project - I think it's a good one. As Tom said, this application would have its place: towards the higher end UAV market.


Luke

[FirmamentFX]

My immediate concern with mini-itx, or any traditional "small mobo" is the current draw requirements

I'm not too concerned about that - There are 2 options for power:

1 - The turbines in the aircraft will have a second stage with generators (http://www.sullivanproducts.com/GenesysMainFrame.htm)

or 2 - there will be a dedicated small turbine in addition to the propulsion turbines. The fuel draw requirement should be minimal (when compared to the equivalent weight battery packs would need), and the aircraft will be able to carry plenty of fuel.

M

[LukeZ]

I'm not too concerned about that - There are 2 options for power:

1 - The turbines in the aircraft will have a second stage with generators (http://www.sullivanproducts.com/GenesysMainFrame.htm)

or 2 - there will be a dedicated small turbine in addition to the propulsion turbines. The fuel draw requirement should be minimal (when compared to the equivalent weight battery packs would need), and the aircraft will be able to carry plenty of fuel.

MYep, that would work. And it sounds good. But again, we're talking high-end here (turbines? Three of them?)

And that's ok - just good to know the intended application.


Luke

[LukeZ]

Good lord! I just went and looked up the Panavia Tornado (http://en.wikipedia.org/wiki/Panavia_Tornado). :eek: I'll say this, you're ambitious!

I might have some reservations about this claim:It is also an inherently stable high wing aircraft

;) Luke

[FirmamentFX]

Good lord! I just went and looked up the Panavia Tornado (http://en.wikipedia.org/wiki/Panavia_Tornado). :eek: I'll say this, you're ambitious!

I might have some reservations about this claim:

;) Luke

It's the culmination of many years' worth of building and flying large scale RC aircraft :)

[FirmamentFX]

I've just found another potential benefit of scripting - all the autopilot modes and behaviours can be scripted (for example HDG/TRK, LAND, flare, rollout, RWY TRK etc).

The flight plan could simply be an extension of that, using an include() function.

This would involve having the scripts executed higher in the system heirachy (the way I have it currently planned, the Flight Guidance & Management System is the top level of control, below which you have the Flight Management System and the Flight Guidance system - the FMS controls the flight plan, and the FGS controls the autopilot, autothrottle, flight director, and failsafe controller).

This also has an additional benefit in extensibility - autopilot modes can be changed and modified more easily to suit different aircraft.

M

[FirmamentFX]

:eek: I'll say this, you're ambitious!

Luke, just a point on this (not that I feel I have to justify myself ;) ) - the original plan was to create a "test bed" and do a giant scale commerical airliner - either a 747-800 or an Airbus A380 (I was in favour of the 280, because it's so damn cool - and I am living about 80km from Toulouse at the moment! :D ). We could then test the flight computer in a less "stressful" environment and with more gentle handling characteristics, before building the fast jet.

The problem we had with this was that even a giant scale model is inherently going to have a narrower fuse than a jet with a 3 or 4m wingspan, simply because the length and wingspan are so much greater.

Bear in mind, although we are interested in the technical characteristics of these systems, we also want to make a f*****g cool plane! :D We're in this for fun, even though we take it very seriously...

:D

Martin

(PS: I still want to do the A380....!)

[FirmamentFX]

Ok I've been thinking about this, and here's another possible way to implement it:

Program a "traditional" autopilot system (following lateral and vertical flight plans), but have a scripting language that can deal with all the other aircraft functions (for example camera triggering).

The flight plan can then "call" scripting functions at certain points.

M

[FirmamentFX]

Update - after much argument the past 2 days, we have agreed to do a commericial jet first, and in the interests of keeping already high costs down a bit, we're going to do the airbus A320 (2 engines not 4, or with the APU, 3 engines not 5!).

I also came across a software system called "Project Magenta". It is a display generation system for simulators, but can be integrated to fit in with other systems. The airbus version of their software is what we will be using for the ground displays.

Regarding the autopilot/autoland system - after detailed studying of the Airbus 320 operating manual, and looking at other R/C & UAV autopilots, we have decided to inplement a traditional autopilot system (a simplified version of the airbus one), and also a separate module called "COPILOT", which is the scripting language executor which will allow us to control the aircraft.

The architecture works something like this:
Data received from the ground is fed into the computer system. If the data is calling a script function, it goes to the parser, which then turns the script into the same type of computer commands that would be seen if the pilot was manually flying the aircraft. These commands are then sent to the flight control system. The FCS sees exactly the same type of commands if it was in manual flight or automatic.

The autopilot (AP) is then a separate system within the FCS: The way one would turn it on in COPILOT mode is to have a function that turns the AP on in a certain mode, or edits the parameters of the AP. The scripts could do anything - set the flaps/slats, turn the landing lights on or off, take a photo, even complete checklists automatically. If there is ever a FAIL response to a script function, the pilot gets notified and can take the approproate remedial action(s).

Initially the scripting processor will be in the ground unit, but in phase 2 of the software (ie when we've got the bugs ironed out) we plan to transfer it to the aircraft for completely automated flight.

Cheers,

Martin

[hugo_vincent]

FirmamentFX, regarding Project Magenta and your ground station, you might also want to look at OpenGC (www.opengc.org). The project seems almost dead, but I have been working a lot on a fork of the code for my UAV project (www.albatross-uav.org). I have changed a lot around; the display is fully described by XML now, it supports data input from FlightGear (open source flight simulator) or from my UAV comms link. There is a kind of old screen shot here:
http://www.albatross-uav.org/index.php/Image:Opengc-basic-nav.png

I have been trying to modify the display to suit what works for UAV operation. A Airbus UI is very good if you're sitting in the aircraft, but I'm convinced something much better suited to UAV operation is possible (note as you can see in the screenshot, I'm still a long way from there).

Anyway, Project Magenta is closed source and in that respect, hard to modify. OpenGC, or my fork of it, are open source, which gives you much more control.

I haven't released my fork yet, but if you or some of your team are passable C++ programmers (ideally with some graphics or OpenGL experience), I'd love you to work on my fork with me. It will be GPL licensed when released.

Hugo

[FirmamentFX]

Hi Hugo, thanks for the post. OpenGC looks very interesting! Let's talk more about it.

When you say the display is described by XML, is that the display functions, or the actual look (or both)?

The data input is another source of interest - I assume it can be modified to accept data from almost any source? The reason I ask is that the communication protocol we are developing is based on ASCII RS232 - all the aircraft data is encoded into an ASCII stream on the aircraft, sent through the downlink, and then decoded and passed into the Display Management System (which processes it and generates the display data).

I agree that having an Airbus "cockpit" layout would not be the best way of doing things. However, we want to be true to the different systems on the Airbus - ECAM, PFD, ND, MCDU etc.

Something that may also be of interest - we are also developing hardware to control the aircraft, comprised of 2 mini thrust levers (with detents), a sidestick, and a custom keypad (split into the various areas of operation - FCU, EFIS, MCDU etc). All this interfaces with the laptop via a USB link.

Best,

Martin

[FirmamentFX]

Ok these images should give you a more detailed overview.

The display system doesn't yet include the MCDU.

[hugo_vincent]

Thanks FirmamentFX, you certainly have a very very ambitious project on your hands!

In OpenGC, each object displayed on the screen is a GaugeComponent. When I say the display is described by XML, I mean that the layout of GaugeComponents on the screen is loaded from an XML file that is very easy to edit and change. The GaugeComponent's already in OpenGC include things like the PFD, the speed and altitude tickers and tapes, the compass, the navigation display, the engine instruments (EGT, N1/N2 in your case, RPM/tacho in our case), etc.

To add new GaugeComponents, you write a C++ file that uses OpenGL calls to draw to it's part of the display. To add your GaugeComponent to the display, you add a few lines to an XML file that say where it will be on screen and how big it will be etc.

OpenGC also handles the loading and management of basic nav data such as airports, navaids etc., so it is also comparitively simple to write quite sophisticated navigation GaugeObjects like a horizontal situation indicator or a moving map type thing.

OpenGC wraps most of the hard stuff, so even if you've never coded for OpenGL before, but can write competent C++, you should have absolutely no problems writing new GaugeComponents.

The data input into OpenGC is handled by DataSource objects. There are three in my fork at the moment: one to receive data from FlightGear, one to receive data from my UAV, and one to generate plausible looking random data to test OpenGC with. I am also working on one that would be able to receive a generic protocol described by XML, based on the "generic" IO module in FlightGear (it supports basically any ASCII and many simple binary protocols). In your case, you would either be able to use this DataSource when it's finished, or write your own DataSource that reads RS232 data from a serial port and decodes it appropriately.

Hugo

[clolson]

This might be overkill for a ground station, but you can also do quite a bit of gauge development in FlightGear. All the instruments are created and animated using XML config files so there is no coding necessary. All you need to do is pass in the correct information and the gauges will begin to animate.

Also check out the "open eagle" project at http://www.cobbin.com for some more cool stuff along these same lines.

Regards,

Curt.