[WIP] mini reentry pod aka escape pod

[MaverickSawyer]

True. I just can't help but think of the little newton-class thrusters I've seen on display at the Museum of Flight here in Seattle... or some of the MR-series thrusters from Aerojet Rocketdyne:

MR-111, 5 N thrust. 330 grams mass, 169 mm long. I_sp in vacuum: 213-224 seconds.

 

MR-106, 22 N thrust. 590 grams mass, 182 mm long. I_sp in vacuum: 229-235 seconds.

[TiktaalikDreaming]

4 hours ago, MaverickSawyer said:

True. I just can't help but think of the little newton-class thrusters I've seen on display at the Museum of Flight here in Seattle... or some of the MR-series thrusters from Aerojet Rocketdyne:

MR-111, 5 N thrust. 330 grams mass, 169 mm long. I_sp in vacuum: 213-224 seconds.

 

MR-106, 22 N thrust. 590 grams mass, 182 mm long. I_sp in vacuum: 229-235 seconds.

These rcs are at 100N though, so YUGE compared to those. Well, slightly bigger anyway. 

[TiktaalikDreaming]

After actually looking at some cold gas thrusters, they seem to have a nozzle to valve size ratio that goes up as the size of the thruster goes up.  For a 5N nozzle, the valves are still bigger than the nozzle.  At the low end, the nozzle almost disappears.

I'm going to leave the 100N nozzles as they are (mostly because I've trapped myself a bit there, those will be hard to change), but the rotational nozzles will shrink, but get larger valve sections;

like;

I'll separate out the RCS config for those so they have a fair bit less thrust than the main ones.

 

[TiktaalikDreaming]

OK, some lessons learnt.  Looks like a single part can't have two separate ModuleRCSFX instances, or something else I was doing was broken, but I'm reverting to all the RCS being of the same thrust.

After testing repeatedly and getting issues with crazy levels of spin, it appears the issue was (predictably, but I didn't realize for a while) that the parachute module is not centred, so the CoM is not centred, thus spin.  So I adjusted the chute part centre to fake a CoM at the middle, and although I fixed the spin, the pod hangs from the imaginary middle when descending on the chute.  So I'll be moving the CoM of the chute back to sanity, and doing some crazy adjusting the CoM for the pod itself to get the total CoM central.  I added a teeny bit of gimbal to the SRBs so it doesn't need to be exactly central. but it will need to be pretty close.
 

[Shadowmage]

5 hours ago, TiktaalikDreaming said:

OK, some lessons learnt.  Looks like a single part can't have two separate ModuleRCSFX instances

Indeed they can (have multiple ModuleRCSFX).  What issue where you running into?   Will be glad to help sort it out if I can.   (I have a part that is using at least 3 different ModuleRCSFX, all with differing thrusts)

 

[Tyko]

10 hours ago, TiktaalikDreaming said:

After actually looking at some cold gas thrusters, they seem to have a nozzle to valve size ratio that goes up as the size of the thruster goes up.  For a 5N nozzle, the valves are still bigger than the nozzle.  At the low end, the nozzle almost disappears.

I'm going to leave the 100N nozzles as they are (mostly because I've trapped myself a bit there, those will be hard to change), but the rotational nozzles will shrink, but get larger valve sections;

like;

I'll separate out the RCS config for those so they have a fair bit less thrust than the main ones.

 

Wow...this is looking really cool! I've been following along and can't wait to try it.

I'd almost rather have an open node on top and attach a standard docking port JR rather than a custom one.  I guess the trade off is higher part count...

[TiktaalikDreaming]

7 hours ago, Shadowmage said:

Indeed they can (have multiple ModuleRCSFX).  What issue where you running into?   Will be glad to help sort it out if I can.   (I have a part that is using at least 3 different ModuleRCSFX, all with differing thrusts)

 

Oh. Well, when I tried, only the second of the two configs worked. I wasn't sure about defining the effects to be honest. It's that one big section with multiple subsections or multiple main effects sections?

If it's confirmed it does work then I'll put my head down and make it work. After I do some maths to get that centre of mass correct. It's kind of annoying to spin like a crazy thing when trying to deorbit.

4 hours ago, Tyko said:

Wow...this is looking really cool! I've been following along and can't wait to try it.

I'd almost rather have an open node on top and attach a standard docking port JR rather than a custom one.  I guess the trade off is higher part count...

The docking port is pretty much the exact same size as the stock junior. And interoperates. It does mean you can't switch it out for a custom node, and it forces the use of docking nodes. No attaching using just a decoupler.

