Project LR1 Skyhammer: A New Shuttle [p1]

[Scav]

Neat! I'm definitely interested to hear how this goes.

Here you go sir!

Launch was done at the 335' pad heading. Maintained pretty much a near-optimal pitchover regime after roll maneuver complete; at +20' pitch w.r.t. local vertical about 7 seconds after outboard cutoff the RTLS decision was made.

Pitchover took about 5-6 seconds to complete, at which point the last of the fuel in the ET was expended and the tank was jettisoned. I maintained between 30'-65' positive pitch to maintain my TTL (BIG help there keeping the sinkrate down!).

End result:

Yellow lines on the right-hand MFD (if you're unfamiliar with the symbology) denote absolute altitude, green lines denote velocity. As you can see by the sharp yellow line I'm over altitude but by the sharp green line I'm within projected velocity requirements by the time I manually cut off the mains.

This configuration left me feeling confident I could deadstick it through the HAC and achieve a landing given proper pilotage.

You might force me to renege and actually implement aerodynamics in the tank separation.

Uhh, no. I don't want to force you to do anything outside of getting this project done right -- which you've already done a bang-up job of without my help.

With regards to the tank separation, there's that negative-pitch juke that happens when the hinges let go -- we know about that. What else are you thinking of?

 

[kocmolyf]

With regards to the tank separation, there's that negative-pitch juke that happens when the hinges let go -- we know about that. What else are you thinking of?

At the moment, the only force which can separate the tank from the orbiter is the engine thrust. If you are flying in the atmosphere, the relative aerodynamics between the loose tank and the orbiter should also play a part. However, this is still pretty "nice-to-have" compared to, say, a reaction control system.

 

[K_Jameson]

Regarding the external tanks, i was surprised by how late the separation occurs.
Looks like the internal tank capacity is much lower than I thought. In my project (see above) the staging occurs long before, because the internal tanks are proportionally larger (and thus the cargo bay is smaller).

 

[kocmolyf]

Looks like the internal tank capacity is much lower than I thought. In my project (see above) the staging occurs long before, because the internal tanks are proportionally larger (and thus the cargo bay is smaller).

The Skyhammer is actually fairly far from optimal in this regard - if your goal is to minimize the gross liftoff mass, the internal tanks should be much smaller! I tried to strike a balance between small vehicle dimensions, minimal expendable mass (discarded drop tank material), and high internal delta-V to support abort scenarios.

It turns out that above a certain threshold of orbiter internal delta-V to external tank delta-V, your orbiter quickly becomes enormous while your external tank stays roughly fixed in size. I suspect your design might be inside that region (but it's hard to say without numbers).

 

[K_Jameson]

The Skyhammer is actually fairly far from optimal in this regard - if your goal is to minimize the gross liftoff mass, the internal tanks should be much smaller! I tried to strike a balance between small vehicle dimensions, minimal expendable mass (discarded drop tank material), and high internal delta-V to support abort scenarios.

It turns out that above a certain threshold of orbiter internal delta-V to external tank delta-V, your orbiter quickly becomes enormous while your external tank stays roughly fixed in size. I suspect your design might be inside that region (but it's hard to say without numbers).

My project was in a very early stage of design and only basic numbers were calculated. If i recall correctly, the total fuel was subdivided in roughly equal parts: 33% in the orbiter and 66% in the two drop tanks. The tanks feeds all three engines via crossfeed technique and, at the staging, we have cutoff of the two external engines and the central remains online, feeded form the orbiter internal tank.
Staging comes, i think, at around T+185 sec and MECO (if the central remains at full throttle) at around T+465 sec.

 

[kocmolyf]

OK, I've decided to give orbital operations a shot before I work on approach and landing. The two orbital maneuvering engines are pretty easy. They're basically wimpy main engines, and will use the same gimbal control logic. The inclusion of torch igniters means you can start those guys as many times as you want.

The reaction control thrusters, on the other hand, are super complicated. I could cheat and create some magic pure-axis thrusters, but I don't want to do that. So instead, I'm learning about linear programming and matrix pseudoinversion to perform the thruster selection logic given pilot input commands. I expect this will be the most difficult part of the entire addon until I start tackling the fluid systems in more detail. So don't be surprised if there isn't a lot of visible progress for a while.

Wish me luck!

 

[Nicholander]

Good luck, but for the next update, could make killrot or any kind of thing to stop any attitude drift work?

 

[kocmolyf]

Good luck, but for the next update, could make killrot or any kind of thing to stop any attitude drift work?

Possibly. The default killrot will never work with the main engines unless I remove the engine gimbal motion and make it instantly snap, which I'm not going to do. It might work with the new RCS system (doubtful though).

A more likely solution for the main engines is to add roll and yaw damping to the steering controller. Not sure what to do about pitch yet.

The RCS will eventually get its own more sophisticated attitude hold system that will handle e.g. horizon-relative control.

 

[orbitingpluto]

The reaction control thrusters, on the other hand, are super complicated. I could cheat and create some magic pure-axis thrusters, but I don't want to do that. So instead, I'm learning about linear programming and matrix pseudoinversion to perform the thruster selection logic given pilot input commands. I expect this will be the most difficult part of the entire addon until I start tackling the fluid systems in more detail. So don't be surprised if there isn't a lot of visible progress for a while.

Wish me luck!

What your saying sounds like what Hlynkacg was grappling with in his AAPO project; if it is the same kind of stuff I think it should be worthwhile for you two to get in touch.

Also, add another request for some sort of stability control. Since yaw and roll seem to get away from me the most, that sounds good enough for me.

 

[DaveS]

Re: stability control. The way to go for that is to implement rate-commanded attitude control. That is how it works in just about every spacecraft.

 

[kocmolyf]

The way to go for that is to implement rate-commanded attitude control.

Yes, sort of. Technically it's already rate-controlled - the pilot inputs a desired acceleration, which changes the current rate. I assume you're referring to something more explicitly like the Shuttle hand controller, which I don't think is the best fit for keyboard-based controls.

I think with some added rate damping, ascent control is pretty good. On-orbit attitude control will definitely need to be more about transitioning between desired attitudes than flying like an aircraft.

---------- Post added at 10:32 PM ---------- Previous post was at 10:28 PM ----------

What your saying sounds like what Hlynkacg was grappling with in his AAPO project; if it is the same kind of stuff I think it should be worthwhile for you two to get in touch.

Thanks, I just found that thread - It is exactly the same problem. They seem to be running into the issues I would expect with a simplex solver, e.g. cycling. I will make a post detailing a solution when I have it working.

---------- Post added 10-22-14 at 06:29 AM ---------- Previous post was 10-21-14 at 10:32 PM ----------

Huh. So much for all my big talk. I have a working solution for the primary thrusters in Python - turns out scipy has some pretty decent linear programming solvers. They produce very reasonable results for the desired torques and forces I've input so far.

There are a couple paths forward here - I can either try to implement the full solver in C++ (most general), or I can generate some lookup tables for optimal thruster combinations and use those instead (easiest). The lookup tables might get a bit large if I try to take center-of-gravity motion into account, but it's very tempting to not have to implement my own solver. Hmm...

 

[Donamy]

KISS, is usually the best option, to keep your sanity.:tiphat:

 

[kocmolyf]

OK, I've settled on going the lookup tables route. I fiddled around a bit and confirmed a suspicion I had - you can compute thruster combination tables for each of the principle inputs (linear and rotational) independently. Adding these combinations together produces nearly identical results to solving for all six simultaneously (in my case, differences of micronewtons).

I was also able to plot and find where each of the solutions became "unreasonable" - e.g. started using the slight forward angle of the nose -Z thrusters to try and eke out a bit more aftward thrust (bad news for your propellant usage). So I have min/max values for each of the six inputs.

I will need to repeat this process for the verniers as well. I'm hoping to ignore center of gravity changes for now, but I'll have to do some analysis to see if that's reasonable.

I think this is going to work out pretty well, and give quite realistic results!

 

[K_Jameson]

A not related question: what escape system have you thought for your crew?

 

[kocmolyf]

Analysis reveals: thruster mappings are basically insensitive to the expected center-of-gravity movements during a mission. Next step is to hack my thruster tables into Orbiter to validate this.

Once that's done, I'll need to spend some time to figure out how the pilot will control all of this stuff (e.g. switching between main engines, orbital maneuvering engines, primary thrusters, vernier thrusters, setting attitudes, etc.). I don't think I'm quite ready to make a virtual cockpit (the exterior doesn't even have textures yet...) but this may require some kind of 2D panel to control properly.

A not related question: what escape system have you thought for your crew?

There's some discussion on this topic around post #33.

 

[orbitingpluto]

Once that's done, I'll need to spend some time to figure out how the pilot will control all of this stuff (e.g. switching between main engines, orbital maneuvering engines, primary thrusters, vernier thrusters, setting attitudes, etc.). I don't think I'm quite ready to make a virtual cockpit (the exterior doesn't even have textures yet...) but this may require some kind of 2D panel to control properly.

You could make a mfd that handles the user interface for now; I imagine it won't be as hard as panel, so it could be a easier interim option.

About the engine things, I think having a toggle, like a key for switching primary/vernier RCS would work well, though I'm not sure what would be a good idea for the main engines and OMS. It would be interesting to allow Shuttle-style OMS assists with the LR1, but it seems easier to simply not allow the OMS to be controlled until the mains are done, then switch the throttle to control the OMS automatically.

Since I brought them up, I might as well explain what a OMS assist was and why bother with them. Basically, instead of loading just enough OMS propellent for the mission, the idea was to brim the tanks and burn off the excess on the way up, allowing an increase in payload. It could be a neat feature for the LR1, but with something like 40 tons worth of payload to due east already, I don't feel like this vehicle is begging for a few more tons of payload. I might be the only one thinking that though

 

[K_Jameson]

kocmolyf, can you publish the specs of your Skyhammer (fuel capacity, empty weight, dimensions, main thrust and ISP)? Or these data are still "classified"? ;-)

 

[kocmolyf]

You could make a mfd that handles the user interface for now;

Yeah, I might end up going this route. It's a little lame that you have to separately enable the MFD module in settings, but it could do for now.

...with something like 40 tons worth of payload to due east already, I don't feel like this vehicle is begging for a few more tons of payload.

Yeah, it's probably OK for the moment. I also have a different upgrade in my pocket, which is to subcool the propellants to jack up the density.

kocmolyf, can you publish the specs of your Skyhammer (fuel capacity, empty weight, dimensions, main thrust and ISP)? Or these data are still "classified"? ;-)

Sure, although it's a bit complicated with all of the various propellant tanks. I'll give you the overview:

Orbiter inert mass: 99967 kg
Orbiter internal main propellant: 77057 kg CH4, 269589 kg O2
Orbiter internal OMS propellant: 6191 kg CH4, 20940 kg O2
Drop tank inert mass: 30382 kg
Drop tank propellant: 371036 kg CH4, 1297923 kg O2
Main engines: 30476 kN thrust, 380 s Isp (vacuum)
OMS engines: 125 kN thrust, 363 s Isp

---------- Post added at 01:26 AM ---------- Previous post was at 01:09 AM ----------

Better analysis reveals: actually lateral and vertical translation are quite sensitive to center-of-gravity movement. Oh well, I'll just tack on the extra dimension in the lookup table.

 

[kocmolyf]

OK! Basic control with the primary RCS thrusters is working. It's still a bit unrealistic at the moment because it uses throttling instead of pulse width modulation, but I'll work on fixing that. At least I validated that my gains generation method is correct.

Still tons of work left to do, but that was probably the largest unknown. The next biggest hurdle will be bringing up an MFD.

 

[kocmolyf]

I had a little time tonight, so I switched the thrusters from throttle control to pulse-width control. It's actually pretty awesome to watch the coupled thruster firings as you maneuver around; it looks a lot more like a Shuttle or Soyuz fly-around than your typical Orbiter craft.

This only further emphasizes the need for the vernier thrusters, though. Using fine controls is pretty painful as you get about one short thruster pulse per second. The default autopilots are also not pleased...

---------- Post added at 08:19 AM ---------- Previous post was at 06:33 AM ----------

I also probably need to add another mode to the thrusters that relaxes the constraint that e.g. rotation produces no translation. I think that's causing a lot of extra propellant burn when you don't really care that much unless you're in close proximity to another object.