Could orbiter be used to control real rcokets?

[jjake101]

It would probably be limited to earth orbit and the moon but would it be possible?

 

[RisingFury]

No, nor would you want it to control real world rockets. Orbiter has exact data about stuff like position, velocity,... and does a bunch of stuff it doesn't need to do for control of rockets.

 

[Face]

It would probably be limited to earth orbit and the moon but would it be possible?

What do you mean with "control"? Putting Orbiter on a µC and let the program control the actuators?

Keep in mind that Orbiter is a closed simulation in such a way that the complete environment is simulated instead of measured. In real life, Orbiter would already have problems determining the accurate position in 3D space and time. And besides that, I guess a CTD would be more than annoying for a multi-million Euro investment.

regards,
Face

 

[BruceJohnJennerLawso]

No, nor would you want it to control real world rockets. Orbiter has exact data about stuff like position, velocity,... and does a bunch of stuff it doesn't need to do for control of rockets.

Well, Orbiter definitely would be off in certain areas, but how far is Orbiter_ng from being an accurate launch sim?

 

[Face]

Well, Orbiter definitely would be off in certain areas, but how far is Orbiter_ng from being an accurate launch sim?

I think the lack of proper structural simulation makes it more of a launch visualization than an accurate simulation.

 

[Spacethingy]

Not Orbiter alone - Orbiter is a simulator, i.e. it acts as the laws of physics on the virtual rocket, not its flight guidance system. However, a converted Orbiter MFD... :shifty: interesting....

Aaargh, :ninja: terribly...

 

[Izack]

Do you mean controlling a rocket based on input from an Orbiter simulation, instead of input from real sensors and tracking data? I'd say that's unlikely to meet with success - Orbiter simulates real conditions in the atmosphere and outer space, and so by definition is simplified, ergo inaccurate. The real rocket would diverge from the path Orbiter predicts for it at a significant rate, and the vehicle would quickly fail because of nonsense commands from Orbiter.

If you mean using Orbiter as an on-board control software on a rocket, well...Orbiter isn't a guidance software. :shrug:

Edit:

Not Orbiter alone - Orbiter is a simulator, i.e. it acts as the laws of physics on the virtual rocket, not its flight guidance system. However, a converted Orbiter MFD... :shifty: interesting....

Interesting indeed, but likely to happen the other way around - a guidance software would be converted into an MFD.

 

[Urwumpe]

It would probably be limited to earth orbit and the moon but would it be possible?

No, it would not. Orbiter does do (almost) NOTHING that the computers for real rockets do. First of all, Orbiter is a spaceflight simulation, not a spacecraft simulation and not a spacecraft guidance system.

Orbiter does not do navigation. It always knows perfectly where its spacecraft are in its own universe. It doesn't care about the real world and does not look for sensors.

Orbiter does not do guidance. Aside of the things it knows easily (prograde, retrograde, normal), it does not do anything guidance-like. you need to teach Orbiter to do this, if you need it in your add-on.

Orbiter does also not do control. It doesn't handle actuators, it directly handles the resulting forces. Orbiter does not know why a surface of your wing moves, it only knows that it moves.

Practically, you can launch a rocket into orbit with a 20 Euro Arduino board. Rockets need no pretty 3D rendering, do not need to calculate planetary gravity with high accuracy. Only navigation data in and control data out.

Everything that makes real rocket computers expensive, is safety. They need to be radiation hardened, so the computer does not fail after 5 minutes in flight. They need redundancy and error correction. They need to operate with higher tolerances to thermal environment, vibrations and electricity than what your computer at home does. Rockets need powerful communication gear, self-destruct systems, drivers for pyrotechnics, etc. And of course, they are expensive for being not build more often than 1000 times.

 

[BruceJohnJennerLawso]

No, it would not. Orbiter does do (almost) NOTHING that the computers for real rockets do. First of all, Orbiter is a spaceflight simulation, not a spacecraft simulation and not a spacecraft guidance system.

Orbiter does not do navigation. It always knows perfectly where its spacecraft are in its own universe. It doesn't care about the real world and does not look for sensors.

Orbiter does not do guidance. Aside of the things it knows easily (prograde, retrograde, normal), it does not do anything guidance-like. you need to teach Orbiter to do this, if you need it in your add-on.

Orbiter does also not do control. It doesn't handle actuators, it directly handles the resulting forces. Orbiter does not know why a surface of your wing moves, it only knows that it moves.

