Vessel Transorbital tug / Hauler

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
We have quite a few really cool spaceplanes with decent simulations. The XR-series most of all, but also the DG IV, the starliner, and there might be some I've missed.
We have nothing comparable for purely orbital operations like transfers. There's the dragonfly, which has electric and lifesupport systems, but it can't do orbital transfers (much less with some load), and also it doesn't quite work anymore in orbiter 2016 (everything seems nice enough until you turn the power on, then things start to not work quite as they should). There's the shuttle-A, which is a pretty big-ass hauler with a nominal payload of 120 tons, but doesn't have much simulation. A couple of neat controls for the pods and docking port, for sure, but nothing deeper, nothing that requires any checklists aso.

The thing I found myself really wishing for lately was a kind of realistic, near-future "orbital truck" if you will, capable of transferring modest to moderate payloads between orbits, but that makes you work a bit to operate it, so there's more to flying it than just orbital transfers.
The easiest way to achieve something like this would probably be to give the shuttle-A the "XR-1 treatment" so to speak, at least in that case there would already be a mesh to start with, or to beef p the dragonfly, though its whole panel structure would need to be rewritten for orbiter 2016, which is a lot of work in and of itself.

In any case, here's some of the features I'd like to see:

  • Reasonably realistic (shuttle-A is stretching it a bit to be honest, though it could be nerved somewhat with more realistic specs).
  • Capable of reaching the moon from LEO, though not with much payload (maybe up to some 10 tons or so...)
  • Doesn't need to be capable of landing on the moon, though that may be a cool thing for a second iteration.
  • Some electrical system that needs a startup procedure before you can get going, similar to the dragonfly (though not necessarily that indept. I'm don't think we need fuel cell tank pressures and stuff, just a logical distribution system that needs to be powered up a certain way and blows some fuses if it isn't).
  • Some life support simulation, like o2 and Co2 levels and thermal control (big one, that, I know). The whole thing might have an endurance of maybe a week before it needs to resupply.
  • UMMU/OMMU support is quite optional, I barely use these features, but there should be some failure state if you forget important things, even if it's just a "Congratulation, everybody's dead" message on the HUD or so.
  • VC would be awesome, but some nice panels would do just fine.
  • Potentially, some closer simulation of the main engine. Nothing too fancy, but having to go through some procedure to get the thing ready to ignite would be cool, if that's actually realistic.

The last point maybe highlights my problem... I have the coding skills to do something like this. In fact, I even have lots of code lying around from older projects, including nice things like an animation framework for orbiter, a framelocked event messaging system, a whole general constant voltage electric simulator that I kinda finished but never used, and a couple of other stuff.
I do face three major problems, though:

1. I don't know nothing about spacecraft systems. Not even airplane systems, when it comes to that. Actually designing how this thing should work and how the procedures should be would be a major learning endeavor. Usually I play simulations to learn about stuff like that, I don't typically write them, though it has happened a couple of times in the past.
2. I can do modelling, but it takes me unreasonable amounts of time, and I really don't enjoy it that much. It follows that most things coming out don't usually look that nice, and the thought of designing a virtual cockpit drives shivers down my spine...
3. The factor compounding the two above is a problem that most people will be familiar with... I don't have much time. I obviously have a job, but besides that I also have a private project that I intend to (attempt to) commercialize at some point when it's far enough, and then there's a family with a special needs child, and... well, there's not much of the day left over. If I try to do this alone, it'll never get finished.

I'm mentioning this so it's understood that I'm not just posting a feature list here and waiting for somebody else to do all the work. I'm totally willing to do my part. But my part isn't enough to get something like this over the finishing line, so let's start by discussing the basics:

a) Is anybody besides me actually interested in something like this? The goal would be to have a vessel that could be used as a solid basis of a kind of "eurotrucker in space" experience, which is something I'd like very much, but maybe I'm the only one.
b) Any suggestions for the design of the craft and its systems? Not implementation so much as specifications, sketches, equations, hell, just a sketch of what the cockpit of such a craft might look like in some detail would already be helpful...
c) Any suggestions on possible implementation patterns, libraries etc that could shave some work off of this?
d) Anybody interested to actively participate in development?
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Some clarification about the requirements: Do you mean with "reaching the moon" also returning to LEO from it with one load of propellant?

