Project Universal Fly By Wire - Progress Report in first post

[lassombra]

I've proposed this before, but I feel it's time to propose it again. I'm willing (even eager) to do the work on this, but I have only one opinion (mine) on what the design should be like. This will not be begun until after the Intermodular Ship project reaches a release since I'm helping out with that one. That gives everyone here some time to weigh in with their opinions of how this should be done. Now to the proposal:

Space flight has had fly by wire for a long time. The Apollo missions had basic fly by wire, all stick controls going through the AGC and being interpreted based on mass and cg. The STS program had full electronic fly by wire, complete with autopilot functions. The fly by wire on the STS program was capable of completely reorienting the reference axis for use with the docking ring along the Y axis.

Orbiter does not have fly by wire. All inputs made go directly to the controls. We have rudimentary autopilot commands. We have a third party navigation system which depends on the RCS being well aligned around the CG. Atmospheric flight surfaces are direct control, though sometimes simple additive or subtractive routines are incorporated. There is no system to accommodate for shifting cg (docked vessels have a lot of issues here).

I feel it's time that Orbiter got a fly by wire. I can and will build it, but I'd like to give everyone an opportunity to weigh in with their design ideas. I have a concept, but I'm gonna wait to reveal mine until other people have commented.

EDIT: This project is being developed with an aim to be useful with 99.9% of orbiter vessels. Those few vessels which use their own cg code or actively avoid cg issues are the first exception, and those few vessels which override orbiter's control systems and write in their own code would be the second. Keep that in mind when making your suggestions. If your suggestion is aimed at a specific craft, consider if that suggestion might also apply to other craft or if it's an edge case. If it's an edge case, then perhaps mention that it's something you like but don't expect since I simply cannot handle *all* edge cases, though I'd like to try. That said, please do mention edge cases, I'm sure as this progresses, I'll find more about how different vessels have solved some of these problems.

Things that have already been eliminated:

• Controlling engines other than Main and RCS. These engines don't usually expose any kind of standard control, so this project wouldn't even have access to them except on a specific case by case basis, and only if the project exposes an API that allows that. Not reasonable expectation, unlikely to be provided. Vessel authors will be welcome to contact me to work out a way to get their vessel incorporated, and I'll provide a set of API call backs to vessel authors who design vessels after this project is made and want to use this with special engines.
• Multiple / non-standard / remapped inputs. This is simply outside the scope of this project and there is another project that I know of in progress that does just that. I'll be in touch with that project developer to maintain consistent compatibility, and feature requests along those lines should be aimed at that project. I don't compete with other people's projects.

Ideas which have already been presented and strongly considered:

