Project New Truss System for space stations

[Zatnikitelman]

My next project for Orbiter is to make a real-tech truss system for space stations. I've decided that to start with I'll have a pressurized connecting module, a basic "extension" truss with berthing points for unpressurized pallets, a radiator truss, and a solar truss. I'm also toying with the idea of a thruster truss with some auto-compensator similar to the Dragonfly to enable 3-axis attitude stabilization of stations.
I've started running into a slight problem though. I'm afraid these trusses might be too small!

http://i226.photobucket.com/albums/dd230/Zatnikitelman/basictruss.jpg

That is the basic "extension" truss I've been working on. It is 6 meters long and 2.15 meters measured across the flat sides and 2.48 meters measured across the points of the hexagon. I started thinking this whole system is too small when I tried to add a Power Data Grapple Fixture which is around .57 meters in diameter. That would seem to practically dwarf the truss itself (the pallet connectors are 0.15 meters in diameter). An advantage to this however, is that two trusses could fit side-by-side in a 5-meter launcher (STS, AtlasV, DeltaIV, Prometheus, etc.) Before I go much further with the modeling, I'd like to see what the community thinks about my scale so far.

http://i226.photobucket.com/albums/dd230/Zatnikitelman/pressmodule.jpg

Here's the pressurized module, it's 3.7 meters in diameter and berths to other pressurized modules with a CBM.

~Edited to change pictures into clickable links only, to reduce loading time

 

[fireballs619]

I, personally, think that the current scale looks very good. I don't really see a need to increase it, because, as you said, the ability to launch multiple trusses in with one lifter is a huge plus.

 

[MaverickSawyer]

Agreed. This is great for a start. Are the solar and radiator trusses going to be larger in length or diameter?

 

[n72.75]

I like it.

Keep up the good work.

 

[Zatnikitelman]

Not in their launch configurations; the radiator truss will of course deploy radiators from a folded state. The Solar truss, I currently plan to have the two solar arrays on each side, folded up against each other like the ISS arrays. When it deploys, the other truss-interface will extend outwards to give room for the array to swing around.

 

[Grover]

keeping the hab-modules roughly the same diameter as the ISS modules (i know they vary, but take an average or something ) gives you plenty living space. you could perhaps lose 300mm or so of diameter and still call them hab modules. (NOTE i didnt mention length for a reason, length can be anything you like)

as for trusses, they should ideally vary in length, with the longese being the length of an STS payload bay, and the shortest being a baby truss, say 1m for strutting paralell trusses.


and as my structural engineering skills are honed by my uni course, ive just noticed that those trusses are hugely over-engineered. let me put it this way. 2.4 metres is the displacement of a low ceiling to the floor (normal is ~2.6m) and 6m long is the length of two rooms. for something that small (compared to a spacecraft like the STS) you dont need that much material to hold it rigid, so your poor shuttle will be carting up mass that it doesnt need

one simple fix: make each strut of the truss narrower, reduce the mass, and increase the stress on each one (since it can clearly manage the stress of a spacecraft docking at 100mm/s already)

hope it helps, and nice work on the modelling!

---------- Post added at 12:59 PM ---------- Previous post was at 11:38 AM ----------

had a few thoughts;

