Project Dragonfly Upgrade

[Rybec]

I've started work on a successor to the Dragonfly. There were a few things about the Dragonfly that kind of irked me, so I decided it was time for an update.

Here's some test renders of what I have so far (Untextured, I'll be texturing it as well):

Aprox. 4000 polys with no crew.

I've raised the cockpit so you can see over your payload. That was one of my primary concerns. About a year ago, I was working on a rather large station (I'm going to continue work on it soon, been away from Orbiter for a while).
You've probably also noticed the third propellant tank. I plan on using a variable center of gravity similar to the XR series, where you can shift the balance by pumping fuel to the rear tank (the effects of which I plan to scale based on how much fuel you actually have left). On small loads, this may be sufficient to reset the total CoG to it's normal position. On larger loads, it should at least reduce the amount of fuel needed to compensate for the weight shift.

I haven't decided what I'm going to do with the radar yet. I'd like to find some way of getting it to display outlines instead of dots, as my station has gotten so convoluted that the normal radar display is useless for navigation around it. I had to do most of my maneuvers from an exterior view or through the use of CameraMFD, set up to pretend all the hab modules had cameras on them. I figured that wasn't much of a stretch. (I might try to implement that as a built-in display later on).


I'm not convinced I like the truss design I've used. I'd like any input you guys have on that.


Here's my todo list:

-More detail on the mesh.

-Active CoG control via relocation of fuel in the tanks.

-Same or improved CoG compensation for maneuvering payloads.

-Life support/power systems as detailed as the original, but more "transparent" if you will. This means it will typically be handled by computer control, with manual overrides available in the event of failure.

-Potential for failure: All systems will have a constant variable chance of failing. Some things may fail gradually like a pump, other may blow without warning. This should happen often enough that you see it, but not often enough to be annoying. Failures will require manipulation of panel/VC elements to effect a repair or override. The fuel cell management panel would still exist, for instance, but it would be "behind" another panel that you have to open.

-A proper "safe" mode, like the DG-IV. I had to manually edit my station scenario a few times because even with everything seemingly shut down, some value on the Dragonfly would continue to update while it was docked and I was de/reorbiting my XR5s (did I mention I was launching four of them at once?). The value would eventually grow so obscenely large that Orbiter crashed. I'm not even sure what it was. I also had the thing just flat out stop working (fuel cells refused to light, all gauges showed nominal values) after being docked a while and had to completely make a new one. Maybe I wasn't doing it right.

-Full UMMU support, and maybe UCGO? I don't see where it would be useful here except maybe for emergency equipment. I could make a spare parts cargo needed for certain failure recoveries, or could carry an ISRU or UMMU re-entry cone (after converting it to UCGO, of course). Maybe an engine module for orbital manuevers, I don't know.

-Self-destruct on reentry unless docked or attached to a larger vehicle/in safe mode.

-Airlock controls, maybe a fuel-consuming APU like the XR series needed for airlock and CoG shift.

-Virtual cockpit

-Built in RMS with a better IK solver than the one in URMS, to make it more useful for assembly. If I'm successful with it, I'll probably make an URMS-style verion as well as an SDK of sorts. An URMS comes in real handy when attaching those little fuel tanks on the space station building blocks. An URMS with an end-effector orientation aware IK solver would be even better. I'll probably make it able to automatically orient to and grapple at attachment points, since the SSBB modules already HAVE them.



One more thing, though: This thing needs a name. The new cockpit reminds me of a frog a bit, but Leapfrog may be a bit silly for an orbital tug.

Thoughts/comments/suggestions? What features would YOU add to a station assembler?

CURRENT VERSION: Alpha 1
Readme:

 ______   ______ _______  ______  _____  __   _ _______        __   __      ____
 |     \ |_____/ |_____| |  ____ |     | | \  | |______ |        \_/         __/
 |_____/ |    \_ |     | |_____| |_____| |  \_| |       |_____    |      \/.|___ 
                                     Alpha 1

Install: Extract folders to your Orbiter install directory. Press button. Receive bacon. Comes with a comparison scenario with a Dragonfly2 docked to a Dragonfly.

Dragonly 2 aims to bring the Apollo-era Dragonfly up to near-future levels, or at the very least to a level where it'll see more use.

___     _    
 | _   | \ _ .
 |(_)  |_/(_).