But yeah, it's too keep the part count to a bare minimum. Not just for the physics engine, but also because it's a pain to add a multi part pod on the side of craft in the vab.

[DStaal]

16 hours ago, TiktaalikDreaming said:

 

I just want to say - that's gorgeous.

[Shadowmage]

14 hours ago, TiktaalikDreaming said:

Oh. Well, when I tried, only the second of the two configs worked. I wasn't sure about defining the effects to be honest. It's that one big section with multiple subsections or multiple main effects sections?

IIRC you need to add an 'fxPrefix' entry to each ModuleRCSFX config, with a unique name for each module.  They should be able to point to the same EFFECTS block node.

Effects node:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L178-L204

partmodule configs:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L568-L1016

Yes, there are 6 instances of ModuleRCSFX on the part.  As far as I know they all work correctly.  Ignore the SSTU_FIELD stuff; that is specific to that part setup, and shouldn't effect the EFFECTS.  I'll double check this evening and let you know for certain.

[TiktaalikDreaming]

6 hours ago, Shadowmage said:

IIRC you need to add an 'fxPrefix' entry to each ModuleRCSFX config, with a unique name for each module.  They should be able to point to the same EFFECTS block node.

Effects node:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L178-L204

partmodule configs:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L568-L1016

Yes, there are 6 instances of ModuleRCSFX on the part.  As far as I know they all work correctly.  Ignore the SSTU_FIELD stuff; that is specific to that part setup, and shouldn't effect the EFFECTS.  I'll double check this evening and let you know for certain.

Awesome. I can pretty clearly see where I've stuffed up.

That part is wall to wall example.

[Shadowmage]

18 hours ago, TiktaalikDreaming said:

Awesome. I can pretty clearly see where I've stuffed up.

That part is wall to wall example.

Note that I've just updated the part config in the dev branch to fix some issues that I didn't catch initially.  Notably, I fixed the 'transform names' for the EFFECTS nodes, and had to give each part-module its own running-effect (due to the different transform names), and reference that effect in the rcs part-modules.

https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L178-L339

https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L703-L1151

I can confirm that it -does- work though with this updated config.  All of the RCS ports fire as they should, and the particle effects work appropriately.

 

[TiktaalikDreaming]

On 6/9/2018 at 1:05 AM, Shadowmage said:

Note that I've just updated the part config in the dev branch to fix some issues that I didn't catch initially.  Notably, I fixed the 'transform names' for the EFFECTS nodes, and had to give each part-module its own running-effect (due to the different transform names), and reference that effect in the rcs part-modules.

https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L178-L339

https://github.com/shadowmage45/SSTULabs/blob/dev/GameData/SSTU/Parts/ShipCore/Series-E/SC-E-FS.cfg#L703-L1151

I can confirm that it -does- work though with this updated config.  All of the RCS ports fire as they should, and the particle effects work appropriately.

 

Ah, great. I was wondering if the older config suggested the effects transform name was capable of partial matches.

The main insight for me was just the structure around how to have multiple effects, which I realised I've done before for multi mode engines. And that rcs can have that link through to a named effect, rather than just running.

thanks again

Edited June 11, 2018 by TiktaalikDreaming

[TiktaalikDreaming]

And, hopefully no-one really liked the basic KSP grey look too much.  I'm going to change over to International Safety Orange.

(obviously I haven't layered all the colours on for things that won't be the base colour yet, but you get the idea)

Edited June 10, 2018 by TiktaalikDreaming
Added rescue pic

[TiktaalikDreaming]

I've packed the github bits as a "release"...   https://github.com/TiktaalikDreaming/KOOSE/releases

There's clearly still a fair bit of work to do.  Especially, I'd like to get the CoM right once the chute is attached so the thing doesn't spin like crazy when the SRBs are fired.  Using a bright orange colour certainly helps finding areas I haven't layered on their own colour for, so texturing should actually speed up now.  The heat shield very much needs work on texture.  The IVA isn't textured at all yet except to remove the orange layer, so there's work to do there, and the kerbal position is still wrong.  But I'm happy to release without a fully working IVA.  I'm also working on a fairing piece for the heat shield in case anyone wants to attach a service module.

[TiktaalikDreaming]

