Project Light-Class General Purpose Tug (LCGPT)

[Depth08]

Light-Class General Purpose Tug

Introduction:
A light tug-type vessel able to carry out basic station building and module pushing operations. The idea behind the project is to be a modern successor of the older decommissioned DragonFly Class, which doesn't seem to work properly anymore. I have always been inspired by the DragonFly class space tug. Mainly because it was the only fictional, yet realistically modeled vessel available within the standard package. With a close eye on the systems, I'd like to take it to a new level with the LCGPT.

STATUS: EARLY DEVELOPMENT
- Basic custom DLL
- Mesh files

Some shots:

PLANNING:
- Realistic system logic: Many custom features making life easy, yet not too complex.
- An extended soundset to add some to the immersion.
- Some extra modules for station building to play with.

I'd like to achieve a great experience, with some things the dragonfly missed, yet just that little extra modern.

The LCGPT is smaller than the Standard DragonFly Class. It can maintain a crew of two with a life support system.

It's strengths will be:
- Versatile and lightweight
- Comfortable to use
- Budget solution which packs quite a punch in what it does
- Outperforms the DragonFly because it will have a better combustion in it's thrusters

It's weaknesses:
- Not that easy to start up (Nifty machine)
- Notorious for system failures (which is something I personally favour)
- Small fuel and reactants storage tanks

It's total operation time is limited to 55 minutes, by that time it must be returned to replenish its fuels.

So who likes the sound of this? I am a great designed but my C++ skills are sort of dusty. It'd be great if somebody pushed me into the right direction regarding the writing of special systems in my DLL. Also it'd be great if somebody actually told me what's going on with the original DragonFly, I sought everywhere but can't seem to find an answer as to why it's systems aren't working (CoG Compensation, RCS modes)

Any of your comments can potentially bring me forward, so please do help!

 

[Interceptor]

This looks really cool,if you could get the cog feature working like the Dragonfly in orbiter 2006 it would be a great asset for orbiter2010,I never use the Dragonfly anymore because of the broken cog system.

 

[C3PO]

Looking great! :thumbup:
The Dragonfly is showing it's age now. I haven't been able to get it working for years. :embarrassed:

I think 55 min is a very short time. I used to go very far to fetch the modules/cargo, and part of the fun was to fly efficient to 'stretch' the fuel. Not much worth as a Tug if you have less than one orbit worth of resources.
And that brings me to my other idea. If you put the thrusters on deployable arms you save fuel used for CoG compensation. It's probably a bit to late for that judging by those finished meshes. :lol:

The time limit could be set by resources like life support or electrical power. Even heat management could be used. Then you could turn off stuff to prolong your trip to avoid draining the batteries or run out of fuel cell resources.

The Dragonfly Radar always looked a bit obsolete to me. I'd imagine a craft like this to use Lidar cameras and/or D-GPS for rendezvous and docking.

Looking forward to the LCGPT Tuesday!

 

[sorindafabico]

Great! I like the concept of the Dragonfly and I thought of starting a project like this for months, but real-life commitments have prevented me from putting time into any addon idea.

Anyway, I'll keep watching your progress here.

---------- Post added at 05:32 AM ---------- Previous post was at 05:30 AM ----------

I think 55 min is a very short time. (...) The time limit could be set by resources like life support or electrical power. Even heat management could be used. Then you could turn off stuff to prolong your trip to avoid draining the batteries or run out of fuel cell resources.

I agree. EVA time limit is about 8 hours, and 55 minutes is less than one orbit.

 

[MaverickSawyer]

I concur with the previous posts: A beautiful and much-needed ship. However, I have a question the fellows above me seem to have missed asking: Is the 55 minute limit the power supply limit, the burn time limit, or the "typical" mission duration (based off of a certain number of manuevers)?

 

[Izack]

Perhaps a minor niggle, but those RCS nozzles have a bit of an extreme expansion ratio, eh?

 

[Depth08]

Thanks for all your replies! I'll try to answer you one by one.

if you could get the cog feature working like the Dragonfly in orbiter 2006 it would be a great asset for orbiter2010

That's what I had in mind. Without it, a space tug seems useless, and hard to operate. It'll have a manual and automatic CoG compensation. Only I need some hints in how to calculate it. Should I make real-time compensation, or pre-calculated depending on the length of modules you're hooked up with?

I think 55 min is a very short time.

The idea around the LCGPT is a light-weight local worker around a space station. Able to push around modules within proximity of the station. The MCGPT however, which is the project after this one, has about the same systems, but with a much further range.

If you put the thrusters on deployable arms you save fuel used for CoG compensation. It's probably a bit to late for that judging by those finished meshes.

Yeah it's kind of late for the LCGPT, I was thinking about this too. So it's actually possible to alter the thruster's position on the go?

The time limit could be set by resources like life support or electrical power.

That's the idea, some systems can be turned off, you could even turn off the oxygen, it's not like orbiter's going to prompt you that you died. If sound is included, you won't be hearing it anymore though.

Is the 55 minute limit the power supply limit, the burn time limit, or the "typical" mission duration (based off of a certain number of manuevers)?

The 55 minutes are all you need for the operations with this machine. Imagine a space station, and a module has to change position, or a new one has to installed. The LCGPT is exactly that perfect local worker. It's scope of application is limited however, it can't go on a long haul to pick up another module somewhere in a different orbit. That's a job for the MCGPT I had in mind.

Perhaps a minor niggle, but those RCS nozzles have a bit of an extreme expansion ratio, eh?

I'm not an expert, but your advice can help me make the LCGPT a better experience. I can still change them if you like.

 

[Urwumpe]

I'm not an expert, but your advice can help me make the LCGPT a better experience. I can still change them if you like.

Then change the bell-shape for something vacuum like. The Apollo RCS is a good hint there. Alternatively the Shuttle PRCS, but there you rarely see the full nozzles.

 

[Interceptor]

A new radar system would be great too.

 

[Linguofreak]

The 55 minutes are all you need for the operations with this machine. Imagine a space station, and a module has to change position, or a new one has to installed. The LCGPT is exactly that perfect local worker. It's scope of application is limited however, it can't go on a long haul to pick up another module somewhere in a different orbit. That's a job for the MCGPT I had in mind.

That's just the thing, in realistic orbital operations with a tug at the station, a new module would probably be delivered to a different orbit to minimize the risk of a high velocity collision or of the station being hit by the booster's engine plume. My understanding is that the Shuttle, at least, tended to cover the last few kilometers of a rendezvous over the course of several orbits, and that the last few hundred meters took half an orbit to a full orbit. So even assuming that modules were delivered to a point a few hundred meters from the station (which is as close as they could safely be delivered, the ISS is 100 meters in its largest dimension), you'd still be fairly likely to bust your 55 minute limit. A tug with the mission profile you describe for this one should have resources for several orbits, your medium tug should probably be able to operate independently for several days (and should be able to keep a crew alive for an other several days beyond that in case of a breakdown without any other spacecraft close by).

 

[Urwumpe]

55 Minutes are also so short, that a robot arm would have only a slightly shorter range - and such a short period of time forces you to use more inefficient maneuvers, instead of just moving around the station with small impulses.

3 hours (= about two orbits) would be a better value. Thats long enough to operate within about 20 km distance of the station, but too short for longer distance rendezvous.

The 6 hour docking of Soyuz and Progress is already done by placing the spacecraft within 50 km of the station.

 

[MaverickSawyer]

Hrm... Any idea what the ISP is yet? Also, how much space is available in the "tail"? It appears to be a lattice array, so it might be possible to shoehorn in some more propellant tankage there... Unless there's a way to boost the ISP. :hmm:

In any case, it's your project. Don't get discouraged by Urwumpe: He just gets a little grumpy sometimes. :lol: Make it how you want, and anyone else who likes it can download it. Those who don't are welcome to make their own.

 

[Urwumpe]

In any case, it's your project. Don't get discouraged by Urwumpe: He just gets a little grumpy sometimes. :lol: Make it how you want, and anyone else who likes it can download it. Those who don't are welcome to make their own.

:dry:

 

[C3PO]

That's just the thing, in realistic orbital operations with a tug at the station, a new module would probably be delivered to a different orbit to minimize the risk of a high velocity collision or of the station being hit by the booster's engine plume. My understanding is that the Shuttle, at least, tended to cover the last few kilometers of a rendezvous over the course of several orbits, and that the last few hundred meters took half an orbit to a full orbit. So even assuming that modules were delivered to a point a few hundred meters from the station (which is as close as they could safely be delivered, the ISS is 100 meters in its largest dimension), you'd still be fairly likely to bust your 55 minute limit. A tug with the mission profile you describe for this one should have resources for several orbits, your medium tug should probably be able to operate independently for several days (and should be able to keep a crew alive for an other several days beyond that in case of a breakdown without any other spacecraft close by).

