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:
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
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.
- 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'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
Last edited: