Use of FSUIPC for computer science real time systems researh

[cfeld]

Hi Everyone,

I wanted to ask this question to all you experienced FSUIPC developers before I get too far into my project to get your opinions and thoughts. I've been a huge flight simulator user for years but I've never developed anything for it. Now it seems like I may be able to combine my hobby with some of my research.

I am a graduate student in computer science and the university of victoria. I am currently studying real time systems and for my final project I would like to do something pretty cool using Flight Simulator and FSUIPC.

What I need to do is to take the RTOS (real time operating system) I've created for my course and put it into an applicaiton.

I'd like to get my RTOS to be a flight controller for a simulated plane in flight simulator. What I'm wanting to do is to run an older version of flight sim (98 or 2000, could use 2002 or 04 if anyone thinks its easier to develop for) and using FSUIPC to take some data from flight sim (such as aircraft orientation, airspeed, altitude etc), transmit it over TCP/IP to another computer (the one containing my RTOS) The different values read from flight sim would be like data from real sensors on a real aircraft. My RTOS will then act like a flight controller and decide which flight surfaces need movement (ie to keep level flight or do a turn etc.) and my RTOS will send those commands back to the FS computer via TCP/IP and FSUIPC will send those commends into flight sim to controll the aircraft.

So my big question is..... does this sound do-able? I'll take care of the RTOS computer side of things... but is it reasonably easy to get the data i'm looking for out of flight sim and then send it off to another networked computer, then get control movements back and send them to flight sim?

Also if any of you know of utilities/sample code etc that may help me with this task, i'd appreciate your suggestions (as I'd prefer not to write a program to collect and send off the data to other network computers)

Thanks a lot for your time and I look forward to your replies. I can be emailed at cfeld@uvic.ca

Cary

[Pete Dowson]

... using FSUIPC to take some data from flight sim (such as aircraft orientation, airspeed, altitude etc), transmit it over TCP/IP to another computer (the one containing my RTOS) The different values read from flight sim would be like data from real sensors on a real aircraft. My RTOS will then act like a flight controller and decide which flight surfaces need movement (ie to keep level flight or do a turn etc.) and my RTOS will send those commands back to the FS computer via TCP/IP and FSUIPC will send those commends into flight sim to controll the aircraft.

The nearest thing to this already implemented would probably be Project Magenta's advanced Autopilot, built into it's MCP. It has two modes, one using the FS autopilot for some things, and another where it tries to do the whole thing itself. Of course the inter-machine transmissions are performed by WideFS in this case -- the MCP can be run on the same PC as FS, or on another. WideFS provides the remote interface to FSUIPC.

I think all this is perfectly feasible for control of aircraft where a small time lag (latency) is not detrimental to the flight. You would find this probably a bit too slow for jet fighter operations, or even probably Extra aerobatics. But for airliners and some GA aircraft you can do it. If you are not operating as an Autopilot, but more "fly-by-wire" there are even facilities in FSUIPC for disconnecting the user's flight controls, reading his values and acting upon those.

Regards,

Pete

[cfeld]

Hi Pete,

I'm going to send this same message to your email address as well. My appologies for the duplication but I want to be sure that you get this.

Thank you for your reply to my forum message regarding the real time system's research I plan on doing.

I can see from all the posts and the fact that you have personally created FSUIPC and WIDEFS that you definetly know what you are talking about.

I have created a RTOS which currently runs on its own (not on windows or linux... but it is an OS by itself.) It would be must easier for me to make my RTOS work on linux than on windows because I can edit the kernel etc.

