My Airbus UAV project

[FirmamentFX]

Just an update on the project (see other threads for more info) if anyone is interested! :)

The final decisions on the UAV development have been made:

Onboard Systems

- Aircraft control system will consist of a master computer which provides flight control / autopilot / ATHR / Nav and processing functions, and also parses COPILOT scripts (see below).

- Also within the UAV will be several custom hardware modules:

-- Sensor Data Acquisition Controller (SDAC) : collects and processes all the raw data from the aircraft sensors (air data, GPS, inertial reference etc). The data is fed from a simplex (one way) bus to which all the sensors are connected.
-- Aircraft Monitoring System : monitors the state of all the systems onboard (and signals being received) and manages degraded performance in the event of a failure (also hard-wired to the backup Futaba receiver which is again directly connected to essential servos and actuators).
-- Flight Control Data Concentrator (FDAC) : this takes the command outputs of the master computer and passes them to a digital bus running all around the aircraft. Connected to the bus are microcontrollers which output to the actuators. The bus is full duplex, and positional sensor data is also sent from the sensors connected to the control surfaces to the FDAC, which processes it in the same way as the SDAC does for air data and the other sensors.
-- The radio modem.
-- The FDR - a solid state recording system to record all the flight parameters.

All these modules (including the modem and master computer) will be connected via an onboard ethernet link, which will also be able to accept an ground connection to the pilot computer.

Although complex, this system is very flexible and new modules can be added simply by plugging them into the hub.

