Yet another new simpit

[Robb Bates]

Well, after tossing the idea around for the longest time, it took all the news about the 40th Anniversary of the Apollo landing to light a fire under my butt.

I've finally decided to build my simpit. Lots of ideas, lots of questions. Here's what I have so far.

I found a Thrustmaster F-16 FLCS and F-16 TQS at a thrift store for $9 total! What a steal! They are the old game port versions. I've already hacked the joystick onto a Playstation controller with a PS2 to USB adapter. I had planned on doing the same for the throttle. But it seems the PS2 joystick likes to auto adjust the deadzone in the center of whatever pot you're using which wouldn't be good for a throttle. I have a "Eliminator" USB joystick, which I'll probably use to replace the PS2 guts in the F-16 joystick and throttle. I have plenty of other uses for the PS2 joystick/adapter. Namely the rudder pedals, the "Range" and "Elevation" dials on the thottle. I also plan on building a translation controller and a pilot viewing angle joystick.

I went down to a junk yard and bought a car seat from a 1990 Nissan something. Very space-ish looking. I'm quite pleased with it. But getting all the ergonomic measurements right is going to be a trick. How high do I put the joystick and throttle? How far away do I put the panels, etc., etc.

I also have an 8" touch panel LCD screen to use as an MFD.

I'm basing this mainly on the Delta Glider IV, but I want to still be generic enough for MS Flight Sim/Flight Gear, and whatever else. I'm really good with the electronics hardware side of it and I have a small CNC machine, but inexperienced with the interfacing with Orbiter. I could also dive into the SDK a bit.

Here's a few questions I have.

What would be the minimum set of controls for a good generic (but DG4 oriented) sim pit? Or another way to put it: What controls are used ALL the time that should be implemented in hardware so you don't have to grab the mouse to operate them on the virtual cockpit?

Should I include NAV/COM radio controls for MSFS (and Orbiter).

Is there an easy way to interface the MFD buttons to hardware buttons? The key mapping seems to change all the time based on what's displayed. Is there a fixed mapping for these buttons? Like Alt_Shift_1 for the first button, or something like that?

I plan on putting a bank of toggles for all the doors/lights, etc. But I'd like to come up with an easy way to change the switch labels depending on what software/ship I'm using. Like for the DG4, the switches could be Outer Airlock, Inner Airlock, Nose cone, Retro doors, etc. But for the Atlantis they could be, Cargo Door, Radiator, KU band antenna. I could do something like slide a piece of paper with different labels into a plastic holder, or something much more elaborate like an LCD display with software "hotkey" labels. Any other ideas?

Other than using a TripleHead2Go, is there any other way to display the outside view on more than one monitor? I've read that the latest beta separates the graphics engine from the simulation engine. Does that lend itself somehow to help with this?

Lots more questions, but not enough time right now.

Robb Bates

 

[MeDiCS]

This should help, a lot: [ame="http://www.orbithangar.com/searchid.php?ID=3223"]Fly-By-Wire 0.9 beta[/ame]

 

[Robb Bates]

Definitely! That's one of the first Add-ons I'll use.

Robb

 

[bpops]

As far as I know, there is no 'permanent' key assignment to the different MFD buttons -- instead, as you said, they change depending on the MFD mode. Because of this, I created different controls for every MFD on my sim pit.

But that's not to say it can't be done. Lockingtoggle's DGIV sim pit ( http://www.orbiter-forum.com/showthread.php?t=4816 ) seems to have implemented what you're looking for. But I'm not sure how he does it (or intends to do it).


Can you tell me what kind of CNC machine you have? I'd love to get one, but all the ones I've seen are too expensive.

 

[yagni01]

Check out the cockpit pages on the orbiter wiki. . . http://www.orbiterwiki.org/wiki/Orbiter_cockpits

I suggest the cardboard mockup approach to discovering the best placement of controls. Since you're doing generic, its all a matter of whats comfortable for you.

You can find out what controls are most important by making a note every time you reach for the mouse while flying.

Labels - you could use magnetic material (ala refrigerator magnets). I think that would look better than paper.

You can use multiple head graphics cards or multiple cards to use multiple monitors.

HTH

 