A mostly functional KOOSE is now released (https://github.com/TiktaalikDreaming/KOOSE/releases/tag/0.3); 

A few things still to do before it's a releasable mod, but it's getting there.

Time to reword all the stolen config. 

[DStaal]

14 hours ago, TiktaalikDreaming said:

I've packed the github bits as a "release"...   https://github.com/TiktaalikDreaming/KOOSE/releases

There's clearly still a fair bit of work to do.  Especially, I'd like to get the CoM right once the chute is attached so the thing doesn't spin like crazy when the SRBs are fired.  Using a bright orange colour certainly helps finding areas I haven't layered on their own colour for, so texturing should actually speed up now.  The heat shield very much needs work on texture.  The IVA isn't textured at all yet except to remove the orange layer, so there's work to do there, and the kerbal position is still wrong.  But I'm happy to release without a fully working IVA.  I'm also working on a fairing piece for the heat shield in case anyone wants to attach a service module.

I did a quick test myself - pretty much seeing the same as you.    Ran out of EC on the way down, way before I needed to release the chute.  (Again, USI-LS uses EC - may either want to write a config for USI-LS, or just up the base EC.)

The one other thing is that it spun widely on reentry, and couldn't keep the heat shield to the front.  (Using the KOOSE heatshield.)

Reentered from about a 120,000km orbit this time, with monoprop to spare - though I needed it during reentry to keep the capsule oriented.

[TiktaalikDreaming]

4 hours ago, DStaal said:

I did a quick test myself - pretty much seeing the same as you.    Ran out of EC on the way down, way before I needed to release the chute.  (Again, USI-LS uses EC - may either want to write a config for USI-LS, or just up the base EC.)

The one other thing is that it spun widely on reentry, and couldn't keep the heat shield to the front.  (Using the KOOSE heatshield.)

Reentered from about a 120,000km orbit this time, with monoprop to spare - though I needed it during reentry to keep the capsule oriented.

I've just realised that I have three parts and I've tried to balance the CoM with the two that have changing masses.

I had troubles when I changed the centre of part on the chute, with the pod acting like the chute was central, even though it clearly wasn't. But I never actually tried changing the centre of mass for it.

I'll check how that behaves and update.

[TiktaalikDreaming]

I changed the CoM of the chute, and put the other parts back where they should be.  It's a LOT more stable.  But, at the end of the SRB burn, the thing still starts rotating.  I suspect the gimbal is acting up as it's backwards and placed a bit differently versus the CoM than normal. 

I've updated the git repo but not repacked as a release yet.  I want to do a pass through the text and so on.  I should also invent a manufacturer and so on.

[TiktaalikDreaming]

Tidied up the config, even made it localizable, and have put it up on SpaceDock as a release candidate thingy.  Repacked on github as the same version (0.9) as well.

All 3 parts (soo many) are made by Eskape Kapsule Pty Ltd

I would have done Kerbal Electrics, but that's already in use for a lights pack.

[TiktaalikDreaming]

Welease fwed;

 

[TiktaalikDreaming]

I've started looking at a six way docking station that will fit a 2.5m profile;

Working on the main structure before adding aero shells etc.  The inner diameter is less than 1.25, but still fits 6 kooses around it.  The heatshields will be just at the outsides of the 2.5m cylinder.  I've had to use a trimmed down docking node as they interfered with each other, but it does occur to me that the KOOSE can't actually dock.  Without some extra RCS or balls of steel anyway.  It can't translate forward.  So the docking nodes will be pretty much disconnect with no reconnect.

[TiktaalikDreaming]

The colliders are going to be fun;

 

Edited June 14, 2018 by TiktaalikDreaming

[DStaal]

6 hours ago, TiktaalikDreaming said:

Working on the main structure before adding aero shells etc.  The inner diameter is less than 1.25, but still fits 6 kooses around it.  The heatshields will be just at the outsides of the 2.5m cylinder.  I've had to use a trimmed down docking node as they interfered with each other, but it does occur to me that the KOOSE can't actually dock.  Without some extra RCS or balls of steel anyway.  It can't translate forward.  So the docking nodes will be pretty much disconnect with no reconnect.

Which of course leads to the question of why they're docking nodes in the first place.  Decouplers would be role-appropriate.

And if you wanted to replace the pods you've used, you just have to send an Engineer with a wrench.

[TiktaalikDreaming]

6 hours ago, DStaal said:

Which of course leads to the question of why they're docking nodes in the first place.  Decouplers would be role-appropriate.

And if you wanted to replace the pods you've used, you just have to send an Engineer with a wrench.

Well, they're docking nodes because decouplers are a stage, and one stage per part.

[Tyko]

I'm suddenly picturing a mission to replace the pods using some special docking tug...hmmm