Any constraints on the crew size or should it just be kept minimal?

How should the payload be like? Pushed or pulled as docked vehicle? Multiple smaller containers (UCGO style)? Encapsulated payload in a payload bay? Liquids or bulk cargo?

On your questions:

a) I think we really could use something like a true small spacecraft, without any focus on landing somewhere. There is a gap in capability.
b) I could do a SysML model, if you want to, as coarse baseline architecture. I think cockpit should maybe be done agile with players in a playtest phase - in that case it might be smart to be able to change the cockpit layout easily.
c) Not that much, as little of the actual implementation is known yet. I work on a basic framework to handle all the boilerplate stuff of Orbiter (especially loading/saving) for Gemini-Titan, I could contribute this into the project as well. Maybe that is a good start.
d) Count me in, but I won't do really much in the next two weeks - I am on some sort of vacation.

On the other set of questions:

1. The most unsurprising solution is sticking to the basic set of abstract subsystems of any manned spacecraft: Structure (primary, secondary), ECLSS, TCS, EPS, GNC, Propulsion/AOCS, DPS, communications. Generally, you have a control loop setup: We measure something (sensors), display it to the player, who decides and use the input to apply effectors on the vehicle state... da capo.
2. Same here. But if nobody else wants to do it, I think the ugly horror that I can create is still better as nothing at all. And if it is just serving as bad example so that some modeller gets eye cancer and does an overhaul of the meshes to protect himself.
3. Same here. But then, any 1000 mile travel starts with the first step. I think the key is keeping everything as simple as possible initially. If you only can work 1 hour per week, then we can't do something that requires focus and full concentration (Like SSU requires). We have to reduce complexity, as absurd as it sounds, for producing a complex spacecraft. And leave the magic to somebody else.

I would suggest making the actual implementation open-source and free to be modified by anybody who wants to add something - as long as we can include it in return as well.

Also, I would prefer some kind of brainstorming about the various possible configurations for this spacecraft, with multiple users providing their, hopefully different solution for the various stages of the development. In systems engineering, there is a common zig-zag model of refining the requirements based on the selected solutions for the previous set of requirements. We could do it like that in this thread - from an initial set of requirements, we include could do single out certain pivot requirements and ask for a solution - which subsystem or subsystems could solve it? How could it be achieved and what is the price? Which new requirements would then be added, which requirements would need to be changed for it?

In the end, it would then need a decision which solution becomes the new baseline configuration for the next iteration (including going back to a much older iteration). Would you like to be primarily something like a product owner (in the Scrum sense) for this project?
 
Last edited:

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Do you mean with "reaching the moon" also returning to LEO from it with one load of propellant?
I was thinking one way trip and refueling, but then getting back from the moon without payload is pretty cheap, so could probably be done at further payload reduction. I definitely didn't think of getting something there and back again without refuelling.