GOAL:                                                                                                                                STATUS:
-Mesh improvements                                                                                                                   (IN PROGRESS)
-simplification of life support and power controls while maintating simulated complexity                                             (NOT STARTED)
-Damage and systems failure simulation                                                                                               (NOT STARTED)
-Adjustments to allow craft to be taken to orbit through standard payload lifting methods: shuttle, XR-series, rockets, DG-IV?       (XR5 COMPATIBLE)
-UMMU/UCGO support                                                                                                                   (NOT STARTED)
-CoG shifting via fuel tank levels                                                                                                   (NOT STARTED)
-Preservation/enhancement of stock Dragonfly CoG compensation computer                                                               (COMPLETE?)-unchanged
-Virtual Cockpit                                                                                                                     (NOT STARTED)
-RMS with better IK solver than URMS (End-effector orientation specific, auto dock alignment, direct trans/rot of TARGET, not ARM)   (NOT STARTED)
-Airlock                                                                                                                             (NOT STARTED)



Included files:
Orbiter
    Config
        Vessels
            Dragonfly2.cfg
    Modules
        Dragonfly_2.dll
    Meshes
        Dragonfly2.msh
    Scenarios
        Dragonfly2 Demonstration.scn

Changelog:
Alpha 1- First compile from Dragonfly source, start of new mesh. Camera raised to match mesh. Vessel is XR5 payload compatible, but has the wrong payload icon. (based off Countdown84's Dragonfly XR5 mod)

KNOWN BUGS:
-The CoG compensation computer doesn't seem to work for me in my addon or the original under Orbiter 2010. Have not tested other versions.
-Antennae don't function, not in my version and not in the original. I suspect something in here isn't kosher with 2010. If so, then it's a wonderful time to do an update.

Please do not re-distribute this addon until it's complete. Post any bugs you find.

 

[N_Molson]

Looks very good ! An update of the Dragonfly is indeed an excellent idea. :thumbup:

Will it fit in a Space Shuttle cargo bay ? In a 6m fairing ? in a 5m fairing ? It was one of the problems of the original one.

 

[HAL9001]

Looks very good.
What would nbe about a manin thrust (just a weak one, but enough to change orbit).

 

[Usquanigo]

I would suggest elongating the rear truss quite a bit and making it foldable for being launched in something reasonable (ie, NOT an XR5 lol). Also moving the front thrusters as close to the leading edge as possible (if not even on articulated trusses that allow them to actually extend past the front when a load is docked). And go with a larger fuel tank in back (maybe all 'round).

This would be so that the effects of mass on the nose could be handled more ably.

Probably need the main body to be smaller than the original too, like the DF-Lite. (this, combined with the collapsable truss would enable it to be launched on some real-world hardware)

The simplification of the life support is a great idea too, the stock DF is built with Apollo era tech, despite being a futuristic vessel by definition. An on/off with background handling is really how it ought to be, but the ability to go in to a deeper panel is a cool idea for emergencies. (like-wise, limiting fuel-based CoG shift effects to the amount of fuel and free tank space is also a cool thing to add, one more bit of realism)

A fuel cell should be enough for "apu", and even that should be limited in the amount of use, if you add a solar array to it. While in day light, with an array on most sides (probably just part of the siding, not something that needs to be deployed), it soaks up enough power to keep the fans, lights and scrubbers working, but when you go into night, then the fuel cell needs to kick in. With energy efficient fans, pumps, and lights that we have even today, I really don't see that being a problem. The most draw would be from an RMS arm. So if you wanted, you could make that thing require the fuel cell even while on solar power, and increase the fuel cell draw while in night (if someone wanted to use it at night to begin with).

Keeping the radar display (or an improvement on it) would be a great thing too.

Regarding the break up on re-entry, I don't know enough about the sdk, but wouldn't it be enough just to go by Dynamic Pressure or temperature or something? That way, you don't need to check if it's docked to something or not, as if it's inside a fairing (like the shuttle bay) it would be sheilded from the pressure and temp anyway.

Speaking of which, I wonder if it would be possible to set up attach points that would allow the truss to be removed and attached. Say you needed to bring it home but don't have a space shuttle at your disposal, and are only using realistic vessels. You could eject the truss and try to fold up the cockpit so that it fits into the XR-2 or DG-IV bays (not that they are terribly realistic, but they can be edited down to be reasonable if people choose), the HyperDart would be another one.... or even the UMMU paracone maybe. But however you get it down, you then take it back up and either re-attach the truss, or bolt a new one on.

 

[HAL9001]

why don't do it in a ucgo-cargo just like the rescue boat, but as spaceship?

 

[Rybec]

I would suggest elongating the rear truss quite a bit and making it foldable for being launched in something reasonable (ie, NOT an XR5 lol). Also moving the front thrusters as close to the leading edge as possible (if not even on articulated trusses that allow them to actually extend past the front when a load is docked). And go with a larger fuel tank in back (maybe all 'round).

This would be so that the effects of mass on the nose could be handled more ably.
...

Hmm. That's a bit further than I was planning on taking it. I like it! Some sort of telescoping boom for the attitude thrusters did cross my mind though. Some kind of combination should be effective. I'm assuming moving the location of your thrusters in a DLL-based ship is fairly trivial. I don't see why it wouldn't be.

Regarding the break up on re-entry, I don't know enough about the sdk, but wouldn't it be enough just to go by Dynamic Pressure or temperature or something? That way, you don't need to check if it's docked to something or not, as if it's inside a fairing (like the shuttle bay) it would be sheilded from the pressure and temp anyway.

Yeah, I was thinking a simple dynamic pressure switch. I don't think being inside another craft actively shields it as far as the simulator is concerned, though. I though that was one of the main reasons for the DG-IV's safe mode. It disables the damage systems so you can have it docked to something without getting wing stress or acceleration damage and whatnot.

Speaking of which, I wonder if it would be possible to set up attach points that would allow the truss to be removed and attached.

Going more towards HAL's post, this could all be solved if it assembled from and packed back into UCGO components. Didn't someone already make something that only properly showed up once three cargos were unpacked?
I think having five or six unfolding combine-able cargoes would be the way to go. Once assembled, it would become the actual ship and be one unit until powered down and dismantled. It'd be a good use for the new action areas. Assemble it, then activate it. If assembled, the action area would break it into the separate (but still attached) components which could then be re-packed and moved.

At any rate, I'll make sure the end product, or at least a variation thereof, fits in the Space Shuttle and other standard fairings. For now, I'm going to stick with the current form factor until I'm up to speed on making the DLL work. Once I'm comfortable getting things to animate, I'll start changing it to an assembly package.
I suppose the easiest way to do that would be to have the cockpit be an actual ship, the other parts connect via auto-grappling attachment points, and the ship's abilities and whatnot are dependent on what's attached.

 

[Pilot7893]

This sounds like a great idea! Orbital operations like those done with the Dragonfly are my favorite in Orbiter, so having an upgraded craft to do them with would be fantastic.

 

[Urwumpe]

Go by destruction enthalpy... much more realistic

One of the problems is that Dynamic Pressure only gets the raw drag forces right, but not the effect of heating, which is more critical for spacecraft.

 

[River Crab]

:speakcool:
I think the stock Dragonfly is unloved for a lot of those reasons you had. I hope to see this succeed!

One feature I might like to see...since it seems in-line in terms of it's objectives, maybe you could size it to fit in a rectangle 3.5 x 3.0 x 11.7m? In other words, size of Starliner G42's bay?

Anyway, name suggestions: Bullfrog. Not too silly hopefully.
Or, going with the Dragonfly's name: Damselfly.

Although the way I see the shape, the tank behind the cockpit makes it look like a zombie-frog with exposed brain. :facepalm:
Sorry, I see things in weird ways sometimes (as has been proven many times in a certain other thread).

 

[Zachstar]

Nice work! And I like how you view over target now that was a PITA when maneuvering modules around before.

Good luck man!

 

[Izack]

Funny, I thought it looked very frog-like too.

 

[Hartmann]

A main engine could be good for change orbits or have a bit of freedom or use it to tug cargo between earth or moon

 

[Ghostrider]

A main engine could be good for change orbits or have a bit of freedom or use it to tug cargo between earth or moon

It could but the original Dragonfly was meant more like an orbital "bulldozer" or construction machine. I doubt anyone would want to stay in it for the duration of an Earth-Moon flight, and there are vessels that are more suitable to this task.

What the Dragonfly does well is hauling stuff around and assemble modules in orbit, and this should be true of the successor as well. In the Orbiter timeline we have very advanced ships like the DG-IV and Arrow, near-future spacecraft like the XR-series and utility ships like the Shuttle-A, with the Dragonfly looking very old-fashioned because it simply doesn't need to be more than that. It's a truck, or tractor.

Maybe a more powerful engine could be added - at a price. If the Bullfrog (or whatever it will be called) is made modular, you could have extra tanks and a stronger engine OR a manipulator arm or two, or a stronger set of maneouvering jets for heavier cargo. And maybe, just in case, an inflatable heatshield and parachutes for the crew module that could be made to separate from the truss and reenter in case of emergency. Maybe.

 

[Usquanigo]

It could but the original Dragonfly was meant more like an orbital "bulldozer" or construction machine. I doubt anyone would want to stay in it for the duration of an Earth-Moon flight, and there are vessels that are more suitable to this task.

What the Dragonfly does well is hauling stuff around and assemble modules in orbit, and this should be true of the successor as well. In the Orbiter timeline we have very advanced ships like the DG-IV and Arrow, near-future spacecraft like the XR-series and utility ships like the Shuttle-A, with the Dragonfly looking very old-fashioned because it simply doesn't need to be more than that. It's a truck, or tractor.

Maybe a more powerful engine could be added - at a price. If the Bullfrog (or whatever it will be called) is made modular, you could have extra tanks and a stronger engine OR a manipulator arm or two, or a stronger set of maneouvering jets for heavier cargo. And maybe, just in case, an inflatable heatshield and parachutes for the crew module that could be made to separate from the truss and reenter in case of emergency. Maybe.

I think the name Dragonfly should stick. Call it 2.0 if necessary.

Also, I will add that the reason it seems old fashioned isn't it's lack of engines or inherent utility, it's the Apollo era internals and pilot workload.

That said, you are bang on, the idea is to gather items together from a launcher and assemble them. NOT to drag them all over the place changing orbits and stuff like that, and CERTAINLY not taking it to the moon (that is what the Shuttle A is for, afterall). You need launch your modules into the proper orbit, then use the DF to put them together. (or even reverse, use it to disassemble something to be loaded into a recovery vehicle or booster to either be returned safely to Earth or be moved to a different orbit or even reference body)

You don't use an automobile assembly robot to cart pieces of the car from plant to plant.

 

[Zatnikitelman]

Actually, one thing that I particularly liked about the Dragnfly Lite was that it used the existing engines as "main" engines. I think they were twice as powerful though, but it added the "main" engine group which simplified things in Orbiter a bit as stuff like IMFD or Rendezvous MFD could work, and using something other than weighting down keys on your keyboard for extended duration burns was nice as well. I'm not talking about Earth to moon, or initial orbit to station orbit, but more like if you drifted too far from your station or target craft.

 

[HAL9001]

I now made my first Addon and it's a trie to pack the Dragonfly in a Cargo.
I tried to upload it, but therefore I need a special second Account and for the time it's not possible to create that special accounts.
So I'll trie to upload it here as an Attachment now (it's just 129kB):

View attachment Folded Dragonfly.zip

 

[Moach]

this is a great concept!

i have long thought that we were in need of an Orbital maneuvering craft... the dragonfly not having a VC bugs me most of all... it's such a cool vessel design :hmm: i ofte wish it was brough up to speed with the newer vessels, which are much more detailed, visually...

same goes for the shuttleA... but that's another thread :hmm:


now, packing it into some sort of launcher would be the business! i see a lot of potential and endless fun in this "space construction" aspect of orbiter... a maneuvering vessel is most important in such case :thumbup:



great work so far!

 

[HAL9001]

The box is trabnsparent for viewing the eath from orbit, while carrying that box.

 

[mc_]

not a problem

...added the "main" engine group which simplified things in Orbiter a bit as stuff like IMFD or Rendezvous MFD could work, and using something other than weighting down keys on your keyboard for extended duration burns was nice as well.

IMFD could use "autoburn" even with RCS retro :tiphat:
So it is not a problem to have no "main engines".

"RCS-only" should be enough for Dragonfly's purpose. Also, it saves weight ;-)

 

[Ghostrider]

IMFD could use "autoburn" even with RCS retro :tiphat:
So it is not a problem to have no "main engines".

"RCS-only" should be enough for Dragonfly's purpose. Also, it saves weight ;-)

Yes, but if your engines aren't strong enough it won't work very well. Instead of a main engine, maybe have a secondary, optional, stronger RCS set?