The STS transition from R-Bar to V-Bar relies totally on orbital mechanics, and can't be speeded up. It would make sense to utilize those mechanics when hauling large modules in close proximity to a station. This means that you need at least ½ an orbit for the actual maneuver, and probably 2-3 times that much time for setting up for it and the final approach.

You can't even get the tug to the station without another tug getting it there, rendering it rather obsolete. If you have a larger tug for retrieving payloads from lower orbits, why would you need the small one? Different classes of tugs for different sizes of payloads would make much more sense.

But hey! One of the great things about Orbiter is that you are literally free to do whatever you want. :thumbup: I still think it looks awesome!

 

[Linguofreak]

The STS transition from R-Bar to V-Bar relies totally on orbital mechanics, and can't be speeded up.

It can be sped up by aggressive and unrealistic maneuvering, which is what I tend to do in a near-station environment, partly because I'm impatient, partly because Rendezvous MFD seems to have its accuracy thrown off by nonspherical gravity (and, with regards to reckless maneuvering in orbital insertion, partly because direct ascents are incredibly fun to fly).

I tend to use transit velocities around 5 m/s near a station, which allows for a range of a few km with reasonably straight trajectories.

But a tug should certainly be designed with realistic maneuvering, and thus multi-orbit maneuvers, in mind.

 

[Depth08]

Then change the bell-shape for something vacuum like.

I'll see what I can do with it...

A new radar system would be great too.

That's a fact, it won't resemble existing systems though. Something completely different.

I see what most of you guys mean with the 55 minute limit. I tend to use more agressive manoeuvers instead.

ISP would pack quite a punch (better than DragonFly) Yet risks of thruster blast is not involved here.

I'm still not completely sure about it all.

 

[Urwumpe]

I'm still not completely sure about it all.

Well, we are not suffering much despite the DG kicking a few many GigaJoule into the air without the tiny thrust chamber vaporizing.

If you do it wrong, make it so wrong, that nobody thinks about it.

I prefer realism because it imposes its own challenges - but you can also leave the bounds of reality behind you and still have a logical world around it.

The rational problem with too aggressive maneuvering is just, that it consumes WAY more fuel, especially if you pull very heavy payloads. You might not notice it after 55 minutes and restarting Orbiter then. But if you do multiple missions and refuel from a space station which is itself limited in fuel, fuel economy becomes very important.

Also, it would be the question in Orbiters rather realistic world... would using multiple tugs maneuvering around a very large and heavy payload work? Like using one big tug for bringing it from a lower orbit to the space station and then dock a smaller tug to the other end of the payload for reducing unwanted translations or rotations while maneuvering the payload into position near the station.

 

[C3PO]

It can be sped up by aggressive and unrealistic maneuvering, which is what I tend to do in a near-station environment, partly because I'm impatient, partly because Rendezvous MFD seems to have its accuracy thrown off by nonspherical gravity (and, with regards to reckless maneuvering in orbital insertion, partly because direct ascents are incredibly fun to fly).

I tend to use transit velocities around 5 m/s near a station, which allows for a range of a few km with reasonably straight trajectories.

What I meant was that orbital mechanics can't be speeded up. You can get there much quicker, but then you can't rely on orbital mechanics to help you get there.

In the real world you have to deal with no-spherical gravity too. In the Gemini/Apollo era they had to compensate to stay on track, and I find it very satisfying to be able to do that. Using Rendezvous MFD I can pick any spot close to the target and arrive there 'safely'.

It's down to the player's personal preference how aggressive the approach can be flown. Personally I'd consider anything above 1 m/s inside 500 meters from a manned target a failure. I can do the Hollywood approach too, but I think it's more fun getting an underpowered craft safely docked.

Both approaches are valid, but my point was that the 55 min limitation rules out my preferred way to work around a station.

 

[Depth08]

Ok so up until now I wasn't aware of orbital manoeuvering, had been thinking fuel consumption was the main issue to tackle. I understand now. So does 16 hours sound like not too much, but good enough to work with?

I'm trying to include some realism but it won't all be 100% mathematically correct. It won't be like the DG either, just somewhere in between.

Oh I have to mention also, can anybody give me some extra help getting custom sounds for my DLL?

Thanks!

 

[Zatnikitelman]

16 hours sounds like plenty. I personally was thinking more around 6 hours if you're really want to skimp on the consumables, that's about what a spacewalk lasts already.