[Robb Bates]

Magnets... I like that. But my panels, or at least the label part, would have to be a ferro-magnetic metal. Or perhaps just another fridge magnet. I do happen to have a bunch of blank business card sized magnets with peel and stick adhesive. I think I'll try that idea. Thanks!

I bought a few dirt cheap as-is dual monitor cards from GoodWill. Hopefully at least one of them will work. But I was hoping to use three viewport monitors and one instrument (touch screen) monitor. I'm pretty sure Orbiter can't span multiple monitors. Isn't that why everyone uses a TripleHead2Go?

Robb

 

[yagni01]

I bought a few dirt cheap as-is dual monitor cards from GoodWill. Hopefully at least one of them will work. But I was hoping to use three viewport monitors and one instrument (touch screen) monitor. I'm pretty sure Orbiter can't span multiple monitors. Isn't that why everyone uses a TripleHead2Go?

Robb

Nope, its because thats another approach for Windows to span multiple monitors. Many people consider it simpler than configuring multiple video cards. Orbiter doesn't care as long as the resolution stays below something like 2048 x 800 (don't recall the max, but its in a thread here somewhere). The next version will allow higher res, but it won't care how you get there.

 

[Robb Bates]

I played with it a bit during lunch and found there's a lot of variables involved. But yes, 2048 is the horizontal limit. Bummer. That's only a little better than 640x480 on three monitors. I might go with the beta which I think can exceed that limit. I also played with ZoneScreen which may help with some networked monitors for MFDs and maps, etc. There's also TouchBuddy which I may use with my touchscreen LCD.

Robb

---------- Post added at 03:51 PM ---------- Previous post was at 03:50 PM ----------

I'm also VERY interested in your Orb:Connect. Expect me to pick your brain when I start interfacing my panels.

Robb

 

[Hielor]

I played with it a bit during lunch and found there's a lot of variables involved. But yes, 2048 is the horizontal limit. Bummer. That's only a little better than 640x480 on three monitors. I might go with the beta which I think can exceed that limit. I also played with ZoneScreen which may help with some networked monitors for MFDs and maps, etc. There's also TouchBuddy which I may use with my touchscreen LCD.

Robb

---------- Post added at 03:51 PM ---------- Previous post was at 03:50 PM ----------

I'm also VERY interested in your Orb:Connect. Expect me to pick your brain when I start interfacing my panels.

Robb

RemoteMFD may save you some work:
http://sourceforge.net/projects/remotemfd/

 

[Robb Bates]

Can't see any files. Is it still in development?

But yes, I can definitely see this coming in handy.

Robb

 

[Hielor]

Can't see any files. Is it still in development?

But yes, I can definitely see this coming in handy.

Robb

We haven't made any releases yet, it's still very much in a development phase.

Currently the Surface and Orbit MFDs are working to at least the equivalent of the Orbiter built-in ones (in some cases more), and there are others in various stages of completion.

You can get the source (builds natively in VS2008 on Windows, or g++ on Linux):
http://sourceforge.net/projects/remotemfd/develop

Requires Allegro in order to build: http://alleg.sourceforge.net/

 

[Robb Bates]

Will it work in VS2005? I'm not an expert programming by any means, but I know enough to get myself into trouble.

Seriously though, I know C++ well enough to probably help out and beta test and debug. So if you'd like any assistance, I'm here.

Robb

---------- Post added at 09:27 AM ---------- Previous post was at 09:19 AM ----------

And just for a little background on myself, I work at Southwest Research Institute in San Antonio, TX. I'm in the Space Sciences Division. I do Printed Circuit Board Layout for a living. I've been directly involved in the development of several space probes and satellites. You may have heard of some. Deep Impact, LRO, Swift, New Horizons, Orbital Express, Kepler, IBEX, WorldView, and several you haven't and probably won't hear of. I'm pretty good with designing and building the hardware, moderately decent at programming. I have a CNC machine I converted from a Harbor Freight desktop milling machine. I'm also into robotics. I regularly manufacture circuit boards from conception to design to etching and drilling and populating.

Robb

 

[bpops]