If I use FSUIPC and WIDEFS on the PC side to extact data from my copy of FS and to send it out on the network I still have a problem with how to deal with this data on the other side. Do you know of a linux client version of your WIDEFS? I'd like to make my remote computer as simple as possible and I'd prefer to recieve the WIDEFS packets into my own app or through a linux WIDEFS client (running WINE for example isn't an option for me) I'll then send other WIDEFS packets back to the FS computer with my flight controls etc.

Also would you know of other sample code, other addons, utilities etc that may help me do all this? I'm trying to minimize the development time for all the Flight Sim work I need to do because my research is with the RTOS.

I can not seem to find online older versions of FSUIPC etc. I am considering doing all this work using Flight sim 98 on a computer running win 98 because I don't have the budget to buy a fast computer to run fs2002 or fs2004. I understand that you have now made FSUIPC and WIDEFS payware and if I commit to doing this project I will pay for them but if I use FS98 on an older computer to save money, would you be willing to send me one of your older versions of FSUIPC and WIDEFS and the SDK's that is not payware?

Finally, I've noticed that MS is offering something called netpipes on the FS2002 SDK. Although it is questionable to me if it offers the same features as FSUIPC. Do you know if I may find it easier to use netpipes over your FSUIPC? Do netpipes allow me to send data and receive data at the same time into on copy of FS?

To sum up my questions:

1) is there a WIDEFS linux client? or an SDK that would make it easy to send and recieve WIDEFS packets on a linux system?

2) do you have or know of any sample code, addons, further documentation or utilities that I can use to further save me time on developing things to work with FS?

3) is it possible to get an older version of your FSUIPC and WIDEFS (before it became payware) since I will be developing all this on a FS98 and win98 computer?

4) What do you know about MS's netpipes SDK for FS 2002.

Thanks for all your help!

Cary Feldstein

Graduate Student

Univeristy of Victoria

cfeld@uvic.ca

[Pete Dowson]

I'm going to send this same message to your email address as well.

It never arrived! One copy came to the "private" part of this Forum, but as I said there, I don't like using that at all.

If I use FSUIPC and WIDEFS on the PC side to extact data from my copy of FS and to send it out on the network I still have a problem with how to deal with this data on the other side. Do you know of a linux client version of your WIDEFS?

No. I did hear of someone making a stab at a Linux version of WideClient (or it may have been an Apple O/S version -- it was a long time ago), but I never heard of it coming to anything. There are no specifications of documentation I'm afraid, you'd have to derive it all my monitoring the packets. Quite honestly you may be better devising your own methods.

Also would you know of other sample code, other addons, utilities etc that may help me do all this? I'm trying to minimize the development time for all the Flight Sim work I need to do because my research is with the RTOS.

Sorry, no.

I can not seem to find online older versions of FSUIPC etc. I am considering doing all this work using Flight sim 98 on a computer running win 98 because I don't have the budget to buy a fast computer to run fs2002 or fs2004. I understand that you have now made FSUIPC and WIDEFS payware and if I commit to doing this project I will pay for them but if I use FS98 on an older computer to save money, would you be willing to send me one of your older versions of FSUIPC and WIDEFS and the SDK's that is not payware?

There's only the current version. Use that with FS98 too if you like, though you won't get many facilities -- FSUIPC was designed originally for FS2000. It wll run on Win98 though (try to make sure it is Second Edition). Avoid Windows NT.

I don't really think your project is terribly viable in any case with FS98 unelss you do some deep digging into FS98's innards. Use Adam Szofran's FS6IPC.dll, not FSUIPC, that saves you paying and gives you almost as much -- for FS98 FSUIPC offers only a few extras like Logging.

Finally, I've noticed that MS is offering something called netpipes on the FS2002 SDK. Although it is questionable to me if it offers the same features as FSUIPC. Do you know if I may find it easier to use netpipes over your FSUIPC? Do netpipes allow me to send data and receive data at the same time into on copy of FS?

It certainly allows you to receive data from FS. I don't know if you get any control the other way. I only had a brief look at it a year or two ago and didn't really think it was a lot of use. But don't take my word for it, take a look yourself.

Regards,

Pete

[SeanMcLeod]

I'm busy looking into something similar, basically implementing an auto-pilot, although in my case my auto-pilot code will run on the same machine as MSFS and not on an external RTOS machine.

I have some experience using FSUIPC on a previous university project that I helped out on for a motion platform driven from MSFS. In that one I basically wrote some code that used FSUIPC to extract some relevant data from MSFS (aircraft attitude, aircraft accelerations etc.) run that through some transformation filters to determine what position the motion platform should be put into and then communicated with a D/A board to send the final analog signals to the motion platform's motors to get it to drive the platform.

See the following link for a short 30 sec video of the motion platform that was built.