Any constraints on the crew size or should it just be kept minimal?
I was thinking of two regular crew, can be handled by one if required, can accommodate 2 additional passengers/crew if required space-wise, though that would reduce the endurance (i.e. it might have the space, but life support isn't really engineered to accommodate four people for more than 2 days or so...).

How should the payload be like? Pushed or pulled as docked vehicle? Multiple smaller containers (UCGO style)? Encapsulated payload in a payload bay? Liquids or bulk cargo?
Integrated payload bay doesn't really make sense for such a craft, I think. Attachable containers ala shuttleA are probably best (whether one or multiple), offers most flexibility for most kinds of payloads. Implementation-wise I'm personally fond of cargo containers with a dummy propellant tank, that lets you easily adjust the payload mass for whatever scenario you want to simulate. And if somebody really wants UCGO, a UCGO capable attachable container can be made, keeping the closed source dependency out of the core.
For bonus points, the containers could have some interactivity with the craft, so you could make a cargo container with controlled environment that draws power from the hauler.

I work on a basic framework to handle all the boilerplate stuff of Orbiter (especially loading/saving) for Gemini-Titan, I could contribute this into the project as well. Maybe that is a good start.
Oh, That reminds of that model-binding library for config-files I did once...

The most unsurprising solution is sticking to the basic set of abstract subsystems of any manned spacecraft: Structure (primary, secondary), ECLSS, TCS, EPS, GNC, Propulsion/AOCS, DPS, communications. Generally, you have a control loop setup: We measure something (sensors), display it to the player, who decides and use the input to apply effectors on the vehicle state... da capo.
Yeah, see, that's the part I have no idea about. Not about how to implement it into orbiter, but about how such systems actually work and are controlled in real life. So before starting work on anything like that, I'd need some use-case diagrams, and potentially some technical ones...

I would suggest making the actual implementation open-source and free to be modified by anybody who wants to add something
Oh, absolutely open source. I'm getting really annoyed about all the closed-source dependencies in the orbiter ecosystem...

Also, I would prefer some kind of brainstorming about the various possible configurations for this spacecraft, with multiple users providing their, hopefully different solution for the various stages of the development.
Yeah, that would definitely be cool.
Would you like to be primarily something like a product owner (in the Scrum sense) for this project?
If we get active enough to need it, yeah, that might be fine. Definitely won't have much time for coordination, though, since that's basically the part of my work that stresses me out the most... :unsure:
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
Mmh... interesting... What about a big NTR spacetug you can refuel after each roundtrip ? Wouldn't even have to be crewed. That way you have a somewhat-decent ISP and stay in the "possible" realm. Also managing the reactor systems could be interesting, especially from a thermal standpoint. Not something you simply switch on/off.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Oh, That reminds of that model-binding library for config-files I did once...
Yeah, that might be interesting at a point. I currently didn't need much configuration, but here it could make sense.

Yeah, see, that's the part I have no idea about. Not about how to implement it into orbiter, but about how such systems actually work and are controlled in real life. So before starting work on anything like that, I'd need some use-case diagrams, and potentially some technical ones...

Well, remember, we don't need to cover all at once. Thats just the aspects to probe there.

Also, if you want to avoid too many checklists and things turning into a switch-flipping simulation, I would recommend to gamify things a bit.

For example - EPS (electric power subsystem) can be very complicated (batteries, generators) but if you want to keep things simple, you could just limit things to a few simple mechanisms: Electric energy and electric power. And say something like: Battery can sustain the life support system for at least 96 hours.

If we get active enough to need it, yeah, that might be fine. Definitely won't have much time for coordination, though, since that's basically the part of my work that stresses me out the most... :unsure:

No problem about initially doing the coordination and process/method part. But I would need to give those tasks away at a future point.
 

Arvil

Well-known member
Joined
Apr 20, 2008
Messages
400
Reaction score
315
Points
78
Location
Pennsylvania, USA
Preferred Pronouns
he/him
Perhaps it could have something like a Canadarm, and the cargo containers could have a grappler and standard docking port. The vessel could deliver a container to any ship or station.
 

Pioneer

Well-known member
Joined
Mar 2, 2012
Messages
506
Reaction score
272
Points
78
Location
Greater Detroit
I think we already have a spacecraft like this, but for interplanetary purposes. It's also one of my favorite spacecraft in the game:


The fuel tanks on her are big, so maybe for more close-range cislunar and orbital operations, you could take her and just cut her in half.
Here's another option, but I'm not sure how compatible with 2016 it is:

 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Perhaps it could have something like a Canadarm, and the cargo containers could have a grappler and standard docking port. The vessel could deliver a container to any ship or station.
Canadarms are pretty complex to code, though there might be some code lying about somewhere considering how often they've been done...
I did imagine this craft to be somewhat reliant on existing infrastructure, though. It's a "truck", not a pioneering vessel.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Canadarms are pretty complex to code, though there might be some code lying about somewhere considering how often they've been done...
I did imagine this craft to be somewhat reliant on existing infrastructure, though. It's a "truck", not a pioneering vessel.

Well, since you also plan to have cargo containers, I would say, a robot arm is not mandatory. At least not for the minimum viable product.

But its now in first place time to think about the minimum set of user stories, that the tug should include, not the solutions.

Basic architecture is also a topic now - which solutions and tools are mandatory from the start. Orbiter 2016, Visual Studio 2019 Community, git... what about sound, shall a specific sound add-on be needed?
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Basic architecture is also a topic now - which solutions and tools are mandatory from the start. Orbiter 2016, Visual Studio 2019 Community, git... what about sound, shall a specific sound add-on be needed?
Since both sound add-ons have default sound templates, I don't think we need to explicitly support it right out of the gate. If we're adding explicit support for sound, I'd go with XR-Sound, at this point in time it has more reliable support than OrbiterSound.

Architecture-wise, on the general level, from past lessons learned I would go for an event-driven architecture as much as possible. It just lets you encapsulate things within the add-on more nicely and requires less tracking when you need to do things asynchronously (asynchronously not in the sense of multiple threads, but operations that may have to let a frame pass between setting certain states, which is a frequent occurrence).

But its now in first place time to think about the minimum set of user stories, that the tug should include, not the solutions.
Yeah, I'll think about that for a bit.
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
Funny that you say this, pretty much all your criteria line up with a vessel I have been thinking about for the past few days.

The main premise is that the vessel has a singular large-ish engine, which uses a monoprop fuel heated to extremely high temperatures using one of the two onboard fission/fusion reactors, which also power the spacecraft systems. The engine does not produce ridiculous amounts of thrust or has a ridiculous ISP, but enough to make journeys to the moon from LEO.

This would require a decently in depth power up / down sequence. The reactors would power the two power buses, and would require active cooling.

The RCS and retro engines would use a simple hypergaulic fuel. When it comes to landing, the engine is reoriented so that it faces downwards, instead of forwards.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
I think similar, but about using a LANTR engine there as single main engine for the coarse work. Has the advantage, that I can recycle a lot of the numbers from NASA papers...
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
The main premise is that the vessel has a singular large-ish engine, which uses a monoprop fuel heated to extremely high temperatures using one of the two onboard fission/fusion reactors, which also power the spacecraft systems.
Fusion is a bit too speculative for my taste (for this project, anyways). If you take a fission reactor what you discribe is basically an NTR. Plausible, but probably overkill for a vessel of this size. If my intuition is not completely off the mark, the capabilities should be perfectly within the range of hydrolox, which would result in a better thrust/mass ratio, be a lot less maintenance intensive and the propellant would be manufacturable on orbit from asteroid mining or lunar ice. I can't really see anything being powered by a fission reactor that doesn't have a very good reason for it... Still, if it results in something that's cool to fly, I'm all for it.

But its now in first place time to think about the minimum set of user stories, that the tug should include, not the solutions.

Right, here's how I would envision building this thing (not necessarily in the listed order, though some of these things obviously have dependencies to one another. Not going into much detail, this isn't Jira, after all). Also, this is very broad right now, obviously there's going to be a lot of subdivision and iterations on the individual stories. I have taken the liberty to divide them into a couple of epics just for better overview. List is, quite obviously, open for discussion and sweeping changes.