how were you going to connect all of these together once they reach orbit? would it be as simple as docking them together to make a modular station, or would you do something a little cleverer? i suppose it should be possible to use attachment points if you re-write a simple docking code (if local attachment point is within 10mm of a foreign (and "compatible") attachment point, then attach the two, so the attachment points can be named after their visual (meshed) connector type, so the plate at the end of a truss might be have one prefix to the name (or a 'tag' to help define it, if the API allows), but the connection between two hab modules (which would be a CBM on the ISS) would have a different prefix, and the code would not allow the two to attach (unless you cheat using the SCNeditor or changing the scenario.scn)

on top of that, will there be any way to create a network of RCS or CMG (?) system to allow for station rotation? after connecting the modules, then can "communicate" to provide coherent attitude adjustments?

thanks man

 

[Zatnikitelman]

I've run into a few problems here as I'm developing the modules. My first problem is with the solar truss. I'd like to use a mechanism similar to how the ISS works but for simplicity, I was going to implement the central supporting truss as a linear scaling animation. However, in Orbiter's documentation, it still mentions that child scaling animations of rotations must be uniform which means I can't just scale up a central truss like I was intending to. So I've hit on another solution...which I've started to feel is a bit corny. Basically, a single small truss would be replaced by several long pieces which accordion-fold outwards and serve as the solar array backbone.

http://i226.photobucket.com/albums/dd230/Zatnikitelman/solartruss.jpg

That's what I'm talking about. That black, badly-aliased mass near the right-side interface are the accordion-folded trusses I'm talking about. I may go with it and test it in Orbiter just to see how it looks when deployed, but if there's a better, realistic idea on how to deploy ISS-type solar arrays while avoiding the problem with the lack of scaling animation.

The other problem is struggling with, is still the scale of the whole thing. I created a to scale Power Data Grapple Fixture and have started putting them on my modules, and with them in place, I'm reminded of just how small the trusses and their components are. For instance, here's the base of an unpressurized pallet with PDGF attached for scale:

http://i226.photobucket.com/albums/dd230/Zatnikitelman/smallpallet.jpg

With the PDGF centered over the pallet's attachment point to the truss, you lose just over 28cm of usable space on the space-side of the pallet if you want to use an RMS to move the pallets around. One option around this is to only make them movable via UMMU (visibly at least, I won't cripple the pallet in-code of course so ONLY a UMMU can grab it).

Grover: I wasn't planning on the pressurized modules being hab modules per se, basically just engineering modules with the equipment to handle the functions of the truss, but station builders are of course free to pretend the modules are whatever they want
I've taken your advice about variable sizes and will now have 6, 12, and 18 meter long "spacer" trusses (also the only trusses to mount pallets on [for now]). I've also taken your advice and shrunk the struts a bit, but I was thinking that the struts would be hollow to allow routing of power and data lines along the outside of each truss.
For the trusses themselves, it'd a simple matter of docking them. In real life of course, it'd be a 0-velocity berthing, but this is Orbiter and I'm not going to implement my own dynamical model for a simple addon, I'll leave that to Martin
The only trickery I'll do with attachment points will be with the pallets, they'll dock, then get their docking port swapped out for an attachment point to make mass distribution management easier on the end-user.
I'm planning to create a network of RCS trusses, but I'll need to study up on graph theory, and torque and some other stuff before I fully jump into that.

~Edited to change embedded pictures into clickable links only to allow for faster page loading.

 

[Grover]

simplest way for calculating RCS torque: run 3 different channels (one for each axis) and have each calculated independently, then its a case of calculating the distance that each thruster is from the stack CoG and running a one dimensional calculation 3 times

of course, you could always simply not bother with calibration, and just run the thrusters at full whack regardless of improper calibration, then your only problem is getting each thruster to work out which thruster group it belongs to :hmm: afraid i cant help there; my programming knowledge is basically 0.

if you want any help modelling any modules/components, just let me know, im pretty good at scaling models, partly due to my small library of stock and addon craft meshes that my sketchup has access to:
NOTE: ive never stolen any part of any mesh, just used them to scale my own models by measuring the existing models

-==edit==-
and heres one i made earleir

just a couple hours playing around

the hab module, the far side is the same (androgynous berthing connection)

and with it sat inside the atlantis' bay (for scaling purposes)

 

[Zatnikitelman]