The master computer will run Windows XP SP2 (or perhaps Vista - depending how long it takes) 32 bit (not bothering to update my compilers or runtimes with 64-bit versions - it's not worth it!) with GUI mode disabled (the control software will be a Win32 console application programmed in C++).

Ground Systems

The ground software will comprise of a custom programmed interface (in C++ with .NET 2 managed extensions and openGL for the graphics) which comprises of a virtual glass cockpit and video link from the aircraft (switchable between 3 or 4 onboard cameras).

The glass cockpit module will also include a display of "pushbuttons" and LCD displays which will show the state of aircraft systems. A custom keypad with data entry wheel will be connected to the laptop to provide an interface for the pilot (along with the throttle and joystick).

Another module will be the simulator module - this interfaces with the SDAC (to transmit false sensor data) and master computer [with the exception of the throttles and fuel sensors which are "virtually" simulated] when connected on the ground (and the aircraft is jacked up - ie the jacking sensors are compressed) to simulate the aircraft in flight. The system is totally transparent to the aircraft computer - it doesn't realise it is being simulated. Data can either be programmed or read from an FDR dump file. The simulator will be able to parse COPILOT scripts and fly a virtual mission.

A third module is the FDR dump system - which literally just asks for and then accepts a data dump from the FDR (in ASCII format).

4th module - COPILOT scripting language. Details to be set at a later date.

The final module is the interface module with a flight simulator (FS2004 or Flight Gear - no need to reinvent the wheel totally :D ). This can accept data from either an FDR dump file or be a live link "in flight" (depending on processor speed or alternatively another system networked into the ground control station).

Aircraft Design

As far as possible, the design will be of the A320. The differences will be:

- The airfoil and horizontal stabiliser : We are currently simulating airfoil shapes using fluid dynamics to find the best shape for the size of aircraft.
- Flaps will be double slotted, not triple (for ease)
- Extra thrust fot T/O may be provided by the "APU" turbine in the tail of the aircraft.


Very complex project, but should be a laugh!

Incidentally, and sort of on-point.... I am considering (very strongly) the possibility of quitting my orchestral career and reapplying to uni to study avionics engineering. I started an elec engineering course 7 years ago but quit when I got my first big conducting job. I'm slightly disillusioned (well, VERY disillusioned) with the music and theatre industry... :rolleyes:

Cheers,

Martin

[philthyy]

Ok, I'm beyond fascinated! What a HUGE project! Do you have any pics yet?

[FirmamentFX]

I should have some images soon - not photos though (yet :rolleyes: ).

The physical design is being done in AutoCAD and Rhino 3D, with some of the smaller and more complicated elements (undercarriage) done in Catia V5. I'm learning Quest3D at the moment, so hope to have a 3D virtual aircraft I can put on the web soon.

CFD (Computational Fluid Dynamics) analysis of the airfoils is being done using Fluent for the complex stuff and Flowizard for the generic models (hey, it's cheaper than a wind tunnel :D ) - these will be the first images available methinks, because the analysis will be among the first "physical" things done. (Just waiting for my Fluent update/support CD to come through the mail because they released a new version recently).

We're developing and simulating the circuits and hardware modules in MatLab and Electronics Workbench. MatLab will also be used to create some of the DLLs and program some of the microprocessors for processing flight data - I believe you can compile them in MatLab and link them into applications as a COM object (or ideally a .NET class if I can figure out how to do that).

Something else I meant to mention in my previous post: Flight envelope limitations and a host of other data relevant to the performance of the aircraft will be held in a MySQL 5 database, accessible on the network from any of the modules. I might also implement a "QAR" feature which records to the database - recording only vital information for the flight. The FDR will remain separate (that way if the computer goes down at least the FDR will keep recording while we fly it in "direct" mode).

As I said before, this is a very complicated way of doing things to achieve the desired aim of this particular aircraft, but it gives us an extensible base to work from - other modules can be added in simply by plugging them into the oLAN (Onboard LAN - a Boeing term even though this is an Airbus :D ), and sensors and servos can be added simply by connecting them (via a small module) to the data bus. This avoids the need for physical "plugs" or "ports". Of course there is a theoretical limit to how many items can be connected to a data bus, but in the real world that limit stays theoretical - it is in the 40s or 50s, and could never realistically be achieved in a UAV (for weight reasons if nothing else!!).

Will post a system overview soon.

M

[FirmamentFX]

Ok here's the draft system overview. It doesn't go into too much detail about what does what, but it's pretty easy to figure out.

Anot: I am toying with the idea of integrating the CFDIU (centrailsed fault data interface unit) with the aircraft monitoring hardware module. I just need to run a few simulatiuons to see what would be more efficient.

M

[chopsuey]

Very ambitious but very cool at the same time, keep us posted as I am very interested!

[Unterhausen]

I can't imagine a Vista computer on-board any aircraft. There are third party real-time versions of Windows, and Microsoft is making noises about embedded versions. I have long, sad experience with windows controlling things. Wouldn't want windows flying something over _my_ house.

If you go back to school to become an engineer, it will take forever before you have this kind of money to work on projects again, if ever. Engineers are overworked and underpaid unless they work for themselves. And working for yourself as an engineer is a bit of an iffy thing without more credentials than just an undergrad degree.

[hugo_vincent]

Hi Martin,

You have a very interesting and exciting project on your hands!

Couple of suggestions:
* think long and hard about the complexity and flexibility vs. simplicity tradeoff.... the first version of our project's hardware and software (Version 1 Albatross http://www.albatross-uav.org) eered on the side of complexity and flexibility (rather than simplicity), and despite IMHO good engineering, took longer to get going and wasn't as versatile as we would have liked. Doing it again, like we are at the moment with our Version 2 hardware and software, we are simplifying things quite a lot, at least at the systems level (some of the specific hardware blocks are more complex, but the way they fit together will be simpler).

* rather than re-inventing your own onboard data networks (FCDB and SDB) use an established system like the CAN bus - it's very reliable and well understood, and used in safety critical applications (with care) reasonably often. You can buy one chip solutions and buy software stacks for a variety of processors. Using it will take a big unknown out of your system (at least as far as reliability is concerned). And you will still have full flexibility. Plus you can buy USB-CAN adapters for easy development or debugging of your network.

* rather than writing your own scriting language (COPILOT), why not build it on top of an existing language like Lua, Nasal or even XML (depending on your needs). Both Lua and Nasal are free and are very fast, don't need much memory, and are portable. Writing a set of libraries or modules in one of these languages would almost certainly result in a more reliable, more flexible system, that won't take as long to develop.

* as suggested above by Unterhausen, perhaps consider an alternative to Windows on your main flight computer. Even if you don't want to use Linux for whatever reason, look closely at OS's designed for real-time control applications. For PC hardware, QNX or VxWorks are a very compelling alternatives. Both are hard-realtime, solid as a rock, and have been used in many **very** critical applications, like spacecraft or nuclear power stations. You can still code in C++, although most RTOS's tend to have a more Unix-like structure and APIs than what I presume you are used to in Windows. MATLAB/Simulink supports code generation and integration with VxWorks and QNX.

Hope this helps, and they are only suggestions.

Cheers,
Hugo Vincent
Albatross UAV Project

[FirmamentFX]

Hi guys,

Thanks for the replies.

I feel at this point I should clarify a couple of things:

The XP/VISTA/Windoze in general argument

(Despite appearances I am NOT a MS advocate...). I should have stated I am using XP/Vista embedded and not in GUI mode. The embedded system is on a single-board processor, and the app will be W32 console (no direct user interface).

To expand - I am aware there are alternative OS's (not least linux/unix), but I am C++ through and through. On top of everything else, I simply don't have time to learn another prog language (much as I would love to).

Also, my networking knowledge is all windows-based (although have done my own research, I agree Hugo that UDP is superior to TCP/IP for this particular system, for the very same reasons you mention on your site).

Add to that I am also a .NET person, and all my openGL coding has been in C++, and I would ideally like to develop the ground station and aircraft system on the same platform - simplicity.

FINALLY - I already have an XP embedded license :rolleyes:

HOWEVER - I will look at VxWorks and QNX. I hear the concerns and to an extent share them, but as long as I can code in C++ and have an SQL server running I will be a happy bunny... :D The ground station will always be Windoze.

Data Buses

FCDB and SDB are simply working names for the project. We haven't decided on the standard yet (and we're not developing protocols from scratch!!). However, I came across http://www.northhills-sp.com/products-databus.html - check out the micro and mini couplers (1 - 5 stub).

Complex / Simple

I hear you Hugo! However, we are testing and simulating EVERY software and hardware system to death on the computer before the components are even put together. Using MatLab, Electronics Workbench, and a couple of other bits of software we are virtually "building" everything before actually doing it. It's a good exercise in project management in any case!!

Scripting Language

Again, COPILOT is a working title for the system, not the language. We are looking seriously at NASAL. XML is far too verbose for our needs, and if we compacted it, it would lose half the point of it being XML - human readablity!

We haven't decided whether to actually do a low-level script system or just a "point and click" GUI of buttons that are used to construct arguements and perform functions.

Ground Software

Something else we are looking at it is a 3D "view" of the flight plan, updated live. Showing waypoints, vertical and lateral flight plans, altitude and speed constraints. Basically a 3D verson of the moving map display (but without the terrain).

Executables

Hugo - In the same way as you are doing on V2 of Albatross, we are making the aircraft software a single binary file (apart from the runtimes and .NET classes). The only other thing running will be the MySQL 5 server (to the systems on the network, the server will appear as separate to the aircraft control computer)

My Career :D :D

Unterhausen - believe me, compared to being a professional musician, engineering is a bedrock of stability and security :D The money also pans out better over the year as well. Even as a West End and National No. 1 tour musical director (which I am), the job security is horrendous, and frankly the job satisfaction has gone out of the window the past 6 months (don't EVER talk to me about the musician's union :rolleyes: ).

I am fortunate that I also run a music tech and CG/animation studio, which can finance this project and also uni. I am looking at a direct 2nd/3rd year entry as I already have 18 months of Electronic Engineering behind me.

M

[FirmamentFX]

Hugo - just looked at QNX. Looks good.

I know they provide their own IDE (Momentics PE), but do you know if it is possible to code in Borland C++ Builder and then port to Momentics?

M

[FirmamentFX]

RTOS solutions for windows (allows development in Visual C++ and is integrated with .NET too):

http://www.tenasys.com/products/intime.php

Alternatively Windows CE?

[FirmamentFX]

This thread is turning into my own stream of conciousness!! :D

Ok - I've been looking on the MSDN site, and having gone through their questionairre about embedded systems, they reccomend either Windows CE or Windows XP embedded with RT extensions.

The extensions are from Tenasys (see above) or http://www.ardence.com/ .

I am tempted to go with XP embedded because it is based on the same binaries as XP SP2. It is also more compatible with my knowledge of programming.

M

[FirmamentFX]

Regarding the Data Bus systems - of course another way to do this (thinking about the complex/simple issue) would be simply to design 2 hardware units - one for the FCDC and another for the SDAC with multiple inputs and outputs. The only caveat would be that for expandibility you make sure that there are enough ip/op connectors for upgradability...

Doing that, it would also be possible to power items like the servos directly (from the connector on the module) rather than have a separate power input on the microprocessor that controls the servos/actuators.

This would also cut down on the number of modules that are needed (using the data bus system, you would need a coupler, a CAN transceiver, and a microprocessor for each servo/actuator or set of servo/actuators or sensors.

To ensure that cable runs are not too long (and also for redundancy), it would probably be best to have a "left" and "right" module for each system (or "fore" and "aft") - the left hand control servos/actuators would be on the left module, and the right on the other. That way, if one module goes down, at least half the control surfaces would be working (and you could stagger home).


Food for thought...

[JettPilot]

You need to think long and hard about the type of airframe you want to use. Double slotted flaps, APU. etc. etc. You are going to make this UAV so complicated you are DOOMED TO FAILURE.

Even the military UAV's dont have that level of complication. For a small aircraft, you dont need it. Flaps, APU's, etc. will mean that you project will never get off the ground.

What do you gain with all of this airliner type equipment on a UAV ? NOTHING... You are not trying to fly 150 passengers, you just need an airframe of a small size, and smaller airframes do not need half the stuff you are talking about. Even if you could put all this complicated stuff on , its just more weight, more to go wrong, and would hinder the performance of your UAV.

Just from what you have said, I can tell that your thinking is and approach is so seriously flawed and unrealistic, that you will never have a flying vehicle.

What I say here may sound harsh, but someone needs to tell you. Encouraging you to attempt an unrealistic task is not doing you any favors. Maybe Boeing could pull this off, but one person or even a small group, NO WAY.

JettPilot

[hugo_vincent]

Hi Martin,

I am kind of inclined to agree with JettPilot, but it doesn't mean your project needs to fail, just that some very good engineering and management needs to be applied, and by that I mean SIMPLIFY YOUR PROJECT!! You can always add stuff later, but by designing everything in now, you greatly increase the chances that the project will fail. Work out what the minimal subset is, and build that first. When you've done that, design the second version, building off what you learned. And so on. Finally, many of the complex features you describe may end up being in the system, but they will be in their BY NECESSITY, not just because you want to build a cool, complex system.

More suggestions and notes:
* drop the NAVAIDS node - you don't need any of this, because you have GPS. The obvious arguement is that "I don't want to have to rely on GPS", but unless you can afford (both price and weight) a tactical-grade inertial navigation system, you are going to be relying on GPS anyway, for basic navigation, control and stability. Cheap inertial sensors just aren't good enough for sustained navigation without GPS corrections.

* ditch the onboard LAN idea. Use a lighter-weight network/bus like CAN, and only have one network bus. By the looks, all of the hardware that talks to the oLAN (except the main computer) will be custom anyway. 10/100 LAN is a pain in the arse to build into custom hardware, and also means you need somewhat powerful microprocessors in even the simpler nodes like the radio modem or the flight data recorder. CAN is fast enought too - 1Mbit/s should be no problem. And CAN can talk to the main computer via a off the shelf USB-CAN adapter. CAN busses are a single balanced pair for the physical layer (one twisted pair vs. the two to four pairs for ethernet), with a multi-drop bus (rather than star) topology, so it will save on cabling weight too. You shouldn't need any couplers or transformers, just hook everything straight onto the bus.

* C++ is fine on pretty much any OS, and certainly on QNX. I don't know if it's possibly to use Borland C++ builder or Visual Studio to build for QNX, because I've never used either. Of course, if you know C++ well, and can write good C++ code, the code will be portable across many compilers and operating systems without too much effort.

* MySQL will run fine on QNX. Download it from the official MySQL site. Why do you need an SQL server anyway? Wouldn't something like sqlite be more appropriate?

* note that the InTime windows real-time extensions is really another operating system and kernel running along side Windows, and the real-time stuff will actually be in InTime RTOS executables, not in Windows executables. To add to the complexity, your windows executables will need to communicate with the RTOS running along side, and this communication would need to be asynchronous at least on the RTOS side. And finally..... of course MSDN is going to suggest Windows XP embedded or WinCE..... !

* read about Reynolds number from aerodynamics. As wings and such get small, the viscous effects of air dominate, and things like flaps or even the shape of the airfoil don't matter. This can be evidenced by very small model aircraft that just have flat wings (no airfoil shape). I don't know how big you are planning to build your airframe, but I expect any wing complexity besides basic flaps (i.e. slats, leading edge stuff, slotted flaps) won't be necessary and will just make the thing harder, more expensive and more time consuming to build, and much more likely to fail.

* regarding scripting vs. GUI for route planning etc... your GUI can always output scripts. I think you should aim for a scripting engine approach, and when that works, think about making a GUI to simplify data entry. The script approach will always be more flexible than a GUI, especially if you build it on top of a general-purpose language like Lua or Nasal. Things like loops, conditionals, can become part of your flight plans; these things would be hard to input with a GUI flight planner.

* simulating is not a solution to complexity management. Simulating individual blocks then eventually the entire system will help you mkae sure you get things right when you first build and test them because you will already know how they are supposed to perform, but it will not simplify the design and implementation effort. (p.s. my Masters thesis I am writing at the moment is about simulation software so this is something I know well...)

Good luck!

Hugo

[FirmamentFX]

Hi guys,

Again thanks for the replies - constructive crits are always useful, and I admit I may have been getting ahead of myself.

However, at this point, I should say that we are not just throwing caution to the wind and building a large-scale airbus and that's it. We have a collection of small and large trainer RC aircraft (very stable, no surprise models) which EVERY SYSTEM (electrical, computer, video, radio, sensors, aerodynamics etc) is being tested on separately and with other systems. The airbus is the absolutely FINAL, finished model, that won't be seen for some time. However, we want to define all the systems in the finished model BEFORE we build and test them on the smaller aircraft, so that systems integration can be planned properly.

I have perhaps given the impression that we are just going ahead with the finished model, which is very much NOT THE CASE.

Jettpilot: Initial airfoil tests show that there is a strong possibility we will need flaps on the wing, given the speed (which we want to make as "scale" as possible - accepting that this will not be absolutely possible). The aircraft is 1:9 scale - which gives a length and wingspan of approx 4m (give or take).

I agree that double slotted flaps are more complex than single flaps, however we have already tested on a smaller aircraft a mechanism for implementing double slotted flaps quite simply, and it works a treat.

About the APU - frankly, we need a power generation source up in the air, and it is highly likely we will need an AC as well as a DC bus (we are trying to source systems and components solely running off DC power, but this may not be possible).

The APU will be a miniature turboshaft (with a continuous speed gearbox), connected to 2 or 3 generators. There will also be a backup battery on board, but this will provide electricity for approx 5 mins with basic, essential systems running, just to get the thing back down.

I would dearly love to find a way to avoid using another engine, by connecting the generators to the main propulsion turbines under the eings, but I don't think this will be possible.

Hugo: Regarding CAN. I can hardly find any info about it, aside from the protocol itself (which although very useful, doesn't give me basics such as connector type, methods of connecting into the bus etc).

Radio Modem and FDR - we have sourced these already and both have either RS232 or Ethernet connections and protocols built in.

SQL server - a lot of info (envelope protection limits, waypoint databases, certain logging functions) will be stored in the database. I haven't yet looked at SQL Lite, but chose MySQL because of its speed, my knowledge of it, and the fact that MSSQL can go to hell...!

NAVAIDS and ADIRS - our sources are:
Radio alts: http://www.roke.co.uk/
Attitude and heading: http://www.xsens.com/
GPS: there are so many out there we are still deciding.
Air Data - again there are a lot out there, but we are looking at either guidestar (http://www.athenati.com) which includes a lot of the above in 1 unit, or Microbotics (http://microboticsinc.com/index.php) which provides some integrated systems.

MSDN - yes I had assumed that MSDN would offer a microsoft product :D , I was just pointing out that it seems to be suitable for what I'm doing...

Having had chats with the tech people at both Tenasys (INtime) and direct insight (RTX), it would appear that even though their extensions run at the Hardware Abstraction Layer, they still rely on Windoze for things like disk reading/writing, some network functions (although RTX can talk TCP/IP directly with a network), and other bits and bobs.

GUI for Flight Plan Management - yes this is proposed for phase 2 of the development.

At the moment, I have restructured the systems slightly, still using 10/100 LAN (although this now could be changed at this point for another data transfer architecture quite easily). The NAVAIDS and ADIRS are not modules plugging into the LAN, but SPUs connected to the SDAC. The FCDC and SCDC units are the modules that connect directly to the servo/actuator and sensor SPUs, and the SDAC is a module that connects all the other sensors (that are not linked to the FCDC or SCDC) to the system.

Note that the latest diagram was done before I read the previous 2 posts and aomposed this reply, and the system is still a DRAFT.

Finally, Jettpilot, the point of this project is not to get any old aircraft up and running and get it to go from waypoint to waypoint. That has been/is being done by several people (not least Hugo - whose Albatross UAV project looks fantastic!!). The point of this is to simulate AS CLOSELY AS POSSIBLE systems that are found on commercial aircraft, just to see if it can be done on a smaller scale.

We're not implementing "pax-carrying" safety features (triple rendunancy, or even inflating escape chutes from the doors :p ), but as much as possible we are simulating the avionics and flight management systems.

You may well be right - it may be doomed to failure, we may (in fact, will!) come across unexpected complications, and the thing may never even taxi to a runway, but we're going to have great fun trying to get it in the air, whether it does or not. That's why it's a research project... :)

Cheers,

Martin

[Unterhausen]

all these naysayers on here :)

As far as the APU goes, my plan for avoiding that was to have a brushless motor mechanically driven by the engine. There are brushless motors that will go fast enough, and they make great generators as well as starters.

I don't know if you can afford bleed air driven generators at this scale, but it's another thing to consider.

[FirmamentFX]

all these naysayers on here :)

:D Sorry - didn't want to give the impression that I was having a moan! I do enjoy constructive crits and a good debate :p



As far as the APU goes, my plan for avoiding that was to have a brushless motor mechanically driven by the engine. There are brushless motors that will go fast enough, and they make great generators as well as starters.

I don't know if you can afford bleed air driven generators at this scale, but it's another thing to consider.

Directly connected to the shaft of the turbine??

Bleed air would involve some serious modification to the engines though wouldn't it?

M

[FirmamentFX]

Found a fantastic CAN tutorial - Hugo - the bus and stub wires literally connect directly together!! I see.....!

[chopsuey]

Did I miss the link to this fantastic CAN tutorial?

[Unterhausen]

I vote for a link to the tutorial. I've used CAN, but not designed with it. I believe that CAN on Windows is treated as a serial port, on linux they have special drivers.

Actually, I had to go do some machining before the machinist shut down for lunch, so I didn't finish my previous post. As you've stated, your APU is just a jet engine with a generator attached. Can you get such a thing in the size you want, or are you going to have to adapt a regular jet engine? I only have experience with full size airframes where the engines are big enough to have a tower shaft for power take off. I figured I could use belt drive, but belt drive might be impractical in this application.

[FirmamentFX]

Sorry guys! I was overexcited: http://microcontroller.com/learn-embedded/CAN1_sie/CAN1_files/frame.htm

[chopsuey]

Thanks!

[FirmamentFX]

Quote from the QNX 6.3 system architecture document:

In its simplest form, local area networking provides a mechanism for
sharing files and peripheral devices among several interconnected
computers. QNX Neutrino goes far beyond this simple concept and
integrates the entire network into a single, homogeneous set of
resources.

Any thread on any machine in the network can directly make use of
any resource on any other machine. From the application’s
perspective, there’s no difference between a local or remote resource
—no special facilities need to be built into applications to allow them
to make use of remote resources.

Users may access files anywhere on the network, take advantage of
any peripheral device, and run applications on any machine on the
network (provided they have the appropriate authority). Processes can
communicate in the same manner anywhere throughout the entire
network. Again, the OS’s all-pervasive message-passing IPC accounts
for such fluid, transparent networking.

Sounds interesting... Distributed computing at a much lower lifecycle cost than XPe.

M

[JettPilot]

Hi guys,

The airbus is the absolutely FINAL, finished model, that won't be seen for some time.

Jettpilot: Initial airfoil tests show that there is a strong possibility we will need flaps on the wing, given the speed (which we want to make as "scale" as possible - accepting that this will not be absolutely possible). The aircraft is 1:9 scale - which gives a length and wingspan of approx 4m (give or take).



It sounds like you are more interested in building a scale RC plane than anything else. If your design needs complicated flaps, then your design is flawed. People that build serious UAV's are not making them scale anything, they are designing them to fly well and efficiently, making them far different from "scale" models. You seem to be putting a huge amount of work into what will be a inferrior, poor performing, and failure prone UAV.

5 minutes of electrical power if the APU fials ? You will be lucky to get that thing on the ground when it does happen. If you are high, or far, 5 minutes will take you to the scene of the crash.

You must see why I am very skeptical about this project. Im really not trying to discourage you, but I am trying to give you good advice so that you can have a successful UAV you can be happy with :) If I crashed a UAV of the cost and time to build you are talking about, it would put me out of the UAV game for good. I dont want to see it happen to you. There is lots of experience good advice to be had in this forum, good luck !

JettPilot

[Bulma]

Looks like very interesting project. Here are some suggestions:
If you are looking for alternative to WinXPe, I recommend Windows CE. It is hard real time operating system, very reliable, and can run on standard x86 boards. Also, if you are familiar with windows XP programming, you are familiar with windows ce programming (you use same environment, VS2005, MFC, .NET, etc...). btw, i took last sentence from some MS presentation, but that statement really is true :)
I had some experiences with CAN, and it is excellent bus if you use it for what is designed for (connecting sensors and actuators). However, it is pain to use it for transfering large amount of data (CAN packet size is only 8 bytes long). So, you maybe better of with etherent, using UDP or some other real time protocol based on ethernet.

[FirmamentFX]

It sounds like you are more interested in building a scale RC plane than anything else.

I wouldn't go so far as to say that that is all I want to do, but yes that is part of the idea.

People that build serious UAV's are not making them scale anything, they are designing them to fly well and efficiently, making them far different from "scale" models. You seem to be putting a huge amount of work into what will be a inferrior, poor performing, and failure prone UAV.

The main reason I put this thread in the UAV forum instead of the Giant Scale Model forum is because of the complexity of the systems involved - it is in truth a hybrid of a model built for fun (therefore the choice of aircraft) and a model to test systems out on.

I do appreciate where you are coming from! :)

Bulma - that was my feeling on the CAN bus system. I am intending to use it to bring all the sensors and actuators into the main system, but for the high speed data links I think I still have to use something like 10/100 LAN.

The QNX OS has an ethernet protocol (it cutely calls QNet). I am trying to find out if I can mix QNX OS's and XPe (or XPCE) on the same network.

I'm still trying to figure out if it is better to go with a centralised (ie everything on 1 system) avionics system or keep things on different systems. I think in the end it will be a mix of the two...

M