Epic: Liftoff
  • Clean project setup: Builds and loads into orbiter with a dummy mesh from the orbiter distribution (one of the atlantis payloads or somethin').
  • Basic architecture setup: Vessel has an engine, rcs, a docking port and a stub for an electrical system that are all on-off switchable by keypresses, with everything switching off when the electrical system is switched off. This should mainly be seen as a PoC for encapsulation of the ships systems and event propagation in the code.
  • Stub panel: replaces the keyboard commands with clickable switches. Purely placeholder graphics to have something to go on. I have an entire UI-framework with toolkit lying around that I might be using for that step, I think it might take a lot of the boilerplate out of prototyping. We're going to need a real panel at some point, but that's going to take a while.

Epic: Design
  • Basic physical specifications for the vessel: Dry mass, prop mass, thrust, ISP. May still vary in the future, but some guideline values to base future development on.
  • Basic payload handling specification: Do we use dockports or attachment points, can the vessel still dock with attached payload or do we pull a dragonfly and use a second dockport of the payload for docking (which would be kind of a cool, simple cargo delivery mechanism, to be honest... dock with the payload, undock from the payload, dock to a different port of the station for refualing and resupply).
  • Specification for electrical system: How does the electrical system look and to what depth do we want to simulate it in a first iteration?
  • Specification for crew system: Do we have oMMU support, or do we just have virtual consumers in the vessel? If the later, what properties do they have?
  • Specification for air managment system: What does it look like and to what depth do we want to simulate it in a first iteration?
  • Specification for thermal control system: What does it look like and to what depth do we want to simulate it in a first iteration?
  • Specification for main engine simulation: What does it look like and to what depth do we want to simulate it in a first iteration?

Epic: Systems implementation (Will probably make sense to subdivide further, but we need to know what we want first):
  • Electrical system implementation
  • Payload handling implementation
  • crew system implementation
  • air management system implementation
  • thermal control system implementation
  • main engine simulation implementation

Epic: Graphics+Interface
  • first iteration of mesh
  • rough cockpit layout sketch
  • electrical system controls layout sketch
  • life support controls layout sketch
  • main engine controls layout sketch
  • flight controls layout sketch (MFDs, specific instruments we might need, etc)
  • electrical system controls implementation (placeholder graphics)
  • life support controls implementation (placeholder graphics)
  • main engine controls implementation
  • flight controls implementation

Epic: Optional (very rough)
  • VC mesh
  • VC implementation
  • Sound design
  • Material designs for D3D9 client
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Well, user stories should be written from the user/player perspective, for example in the way of "When I fly this vessel, I want to....".

You are too much focussing already on the technical details and its IMHO too early to decide anything there. With user centric user stories,its easier to find a slice of user stories that make up the MVP or the next iteration of development. With technical specifications, its much harder to grow from release to release.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
You are too much focussing already on the technical details and its IMHO too early to decide anything there.
Yeah, that's what happens when you somebody that mostly develops in-house software does project planning... ?
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Yeah, that's what happens when you somebody that mostly develops in-house software does project planning... ?

Yeah, I know the problem. Its the same with engineers, who can throw a formula at your head with the words "Implement this", without ever saying what they want to do with it.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
Some life support simulation, like o2 and Co2 levels and thermal control (big one, that, I know). The whole thing might have an endurance of maybe a week before it needs to resupply.

This doesn't feel quite right. Life support is really critical. If the thing is to be able to go to the moon one-way, for actual routine work, not just an Apollo-style "go a few times to say we did it and collect data", it feels like life support should be sufficient to cover contingencies like:

1) Your engine fails on the way to the moon. You do a free return, but because you aren't capable of aerobraking or landing, being engine-out means you can't stop at Earth. There's some snafu with the rescue plan, and the rescue ship doesn't rendezvous with you until you return to Earth on your second orbit.
2) You make an uneventful trip to the moon, but two hours before rendezvous, there's a catastrophic failure aboard the lunar station and an evacuation becomes necessary. You dock and take the station crew aboard, and the nature of the failure means that you're able to refuel for return to Earth, but are not able to top up on life support stores. You need to make the return trip with the stores remaining from your outbound trip and extra crew aboard.
3) Maybe there isn't a lunar station yet, and you get stranded in lunar orbit. You need to hold out until rescue arrives.

So my thinking is that the procedure for sizing your life support system is probably to take the one-way flight time for your maximum delta-V mission, make it a round trip, and then give yourself a 100% safety margin.

So if your expected maximum mission is the half-week-ish one-way flight to the moon, life support should probably be good for two weeks. Even then, I'm feeling a bit paranoid about potential accident scenarios.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
I would calculate the life-support rather on the demands of a "business" mission for the life-support: From servicing to servicing.

So, it could mean, that it has to store enough O2 and N2 for multiple trips in modules, while food and water is loaded as often as possible. A regenerative CO2 filter could require servicing once per flight year.

EDIT: Also I would assume that the servicing is provided by the ships manufacturer or service providers... maybe some possibility for extended story arcs.
 
Last edited:

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
IMHO a pure "hauler", especially in a futuristic background, doesn't have to be crewed at all... Seems like an unnecessary risk. If you have to carry people, you can always haul an habitat module, a modular and comfortable cabin with enough Dv to perform on-orbit docking manoeuvers, like 200-300 m/s.
 
Top