Update on the progress. Unfortunately, I've had to start from scratch. After I finally found an STS Payload guide, I discovered that with the EVA handles, the system would be too big to fit side by side in the Orbiter's payload bay by about 10cm, yep, ten lousy centimeters Fortunately, it wasn't too hard to since my modeling skills have vastly improved since I started even on this, and this is the second time building it, just a bit smaller. But I'm basically back to where I was modeling wise when I found the proper dimensions.
Also, I thought I'd show the radiator truss and its tankage. I don't have the radiator panels themselves installed (or textured) yet, but there will be 8 of them, 4 on the top, 4 on the bottom; each one is 6 panels, .5m X .2125m X .01m for a total of 5.1m^2 radiating surface area per truss segment (actual dimensions will be slightly smaller to allow for the extension mechanism). There are 6 attachment points for coolant tanks, and there are 3 coolant tank sizes, 1.15m, 3.14m, and 5.08m long by 1.15m width and height (actual coolant volume to be determined later). The tanks will likely have an FRGF (same model as the truss's PDGFs) and a UMMU attach point, so yes, this truss system will likely be UMMU compatible
http://i226.photobucket.com/albums/dd230/Zatnikitelman/radiatortanks.jpg

~Edited to change embedded pictures into clickable links only to allow for faster page loading.

 

[Zatnikitelman]

Ok, here's some more progress showing how pallets will get to orbit. I've also made some changes to the truss carriers themselves. Originally, I was building STS only and inline launcher only versions of the carriers. The inline carriers would only have a passive CBM docking port and the STS version would only have trunnion pins and scuff plates. However, I've decided with input from other users, that it may be useful to dock even an STS payload to a station so now, the only difference between STS and inline carrier versions is the addition of trunnion pins to the carrier when it's flying on STS rather than having completely separate versions.
Below is the carrier for pallets. Pictured is the inline version; when configured for STS, there will be trunnion pins and scuff plates on each side at each end. The central section where the (mockup) pallets are in the picture can spin about the z-axis (perpendicular to the passive CBM ring) allowing access to pallets stored underneath while still in the STS payload bay, though I won't disallow spinning while docked to a station. I've only put together one segment for screenshot purposes, but I'm planning to allow at least 7 of those segments while in STS configuration and more in the inline configuration. This means a single Orbiter, mass allowing, can carry up to 42 external pallets into orbit assuming the pallet carrier is the only payload. I haven't checked the inline carrier size yet, but if I had to guess, I'd say around a maximum of 60 payloads (though I may not hard code this limit either).
http://i226.photobucket.com/albums/dd230/Zatnikitelman/stspalletcarrier.jpg

[EDIT]
One thing I forgot was to post a list of all current truss carrier configurations. The designation STS next to them means that those configurations fit, and have trunnion pins for mounting in the STS payload bay. I can forsee a need for the carriers to be launched by a rocket, but then brought back down via STS so it makes sense that they can be outfitted for STS even if not launching via STS.

*dual 6m STS
*quad 6m STS
*dual 12m STS
*dual 18m
*dual 6m/single 12m STS
*triple 6m/single 18m
*single 6m/single 12m/single 18m
*six 6m
*dual 6m/dual 12m

~Edited to change embedded pictures into clickable links only to allow for faster page loading.

 

[Capt_hensley]

I'd say they still look a bit over engineered, but all in all I like the progress you've made. I made a far simpler truss design for Gateway Station, but they carry a far lighter load. Just the MBSS, Arms, and payload attached to the arm on orbit. Only my modules carry the structural load of the station.

Size is a major consideration, and you've made the right choice. My trusses are 70' long and although they can go up in a limited few LVs, three to 6 can go up in one shot. They are so light in fact that other items will probably accompany them on the trip to orbit.

Grab Irons always get in the way. I considered installing them on orbit, but after a few quick calculations, I came to the realization that installing a few thousand grabs was a greater risk than was worth the return on investment.

I like the pallet feature. Attachment(assembly) methods are tricky, use the KISS principal and it should work out.

 

[Zatnikitelman]

I'm slowly making progress. College is taking up a lot of my time, but I'm on spring break this week, and the workload after should be smaller. I'm making a good bit of "behind the scenes progress" and really now it's down to the details, no major modeling work is left.
Here's the main point of this post though, I've done a test import of the 6m basic truss into Orbiter (just a .cfg vessel right now) and wanted to get everyone's opinion on colors, particularly for the inter-truss mating interface components. I'm thinking about adding some simple details to the pallet mounts just to stick something there and make the mounts stand out a bit from the rest of the structure, but I'm not sure what as I'm trying to avoid textures for the truss components (central module will have textures as will radiators and solar truss).

[EDIT] I was playing around with the pallet mount while writing the previous post, and have something that may work. Yes, I know this particular mount is scaled too long in one axis, but that won't be in the final model.

 

[Zatnikitelman]

Finally got a chance to work with the trusses again. Unless anyone has any comments on the design (see below), I'm freezing modeling development of the basic trusses tonight. In the first image from left to right, you see the 6m, 12m, and 18m trusses, and yes, over the ends of the interfaces, but not the connectors they are exactly those dimensions.

 

[Zatnikitelman]

It took me long enough, and I wanted to hurl my computer into the sun a few times, but I finally got the first "base" module textured and into Orbiter. Development on it is also frozen unless someone sees something major I need to do. The textures, particularly on the endcones are a tad wonky, but I've had enough staring at this thing's texture map. The next pieces I plan to show are the radiator and solar trusses. The radiator truss is basically done modeling wise, I just need to animate it so I'm not just showing another 6m basic truss. I'm not exactly sure how I want to do the Solar Truss, but I think I have a good idea for it, similar to the real ISS solar arrays. I've also pretty much finished the carriers. I've modeled several pallets that I'll include, but I'm hoping users will create their own; I'll be including a source model that users can use to base their own pallets off of. I'm hoping, but not promising, to kick this out the door before the end of the month.

 

[Loru]

Looks nice - waiting for complete system

 

[Zatnikitelman]

Wow, over a year since last update. To my defense I had OPH to work on in the interim, but I'm back on this, and actually charging forward. I hesitate to give much of a detailed status update since it seems that every time I do work grinds to a halt. The main purpose of this post however is to get some feedback (I hope) on how the pallets should work.

The "static" truss assemblies all have ports to mount "pallets" to similar to the ISS's External Stowage Platforms and Express Logistics Carrier. Basically designed for hardware that might need to be repositioned at times. I'm planing to release several example pallets including a materials exposure pallet, telescope pallet, spotlight pallet, and communications antenna pallet. The materials pallet is pure eye-candy, but the others will be animated, though I haven't decided if the comm. pallet will be animated or not yet.

The feedback I would like, is whether I should attach the pallets, or dock the pallets. I was thinking attachment points since they would ease keeping your stations balanced, but the docking points are not only easier on my end, but easier for any developers who want to make their own pallets. Under the current attachment system, the pallet docks, then the docking ports are swapped with attachment points and the pallet is attached as a child. But I don't just do this to anything that docks, only vessels that "give permission" so to speak, so if someone accidentally (or deliberately ) docks an XR2, or Arrow or anything else, I wouldn't be messing with those vessels. However, just keeping the docking keeps it slightly more realistic, and requires far less work from the developer, and gives the end-user a little more freedom. What does everyone think of the two ideas? Which one should I use?

 

[PhantomCruiser]

My first thought is that docking would be nice. When I first started out using Mustard's truss (Nebulus?) it was aggrevating to have the thing lined up perfectly, only to have to drop out and have to attach it manually by writing it into scenario file.

 

[Zatnikitelman]

Coming soon to a Tuesday near you:

 

[paddy]

I am loving this. plus anything in wings3d is a plus for me

 

[Zatnikitelman]

Happy Tuesday: https://www.orbithangar.com/searchid.php?ID=6401