• MFD interface
• Ability to interface with Space Craft 3 vessels (confirmed possible)
• Shuttle DAP style interface (seriously being considered)
• Multiple modes (Pulse, Rate, Free) (already was planned to be honest)
• Multiple "power modes" (read vernier and normal from shuttle parlance)
• Independent Axis Control
• Setting HUD to DOCK mode auto-configures thrusters to vernier settings (possibly going to be overriden by a related idea I already had)
• Gimbal thrust vectoring (already planned, glad to see I'm not the only one who wants it)

I did write up a logic document describing the operation of the FBW long before I posted this. So far what is really interesting is together you guys have thought up about 80% of what's on that document. Another suggestion in another thread entirely brought up another 2-3% and my own desires brought up the last 17%. What's interesting though is I wrote this whole thing before coming on here with it. So far noone has suggested anything not covered by it with the exceptions of the things I've already shut down as not being viable.

I've set up a Trac/svn repository for this project. It can be reached at http://ufbw.dyndns.biz. I expect it to continue to be developed rapidly, but I'll need continuous input. Soon I'll be looking for testers and other input.

----------------------------------------------------------------------

PROGRESS REPORT

Note, these percentages are estimates only based on tasks that have already been thought of.

Primary Documentation and concept research: 100%
Support Work (doesn't produce end user material): 60%
Create thruster interpretation code: 47% previously: 25%
Atmospheric aerodynamic controls: 0%
Center of Gravity compensation: 0%
Create API: 0%
Create control loop: 0%
Create user interface: 0%
Reference Frame math: 0%
Target vessel calculation: 0%
Polish and bug fix: 0%

Work done so far on documentation: 6:15 hours
Work done so far on core: 7:54 hours
Work done so far on development utilities (such as debug screen): 4:54 hours
Work done so far on User Interface: 0:00 hours
Total time invested productively so far: 19:04 hours

 

[Cras]

Well I would have to think on this for a bit, as a Universal Fly By Wire is such an appealing idea.

The first thing I would love to have, but am not sure if it is at all possible, would be for ships that use gimballed engines, such as Shuttle, that MFDs that use RCS (like Launch MFD) will be able to have its commands interpretted and passed on to the vessels gimballed engines. Even the XR-2 has gimbals for its engines, I am not sure if its are easy to use, as they seem to have a different mechanism for moving them about, but if somehow they could be linked to a joystick, I can see the potential use for that as well.

That is my initial thought, since you seem to have the basic pro's more than well covered in your original post.

 

[Donamy]

It would be nice if it included SC3 vehicles, for us non-coders.

 

[Moach]

you might wanna start by looking at my flight controls module.... now momentarily called "Project ORCADE" (ORbiter Control Assigned Device Enabler)

it does all the directinput stuff and wires it up to orbiter, so you can use any number of joysticks for doing a bunch of stuff

the thing is not really polished, or finished to any extent - but it does work, and if you want, i can put up the latest sources so you can have a way of tapping directly into joystick input data, which the orbiter SDK unfortunately doesn't expose


does that sound like it could be of any use?

 

[lassombra]

To answer the three so far:

The first thing I would love to have, but am not sure if it is at all possible, would be for ships that use gimballed engines, such as Shuttle, that MFDs that use RCS (like Launch MFD) will be able to have its commands interpretted and passed on to the vessels gimballed engines. Even the XR-2 has gimbals for its engines, I am not sure if its are easy to use, as they seem to have a different mechanism for moving them about, but if somehow they could be linked to a joystick, I can see the potential use for that as well.

I also had thought about that, and have ideas. Glad to see I'm not the only one with that particular idea though.

It would be nice if it included SC3 vehicles, for us non-coders.

I was planning on making it a plugin module that would be available for the pilot to enable or disable. This would have the flaw of making it available to pre-fbw craft, but that is a small price to pay in my opinion.

you might wanna start by looking at my flight controls module.... now momentarily called "Project ORCADE" (ORbiter Control Assigned Device Enabler)

it does all the directinput stuff and wires it up to orbiter, so you can use any number of joysticks for doing a bunch of stuff

the thing is not really polished, or finished to any extent - but it does work, and if you want, i can put up the latest sources so you can have a way of tapping directly into joystick input data, which the orbiter SDK unfortunately doesn't expose

The way I'm thinking of implementing it would eliminate the need for that, however it would be able to read inputs from a project like that, so if someone wanted to, they could use our two addons together to get a very competent and realistic operation. My intent was to do this using a proof of concept model I designed a long time ago for what was going to be a new set of star trek ships that had full on impulse and maneuvering engines that piped straight off the core. That design actually used dummy thrusters with less than .1N of force to read the inputs and then converted them into forces applied in specific areas. That way it stays within Orbiter and would be compatible with any input method people choose, whether using Orbiter's internal input system, or an external one.

 

[Moach]

roger that!


just a side note, i think you can get those inputs from zero-power thrusters just as well (i did on the G42) - just make sure you have a dummy fuel source, lest they keep reporting all zeroes :thumbup:

 

[Cras]

ANother idea crossed my mind, is to combine Rotational and Translational controls. I dont know how many of you are familiar with Space Shuttle Mission Sim, but it uses the numpad for both, without the need to toggle between the two. Throw in the ability to customize which buttons do what (for example if you want 3 to translate up and down sort of thing), I know I would find that to be extremly useful.

 

[N_Molson]

ANother idea crossed my mind, is to combine Rotational and Translational controls.

In real life, there is 1 controller for rotation and another for translation. They don't have to constantly switch "translation-rotation-translation-rotation" as we do

I'm quite enthusiast about the idea. The Lunar Lander project I'm working on would benefit a lot from this (as it involves CG shifts, and manoeuvering docked vessels stacks).

 

[lassombra]

ANother idea crossed my mind, is to combine Rotational and Translational controls. I dont know how many of you are familiar with Space Shuttle Mission Sim, but it uses the numpad for both, without the need to toggle between the two. Throw in the ability to customize which buttons do what (for example if you want 3 to translate up and down sort of thing), I know I would find that to be extremly useful.

As nice as that would be, and perhaps I can included it as an OPTION in a later release (read 2.0 or some such) it would necessarily require me to write joystick code as well since it would then separate itself from Orbiter's input system.

I also am familiar with Space Shuttle Mission, it's a lot of fun, and I'm really impressed with the way they incorporated more than just the flight physics, but at the same time a little disappointed by how much they abstract away the physics. Martin adopted a keyboard control style, and they adopted their own. Martin's has served us well for some time, but I do agree that it could use an update. Perhaps in the next version they will remap the keyboard navigation controls. However, for now, we must work with them as they are.

Perhaps Moach could incorporate some form of key remapping in their project? It would be a nice addition for sure, but is really outside the scope of this project which is aiming at the actual behavior of the craft and interpreting the inputs. Moach's project is aimed at redesigning the input we have to work with.

[/Rambling]

I'm cheered to see that people are interested in this project. I fully intend to make this project simply on the philosopy:

If you want to read a book that hasn't been written yet, then you must write it.

In other words, I want to use this add on, so I'm going to make it. If someone else finds a use for it, that's great. If a lot of people use it, even better. I want to make this an addon that will be useful to people, so I do still want input here, any encouraging words would also be nice. Depending on how my time commitment with the IMS project goes, I may start this early, I'm getting eager to play with it now.

 

[Cras]

I also am familiar with Space Shuttle Mission, it's a lot of fun, and I'm really impressed with the way they incorporated more than just the flight physics, but at the same time a little disappointed by how much they abstract away the physics. Martin adopted a keyboard control style, and they adopted their own. Martin's has served us well for some time, but I do agree that it could use an update. Perhaps in the next version they will remap the keyboard navigation controls. However, for now, we must work with them as they are.

That sums it up nicely.

But I understand if it is too far out to try and get the RCS and TCS active at the same time. I wil post it in the Orbiter Project Sub-Forum and see how it goes there.

With that being said, I am very interested in seeing what direction you want to take this project. I have ideas, but they are more like simulating the DAP on the Shuttle, and that may not be appropriate for what you want to do here, and is probably more in line for an MFD. I dont know enough yet about the Orbiter SDK to being to know the best course of action for something like that.

 

[lassombra]

That sums it up nicely.

But I understand if it is too far out to try and get the RCS and TCS active at the same time. I wil post it in the Orbiter Project Sub-Forum and see how it goes there.

It's a nice thought, but one thing at a time

With that being said, I am very interested in seeing what direction you want to take this project. I have ideas, but they are more like simulating the DAP on the Shuttle, and that may not be appropriate for what you want to do here, and is probably more in line for an MFD. I dont know enough yet about the Orbiter SDK to being to know the best course of action for something like that.

This will definitely include an MFD mode, which will serve as an interface to the system. The system itself however will continue to run outside of the MFD interface (much like LOLA or Redshift does). Ideas are good. You never know who will implement them even if I don't. That said, I'm looking for as much input as possible to make this as high quality an add-on as I can, so I'm really curious about your ideas.

 

[Donamy]

It would be nice if the MFD, could call up things that are attached to a vessel and operate them remotely, so things could be added modulely, not just engines and thrusters.

 

[Cras]

It's a nice thought, but one thing at a time



This will definitely include an MFD mode, which will serve as an interface to the system. The system itself however will continue to run outside of the MFD interface (much like LOLA or Redshift does). Ideas are good. You never know who will implement them even if I don't. That said, I'm looking for as much input as possible to make this as high quality an add-on as I can, so I'm really curious about your ideas.

Well the idea being that in the MFD you can set rate of change maximums, then say, I set it for a maximum rate of change for the pitch channel to be 0.2 degrees a second, when I pull back, it will command the RCS to rotate up to that rate and no more. Then when I release that, it will then null out that rate of change. Of course mixing that with attitude hold would be golden, but that might be beyond the basis of fly by wire.

 

[lassombra]

Well the idea being that in the MFD you can set rate of change maximums, then say, I set it for a maximum rate of change for the pitch channel to be 0.2 degrees a second, when I pull back, it will command the RCS to rotate up to that rate and no more. Then when I release that, it will then null out that rate of change. Of course mixing that with attitude hold would be golden, but that might be beyond the basis of fly by wire.

Interesting. Mostly interesting in the fact that I had the exact same idea, with one tweak. The normal modes would not be based on a specific rate of rotation, but how quickly it'd be able to null that rate of rotation. "Hi" or something like that would be whatever rotation could be nulled within one second. A little more abstract than specifically 0.2 degrees per second. Though, perhaps the interface could be provided to set the modes more precisely as you suggest.

---------- Post added at 04:18 AM ---------- Previous post was at 03:38 AM ----------

It would be nice if the MFD, could call up things that are attached to a vessel and operate them remotely, so things could be added modulely, not just engines and thrusters.

Perhaps you are looking for this: http://orbiter-forum.com/showthread.php?t=26003

 

[n122vu]

In other words, I want to use this add on, so I'm going to make it. If someone else finds a use for it, that's great. If a lot of people use it, even better. I want to make this an addon that will be useful to people, so I do still want input here, any encouraging words would also be nice. Depending on how my time commitment with the IMS project goes, I may start this early, I'm getting eager to play with it now.

Thank you. This is the attitude that keeps this community, and the development of great addons, going. I see so many addons released just so people can say they made an addon. If you don't have inspiration, and a vested interest in what you're making, you won't give it the attention to detail it deserves.

I'm looking forward to seeing the end result of this project!

 

[yagni01]

I, too, am excited about this project and look forward to trying it out ( a similar project is quite a way down on my TODO list). I've been living with Redburne's FBW until a new one comes along. Given I'm mounting this in a physical flight deck I have quite a few needs (to eliminate the keyboard).

RCS (ideas based on shuttle DAP)
- Multiple joystick support
- Independent channels for translation and rotation (high)
- Vernier modes for translation and rotation burns/rates are 10% (or other programmed value) of full thrust
- Normal mode - RCS fires as long as joystick is pushed
- Pulse mode - RCS fires a fixed pulse for each activation of joystick (must be re-centered to initiate another pulse
- Rate mode - RCS fires until a specified translation/rotation rate is achieved.
- Pulse and rate mode setpoints can be preprogrammed
- Independent axis mode configuration (LOW PRIORITY)
- Setting HUD to DOCK mode auto-configures thrusters to vernier settings (LOW PRIORITY)

ENGINES
- The ability to control XR-series vessels SCRAM engines via joystick
- The ability to control Shuttle-A pod (or any other provided auxilliary) engines via joystick
- The ability to control Shuttle-A pod position via joystick (or multi-position switch)
- Gimbal thrust vectoring
- Minimum (non-zero) thrust level (rocket engines are not infinitely throttleable). Should make landings much more interesting
- The ability to assign throttle authority to different engine groups.
- The ability to shutdown engine groups with a button press.

Hope this helps.

 

[lassombra]

I, too, am excited about this project and look forward to trying it out ( a similar project is quite a way down on my TODO list). I've been living with Redburne's FBW until a new one comes along. Given I'm mounting this in a physical flight deck I have quite a few needs (to eliminate the keyboard).

RCS (ideas based on shuttle DAP)
- Multiple joystick support
- Independent channels for translation and rotation (high)
- Vernier modes for translation and rotation burns/rates are 10% (or other programmed value) of full thrust
- Normal mode - RCS fires as long as joystick is pushed
- Pulse mode - RCS fires a fixed pulse for each activation of joystick (must be re-centered to initiate another pulse
- Rate mode - RCS fires until a specified translation/rotation rate is achieved.
- Pulse and rate mode setpoints can be preprogrammed
- Independent axis mode configuration (LOW PRIORITY)
- Setting HUD to DOCK mode auto-configures thrusters to vernier settings (LOW PRIORITY)

ENGINES
- The ability to control XR-series vessels SCRAM engines via joystick
- The ability to control Shuttle-A pod (or any other provided auxilliary) engines via joystick
- The ability to control Shuttle-A pod position via joystick (or multi-position switch)
- Gimbal thrust vectoring
- Minimum (non-zero) thrust level (rocket engines are not infinitely throttleable). Should make landings much more interesting
- The ability to assign throttle authority to different engine groups.
- The ability to shutdown engine groups with a button press.

Hope this helps.

It occurs to me my original reply was kinda harsh and not helpful. The suggestions about multiple inputs or any other kind of input mapping is outside the scope of this project. I plan on working closely with another author who is working on a project that'll do that stuff, the rest I'm looking into. I've updated the first post to show what my decision making process so far has been based on people's comments.

 

[lassombra]

I've set up a project management page at http://ufbw.dyndns.biz. This page will evolve more frequently than the forum here. I'm working on setting it up so people will be able to get email updates from it as well.

 

[darrenc]

Hi, lassombra.

I just noticed your thread while posting one of my own on a similar subject. You may want to check the thread out [here]. Basically, it is a thruster control system which can work with arbitrary (ie: non-balanced) thruster configurations, and has been designed to be easily extensible to handle such things as controlling thrusters across docked vessels.

I have also, some time ago, written some engine gimballing code. It works in a similar manner - you provide a torque vector and it works out the gimbal angles for you. It is highly coupled to the launch vehicle I wrote it for, but with a bit of work I'm sure I could extract the relevant portions and develop it into a reusable component. Would this be useful to you, or do you already have it covered?

Like you say, if people will use it, I am happy to work on it.

 

[lassombra]

I just noticed your thread while posting one of my own on a similar subject. You may want to check the thread out [here]. Basically, it is a thruster control system which can work with arbitrary (ie: non-balanced) thruster configurations, and has been designed to be easily extensible to handle such things as controlling thrusters across docked vessels.

I have also, some time ago, written some engine gimballing code. It works in a similar manner - you provide a torque vector and it works out the gimbal angles for you. It is highly coupled to the launch vehicle I wrote it for, but with a bit of work I'm sure I could extract the relevant portions and develop it into a reusable component. Would this be useful to you, or do you already have it covered?

Like you say, if people will use it, I am happy to work on it.

I don't know if you visited the trac yet? The first phase of the project was documentation and concept research. I finished that one last night when I managed to gimbal the engines of the xr2 and dgIV without issue. I've also demonstrated use of control surfaces, despite what the documentation says I've found that if the user doesn't turn on control surface manipulation, then the add-ons can play with them all they want.

I'd be happy to incorporate your code (would actually complete an entire milestone. More specifically though, I'd like to invite you to participate in this project. Your experience would be invaluable, and if we pool our resources, we could make an add-on that will be truly magnificent. (plus, you seem to have a handle on the math which I'm only just learning).