If you look at the FSUIPC SDK docs and let me know what subset of the variables you need as input, e.g. aircraft attitude (pitch, roll, yaw), aircraft accelerations etc. then I could write a small program that runs on the MSFS PC that used FSUIPC to read the variables and would send them to your RTOS platform as a custom tcp/udp packet.

Similarly the small interface program would listen for custom tcp/udp packets returned from your RTOS with position info for the flight surfaces and it would then again use FSUIPC to update the positions of the flight surfaces based on your calculations.

So if your RTOS includes tcp/udp support then all you'd need to concentrate on would be the actual algorithms for translating the aircraft input data into new flight surface positions.

On the flight surface positions I actually have a question for Pete. Your SDK docs list of number of variables for the flight surface position/deflection, e.g.:

2E98 - ELEVATOR_DEFLECTION (FLOAT64)

However there is no comment on the range or type of units. Is it the same range for all aircraft or does it vary from aircraft to aircfract?

Or am I looking at the wrong variables and should rather be modifying something like:

0BB4 - Elevator position indicator

Cheers

[Pete Dowson]

On the flight surface positions I actually have a question for Pete. Your SDK docs list of number of variables for the flight surface position/deflection, e.g.:

2E98 - ELEVATOR_DEFLECTION (FLOAT64)

However there is no comment on the range or type of units. Is it the same range for all aircraft or does it vary from aircraft to aircfract?

As I think it says somewhere, ALL the values in the second table in the document were found "by accident" in FS2000, some don't apply to FS2002 (or I've not found them), and probably many more in FS2004. I've not even got to them for checking yet for FS2004.

And the reason there's no comment, nothing against them, is that I mostly have no idea what they are nor what units they are, even if they do work. When folks use them and tell me about them, I see if I can reasonably "promote" them to the first table -- but this gives me more word each FS release to try to find the things again, so I'm reluctant if there's already something similar.

Or am I looking at the wrong variables and should rather be modifying something like:

0BB4 - Elevator position indicator

That's an INDICATOR, You can't move the elevators by modifying the indicator, nor for that matter changing the "elevator deflection" readout, which is probably the same thing in any case for all I know.

To move the control surfaces you use the controls. Surely this should come as no surprise? Indicators indicate.

Regards,

Pete

[SeanMcLeod]

That's an INDICATOR, You can't move the elevators by modifying the indicator, nor for that matter changing the "elevator deflection" readout. Surely this should come as no surprise? Indicators indicate.

Reason I thought it may be possible was because those appeared to be the only variables referencing flight control surface's positions, plus the docs said they were 'writeable'. I assumed if they were really just 'indicators' then they would've been read-only.

To move the control surfaces you use the controls.

Not real autopilots :D The controls stay fixed and the computer sends independent commands to the control surface's actuator.

Plus I don't want slight pilot 'bumps' of the controls to be intefere with the autopilot's inputs. Although I see on further reading of the SDK doc there is a special byte at 310A to allow for disconnecting the joystick.

Also what about the case of FBW planes like the B-777, A320 etc. where the pilot's control input is heavily filtered and possibly limited etc. before actually moving the control surfaces?

Even non-FBW aircraft like B-737s etc. have some filtering applied to the pilot's control input based on airspeed etc.

So to wrap up, if I want to control the elevator surface from my autopilot code I should: ?

1. Disconnect the joystick by using variable 310A

2. Write to 0BB2 - Elevator control input

Will this combination also allow my autopilot to move the control surface without being filtered by an aircraft's FBW system?

And if I wanted to implement my own FBW control laws:

1. Disconnect joystick by using variable 310A

2. Read pilot's control input from 3328 - Elevator axis input

3. Apply my FBW control filtering and write to 0BB2 - Elevator control input

I'm not sure that I fully understand the relationship between Elevator axis input (3328) and Elevator control input (0BB2) correctly and when how MSFS's FBW control logic would be in the chain.

Thanks

[Pete Dowson]