Practically, you can launch a rocket into orbit with a 20 Euro Arduino board. Rockets need no pretty 3D rendering, do not need to calculate planetary gravity with high accuracy. Only navigation data in and control data out.

Everything that makes real rocket computers expensive, is safety. They need to be radiation hardened, so the computer does not fail after 5 minutes in flight. They need redundancy and error correction. They need to operate with higher tolerances to thermal environment, vibrations and electricity than what your computer at home does. Rockets need powerful communication gear, self-destruct systems, drivers for pyrotechnics, etc. And of course, they are expensive for being not build more often than 1000 times.

I think I see now. It might not be literally impossible, just not a good way to do things. If you want to build guidance software, youre better off creating the software for that task, than adapting a simulation designed for something completely different.

That being said, Orbiter would be a decent tool to plan the mission ahead of time, particularily as a shiny visualization for media & the like.

 

[jedidia]

That being said, Orbiter would be a decent tool to plan the mission ahead of time, particularily as a shiny visualization for media & the like.

I wouldn't want to use it for planning anything happen inside an atmosphere...

Sure, I think it should be precise enough to plan an interplanetary projectory, but you don't want to punch time accel up. So to do this practically, you don't want a real time sim.

 

[statickid]

maybe pre-planning or brainstorming

 

[Izack]

Orbiter is much more useful bringing spaceflight into people's computers so they can get interested in it than it is for actually assisting spaceflight.

I think I see now. It might not be literally impossible, just not a good way to do things. If you want to build guidance software, youre better off creating the software for that task, than adapting a simulation designed for something completely different.

By this logic I suppose you could use Minecraft as guidance software (all hail Java's multi-platform support.)

 

[hedzup456]

Orbiter is much more useful bringing spaceflight into people's computers so they can get interested in it than it is for actually assisting spaceflight.



By this logic I suppose you could use Minecraft as guidance software (all hail Java's multi-platform support.)

The Blockrocket!
~Hedz

 

[TMac3000]

I wouldn't want anyone using Orbiter to control a rocket, anymore than I would want anyone using Pole Position on an Atari 2600 to control Dale Earnheart's car.

One could, however, use Orbiter to plan/brainstorm interplanetary missions, although I suspect NASA/JHUAPL already have far more accurate planning software.

 

[ADSWNJ]

The exact equivalent of this thread on the pilot forums is "could a private pilot land a jumbo without the autopilot in an emergency". The little Orbiter that could, with it's digital inputs all a-twitching, fearlessly jumps in to stabilize the out of control rocket in the nick of time.

Makes for a nice story anyway...

 

[Pipcard]

The exact equivalent of this thread on the pilot forums is "could a private pilot land a jumbo without the autopilot in an emergency". The little Orbiter that could, with it's digital inputs all a-twitching, fearlessly jumps in to stabilize the out of control rocket in the nick of time.

Makes for a nice story anyway...

This analogy doesn't work, because as people have said before, Orbiter doesn't have "digital inputs" that let it know where and how the rocket is.

 

[Izack]

I wonder how the programming of, in lieu of the Orbiter core itself, some addon rockets would fare in a real-world scenario, using data obtained from sensors instead of the Probe-given near-perfect data they get in Orbiter? :hmm:

 

[Urwumpe]

I wonder how the programming of, in lieu of the Orbiter core itself, some addon rockets would fare in a real-world scenario, using data obtained from sensors instead of the Probe-given near-perfect data they get in Orbiter? :hmm:

Even for NASSP or SSU I wouldn't bet too much money on it. NASSP might run better there than SSU, since it runs the real software for the AGC, but uses a reimplementation of the LVDC.

No add-on really needs to care about redundancy management or electrical transients.

 

[RGClark]

Not Orbiter alone - Orbiter is a simulator, i.e. it acts as the laws of physics on the virtual rocket, not its flight guidance system. However, a converted Orbiter MFD... :shifty: interesting....

Aaargh, :ninja: terribly...

An intriguing possibility. How much does Orbiter have the ability to react to changing inputs in real time?
BTW, I like your avatar. :thumbup:

Bob Clark

 

[RisingFury]

An intriguing possibility. How much does Orbiter have the ability to react to changing inputs in real time?
BTW, I like your avatar. :thumbup:

Bob Clark

What? You mean like pressing keys ore moving the joystick? Orbiter runs at about 100 frames per second on a typical machine under easy load. That means it can handle whatever input it gets from the user or autopilots 100 times per second.