I played with it a bit during lunch and found there's a lot of variables involved. But yes, 2048 is the horizontal limit. Bummer. That's only a little better than 640x480 on three monitors. I might go with the beta which I think can exceed that limit.

The new version still uses DirectX 7, which is the culprit for the 2048px limit. So, don't anticipate that working on its own. Artlav's OGLA does work, however it does not support full screen (and does have some other issues at that high of a resolution). But of course that's a work in progress and he is constantly improving that module -- it's the one I expect I'll use once the new Orbiter is released.

For now, I'm using TH2G at the largest full-screen resolution Orbiter 2006 will go (and not crash) -- I forget the number, but it's somewhere around 1600. I know, not near the 3840 desired, but it does the job adequately. The only real issue I have is that the stars smear out because of the stretching.

 

[Robb Bates]

I'm hoping we can eventually get better than 2048, because across three monitors, that's pretty lousy resolution.

Do you know if there are any plans to have the ability to have additional view windows? Like Left-Front, Right Front? That should prevent the stretching.

BTW bpops, my CNC was home built. That is a fun project in itself. I took a Harbor Freight desktop milling machine, replaced the handwheels with stepper motors, added some motor drivers, and some software. It's quite functional, but small. My work volume is only 6"W x 4"L x ~6"H. Good enough to drill PCBs and cut some small aluminum parts, but not much more. And the top spindle speed is a real limiting factor. Every CNC builder eventually gets upgrade envy. You always want a bigger CNC machine. I was able to do the whole thing for right around $500. There are plenty of plans and websites to build your own. It's not really too difficult. If you have the know-how to build a simpit, then you have what it takes to build a CNC machine. Just do your research first.

Robb

 

[Hielor]

Will it work in VS2005? I'm not an expert programming by any means, but I know enough to get myself into trouble.

I don't think you'll be able to load the project file directly, but we're not using anything 2008 specific so it should be possible to convert it.

It should also work in the VC++ Express Edition 2008, if you want to pick that up for free.

Seriously though, I know C++ well enough to probably help out and beta test and debug. So if you'd like any assistance, I'm here.

Robb

Assistance is always welcomed, and it would be nice to have someone new take a look at things to make sure that Yagni and I aren't totally crazy. It should be relatively easy to configure new MFDs, and the wiki has a lot of information which should be (mostly) up to date.

My tentative goal for a first release would be to have all of the built-in MFDs (or versions thereof) running in RemoteMFD, so a cockpit based on RemoteMFD would be at least as functional as the on-screen cockpit. We haven't even started on the map, align planes, or transfer MFDs, so if you're good at math and really bored some time feel free to take a crack at one of those! :lol: For the TransferMFD I was planning on just porting TransX: http://www.orbiter-forum.com/showthread.php?p=51763#post51763

Porting an MFD from the Orbiter version to work with RemoteMFD is non-trivial, but definitely doable and easier than writing it from scratch. I did it with cjp's excellent FreeOrbitMFD.

Really though, if you want to help out, take a look at what we have, and see what else you would like to have in a cockpit, and then add it...

Do you know if there are any plans to have the ability to have additional view windows? Like Left-Front, Right Front? That should prevent the stretching.

Artlav has a prototype version of a program that allows you to remotely render things, so that might be able to be used at some point to have multiple views from the same Orbiter instance...

 

[bpops]

Do you know if there are any plans to have the ability to have additional view windows? Like Left-Front, Right Front? That should prevent the stretching.

That's an interesting though -- is it possible that DirectX7 could output more than 2048 so long as it was divide up in multiple screens? (Unlike, for example what the TH2G does)

 

[Robb Bates]

Apparently not. I tried that and it bombs.

Robb

 

[bpops]

Apparently not. I tried that and it bombs.

Robb

Ah, oh well

 

[Robb Bates]

Well, bought some plywood this weekend and cut it into the structural panels. Assembling it tonight. I'm trying to keep it compact so it can stay in the house and keep the wife happy. 48"x38" footprint. Smallish, but that's all I'll need.

Robb

 

[bpops]

Post some pictures when you have something completed!

As for keeping the wife happy, I made mine so it can be 'quickly' disassembled and moved if needed. My sim is in the guest bedroom, and my wife already told me I have to move it into the garage when we have guests.