[quote name="SeanMcLeod

Reason I thought it may be possible was because those appeared to be the only variables referencing flight control surface's positions' date=' plus the docs said they were 'writeable'. I assumed if they were really just 'indicators' then they would've been read-only.[/quote]

Where does it say "writeable"? I don't normally say such things.

Most things are writable, but that doesn't mean writing to them has any effect. For most indications whatever you write will simply get overwritten on the next frame as the sim re-computes it.

Mind you, there have been surprises -- like writing to the accelerations can produce an acceleration. It is short lived, but it has been used to good effect for catapulting.

Not real autopilots :D The controls stay fixed and the computer sends independent commands to the control surface's actuator.

They are the controls. I'm not talking about moving the joysticks themselves, I'm talking about the controls that the joysticks "actuate"!

Plus I don't want slight pilot 'bumps' of the controls to be intefere with the autopilot's inputs. Although I see on further reading of the SDK doc there is a special byte at 310A to allow for disconnecting the joystick.

Exactly. You can also use those for "fly-by-wire" as I provide the inputs in another location.

Also what about the case of FBW planes like the B-777, A320 etc. where the pilot's control input is heavily filtered and possibly limited etc. before actually moving the control surfaces?

Like fly-by-wire. Disconnect the control inputs from the "actuators" and put your own algorithms in between. That's what those facilities are for. That's the way folks have used them.

1. Disconnect the joystick by using variable 310A

2. Write to 0BB2 - Elevator control input

Yes, though I think most folks use the elevator trim instead, like the FS autopilot. If you want the plane to be ready trimmed when your A/P is disconnected I suppse you'd need to work out proper use of both.

Will this combination also allow my autopilot to move the control surface without being filtered by an aircraft's FBW system?

Who's FBW? Obviously if something else is doing the same as you there will be conflicts.

And if I wanted to implement my own FBW control laws:

1. Disconnect joystick by using variable 310A

2. Read pilot's control input from 3328 - Elevator axis input

3. Apply my FBW control filtering and write to 0BB2 - Elevator control input

Yes, that's what it says, more of less, isn't it? That's why the facilities are there. And not just elevator of course.

I'm not sure that I fully understand the relationship between Elevator axis input (3328) and Elevator control input (0BB2) correctly and when how MSFS's FBW control logic would be in the chain.

If the input is connected, the input goes to the control. If you disconnect it, it doesn't. It is that simple.

And I have never heard of any FBW in any MS aircraft.

Regards,

Pete

[cfeld]

If you look at the FSUIPC SDK docs and let me know what subset of the variables you need as input, e.g. aircraft attitude (pitch, roll, yaw), aircraft accelerations etc. then I could write a small program that runs on the MSFS PC that used FSUIPC to read the variables and would send them to your RTOS platform as a custom tcp/udp packet.

Similarly the small interface program would listen for custom tcp/udp packets returned from your RTOS with position info for the flight surfaces and it would then again use FSUIPC to update the positions of the flight surfaces based on your calculations.

So if your RTOS includes tcp/udp support then all you'd need to concentrate on would be the actual algorithms for translating the aircraft input data into new flight surface positions.

Hi Sean,

Sorry its taken me so long to reply. I would very much like to take you up on your offer. My RTOS computer(s) will most likely be running a type of linux so there will definetly be TCP/UDP support on them.

My situation has changed slightly and I'm probably not going to be able to get to defining the requirements for at least one month. If your offer to help is still on the table then please let me know and I'll be in touch when I'm able to work on this project again.

Thanks!

Cary

[DavidSolinger]

1. Disconnect the joystick by using variable 310A

2. Write to 0BB2 - Elevator control input

Did somebody succeed in writing data to the elevator control input this way?

I have been able to read from 0BB2 and also to write to certain other variables, but a write to 0BB2 does not seem to affect something.

Greetings, David

[Pete Dowson]

[quote name="DavidSolinger

I have been able to read from 0BB2 and also to write to certain other variables' date=' but a write to 0BB2 does not seem to affect something.

[/quote]

It and the other control surfaces are certainly working okay for writes. Possibly you had the FS autopilot engaged, or did not diconnect the joystick input as mentioned, so it was overridden?

In FS2000 and before these locations actually affected FS directly. Since FS2002 it is FSUIPC which sees the writes and converts them to control inputs using standard FS controls.

Regards,

Pete