-
Yaw steering and RAAN steering
by
Kaputnik
on 07 Jan, 2017 18:22
-
-
#1
by
meberbs
on 07 Jan, 2017 18:26
-
A docking spacecraft is in zero g and can take its time with the maneuver. You have all the authority you need, and can abort and try again.
An F9 doing a hoverslam is so completely a different thing.
It is decelerating at multiple g, in wind, with very limited controls, especially towards the end - mostly main engine gimbaling.
Not the same as docking
wrong. Avionics wise it is the same. Landing just has more constraints and external influences. The F9 always knows where it is going to land. Landing a vehicle is not hard (see lunar and mars landers).
Landing actually uses less external sensors (altitude radar). Rendezvous and docking require long range (star trackers, radar, etc) and short range (radar, lidar, TV, etc) sensors.
"more constraints and external influences" makes it harder, by a lot. The F9 knows only the coordinates of where it wants to go for landing, not what it is going to have to do to get there.
Also did you just seriously try to use Mars landers as evidence that landing is not hard?
The secret sauce of the reentry burn and the aerodynamic flight segment are unique to SpaceX and already more difficult.
Doesn't require any changes to the avionics to perform those tasks. Just a little more programming
How does adding additional control hardware and changing the software equal no changes to avionics?
Landing can be done independent of the actual time, unlike yaw steering and rendezvous/docking. That is a major change to the avionics/ flight software architecture
You know that GPS data comes with accurate measurements of current time for free right? And if GPS is being used at all, they already should have a mechanism for syncing the GPS data time stamp to the current internal clock time. They just have to then feed this already existing data into a yaw steering algorithm. (And this algorithm should be much simpler than a landing algorithm)
-
#2
by
Newton_V
on 07 Jan, 2017 18:33
-
I read some of that discussion. I think there's some confusion between guidance and navigation software (along with hardware to support it) and control systems (autopilots). They are 2 separate issues.
The people comparing to landing the booster are pushing the control system aspect and the associated difficulties. The targeting part is simple.
For yaw (RAAN) steering, it's the robustness of the software and how it converges under highly dispersed conditions (see OA-6).
Atlas has had this capability going back to the Atlas II days. Delta IV will have it this year.
-
#3
by
Robotbeat
on 07 Jan, 2017 18:45
-
How is yaw steering hard? You need more on board memory to store a look up table of launch solutions, but other than that, how is it hard? Particularly, how can it possibly be easier than landing?
Landing on a small platform with rockets, in atmosphere, and in Earth gravity is anything but easy.
Time reference
So a decent real time clock synced while on the pad. I'd be surprised if that wasn't already in use for a modern launch vehicle.
-
#4
by
CorvusCorax
on 07 Jan, 2017 20:27
-
Well, I'd say if you claim Yaw steering as a higher level navigational problem, and docking as a higher level control problem, then the hoverslam landing is both.
For yaw steering, if I understand it right you try to match two 4d trajectories. The vehicles current position and velocity versus the velocity and position of a hypothetical "target" vehicle that is on the optimal trajectory and launched at the perfect T-zero. As such you need to cost-optimize the transitioning to have the trajectories converge to 0 - error with minimal extra delta-v expense
A docking approach could be seen as a simplified subset, except your "target 4d trajectory" is completely static. ( unless you want to do something crazy, like dock 2 sattelites with ion engines while both or under acceleration)
Landing on a spot on the surface however is not as simplified. Even if you are in orbit, but on an interplanetary trajectory it becomes much more obvious, that in order to make reentry and landing on a specific point on the surface,due tonthr difference in orbital movement and planet rotation, you have to be on a spoton in a 4d trajectory that leads there on both correct place and time. From the perspective of an orbital vehicle, any point on the surface is under constant acceleration.
But then you have to deal with all the issues of unstable, under-controlled atmospheric flight, reentry, atmospheric uncertanities and wind from the moment of interface on, all of which don't exist on an orbital docking. Even the moon landing didn't have to deal with that.
To make F9s landing extra difficult, for an orbital docking you have an infijite number of solutions. You can hold indefinitely in a multitude of parallel orbits and try again with little extra cost.
For the F9 landing trajectory there is only one correct solution. You cannot recycle or hold anywhere. It cannot hover, and it has insufficient fuel to recycle ( accelerate upwards, turn engine off, then make a 2nd approach ) afaik the engine can't even turn on another time past the landing burn.
Once you end up on a trajectory that no longer converges that's it. Just like with yawcsteering.
But theres another difficulty. The possible solutions to yaw steering that converge can be precalculated in a lookup table.
Landing has to be calculated online.
The final landing approach is both a difficult control problem, and an advanced navigational problem. The calculation of the corrective trajectory if the vehicle is off course is all but trivial.
I'd say docking is the easiest of the problems
Followed by yaw steering
And when you have mastered both, you can join a harder league and try reentry and spot-landing in atmosphere.
-
#5
by
Robotbeat
on 07 Jan, 2017 20:45
-
Yaw steering requires more analysis to prove safety as well, since you now have a bunch more nominal trajectories to simulate.
I'm not saying yaw steering is trivial, just that it's almost totally a software problem for a modern vehicle. And software can be an enormous pain and very expensive.
-
#6
by
baldusi
on 07 Jan, 2017 22:39
-
I think Newton_V got it right. Yaw steering is a more difficult navigational problem, hoverslam RTLS is a more difficult control problem. Or said in other form, yaw steering is a more difficult "what to do" problem while RTLS is a more difficult "how to do it".
Clearly ULA has decades of working on the use requirement side of their avionics while SpaceX has been concentration on internal requirements.
-
#7
by
Kaputnik
on 08 Jan, 2017 09:57
-
Is Atlas the only vehicle that can do yaw steering?
-
#8
by
pippin
on 08 Jan, 2017 10:55
-
Shuttle did it, too
-
#9
by
Jim
on 08 Jan, 2017 13:17
-
Well, I'd say if you claim Yaw steering as a higher level navigational problem, and docking as a higher level control problem, then the hoverslam landing is both.
And that would be wrong.
The landing is fixed and known and never changes. There is no computing to determine or find it.
And it is just not docking, it is so rendezvous.
Landing on a spot on the surface however is not as simplified. Even if you are in orbit,
No, that is not part of the discussion. This is specifically about first stage RTLS. The first stage flies on a trajectory that when the vehicle is operating normally (no engine problems), it will have enough propellant to return to the launch site. It is purposely staged with that amount.
But then you have to deal with all the issues of unstable, under-controlled atmospheric flight, reentry, atmospheric uncertanities and wind from the moment of interface on,
The landing site is fixed and all that that requires is sufficient propellant margin to cover dispersions.
and an advanced navigational problem.
Again, wrong. The landing site is known and fixed. It stored on board.
I'd say docking is the easiest of the problems
Followed by yaw steering
And when you have mastered both, you can join a harder league and try reentry and spot-landing in atmosphere.
Wrong.
The docking target locationis unknown until the first sensor lockon.
Yaw steering is not a look up table, it is computed onboard
Landing is no different than achieving orbit. It is just has tighter constraints.
-
#10
by
Jim
on 08 Jan, 2017 13:44
-
BTW
we have been using the wrong term
Guidance refers to the determination of the desired path of travel (the "trajectory") from the vehicle's current location to a designated target, as well as desired changes in velocity, rotation and acceleration for following that path.
Navigation refers to the determination, at a given time, of the vehicle's location and velocity (the "state vector") as well as its attitude.
Control refers to the manipulation of the forces, by way of steering controls, thrusters, etc., needed to execute guidance commands whilst maintaining vehicle stability
With IMU's and GPS, navigation is easy.
Guidance for yaw steering and rendevous and docking is harder, there are more variables.
RTLS has more external influences but that was just beefing up the control portion.
There is no active feed back with propellant utilization for RTLS.
-
#11
by
Silmfeanor
on 08 Jan, 2017 15:05
-
So far this discussion has been rather unfruitfull - instead of asking about Yaw steering, what it requires and which LVs did it, we get 'landing/docking is harder /easier than yaw-steering' combined with various opinions of SpaceX.
Those are other discussions.
I am wondering - just to see if I understand it - that Yaw steering requires just engine gimbals for steering during launch. Most, if not all, launch vehicles have that. The problem lies in the guidance package, perhaps combined with specific sensors.
Some vehicles have proven they can do it - thus, they have both working. Other vehicles have the gimballing, so the only other thing that should make yaw-steering work for them is guidance code, and / or some specific sensors.
Is that correct?
-
#12
by
LouScheffer
on 08 Jan, 2017 15:26
-
But for SpaceX, it's almost surely software. The first stage is solving convex optimization in real time, a much harder task than yaw steering.
Not true. Targeting for yaw steering is harder. Again, the landing pad is a static target and always be in the same place no matter what time it is launched. Launching into a specific orbital plane at anytime within a launch window is much harder.
The Apollo-Soyuz rendezvous did this (launch anywhere with an 8 minute launch window) in the early 1970s. This was implemented by the Apollo computer, which had 12,000 instructions per second. Here's
a description by one of the implementors.Even further back, the Atlas-Centaur could do near-optimal yaw steering. This was used on the HEAO missions, as detailed in
Bilinear tangent yaw guidance:
This paper presents a parametric yaw steering law which has been used to provide closed-loop yaw guidance for the launch of the HEAO (High Energy Astronomy Observatory) satellite mission using the Atlas/Centaur launch vehicle. This bilinear tangent steering law provides near optimal yaw steering for maneuvers requiring insertion into orbits with a specified inclination and node. [...] The flight computer implementation of these laws in a rotating coordinate system using real-time integration of the equations of motion is detailed. Explicit solution of the parametric guidance equations requires the inflight solution of (2x2) two-point boundary value problems in the pitch and yaw planes. Excellent results are obtained even for very large (greater than 50 deg) out-of-plane
And even further back, Gemini XII used lots of yaw steering, since they were rendezvousing with a target launched 90 minutes earlier. From the
Gemini 12 mission reportAt spacecraft insertion, the range between Spacecraft 12 and the Gemini XII GATV was approximately 500 nautical miles, and the out-of-plane velocity error resulting from the spacecraft launch-vehicle ascent yaw steering was about 8 ft/sec.
This mission had a 33 second launch window. So even if you can't update the solution for any time within a launch window, (even though Apollo and HEAO did this), you could make it even easier on the rocket avionics by pre-computing a number of trajectories (say 21 of them, 30 seconds apart, covering +- 10 minutes from nominal), then pick one once you decide where in the window to launch. This reduces the problem to something that was solved by a 1960's flight computer.
-
#13
by
Jim
on 08 Jan, 2017 18:20
-
This mission had a 33 second launch window. So even if you can't update the solution for any time within a launch window, (even though Apollo and HEAO did this), you could make it even easier on the rocket avionics by pre-computing a number of trajectories (say 21 of them, 30 seconds apart, covering +- 10 minutes from nominal), then pick one once you decide where in the window to launch. This reduces the problem to something that was solved by a 1960's flight computer.
Not feasible unless does before terminal count. There needs to be time to load and verify the program.
-
#14
by
LouScheffer
on 08 Jan, 2017 19:52
-
This mission had a 33 second launch window. So even if you can't update the solution for any time within a launch window, (even though Apollo and HEAO did this), you could make it even easier on the rocket avionics by pre-computing a number of trajectories (say 21 of them, 30 seconds apart, covering +- 10 minutes from nominal), then pick one once you decide where in the window to launch. This reduces the problem to something that was solved by a 1960's flight computer.
Not feasible unless does before terminal count. There needs to be time to load and verify the program.
Given that computers in the 1960s could load and verify at least one trajectory, a modern computer can surely load and verify all 21 (in this case) in the hours before launch. Then it uses the one that corresponds to the selected launch time.
Given that yaw steering was developed and used, on manned mission, in the 1960s, and that the needed methods have been published, I believe the reasons for lacking it are bean counters, not technology. Unless you have a mission that needs it to reach some otherwise un-available orbit, or some customer demands it, then the decision boils down to how often a few minute window would help, how much a delay until the next window costs, versus the cost to develop and certify.
-
#15
by
Jim
on 08 Jan, 2017 20:59
-
Given that computers in the 1960s could load and verify at least one trajectory, a modern computer can surely load and verify all 21 (in this case) in the hours before launch.
nope, they just load the one
-
#16
by
Jim
on 08 Jan, 2017 21:00
-
I believe the reasons for lacking it are bean counters, not technology. Unless you have a mission that needs it to reach some otherwise un-available orbit, or some customer demands it, then the decision boils down to how often a few minute window would help, how much a delay until the next window costs, versus the cost to develop and certify.
Nope, it is avionics/software architecture. Delta could not if they wanted to
-
#17
by
hkultala
on 08 Jan, 2017 21:04
-
Given that computers in the 1960s could load and verify at least one trajectory, a modern computer can surely load and verify all 21 (in this case) in the hours before launch. Then it uses the one that corresponds to the selected launch time.
What makes you think any rocket (except Falcon 9) today is using a modern guidance computer?
-
#18
by
LouScheffer
on 08 Jan, 2017 22:35
-
Given that computers in the 1960s could load and verify at least one trajectory, a modern computer can surely load and verify all 21 (in this case) in the hours before launch. Then it uses the one that corresponds to the selected launch time.
What makes you think any rocket (except Falcon 9) today is using a modern guidance computer?
Well, "modern" depends on your reference. The Delta RIFCA uses triple MIL-STD-1750A processors. Compared to the computers in the 1960s Titan, or those in Apollo (both of which could do yaw steering), that's a modern processor, with enormous improvements in speed and capacity. But compared to what's in the Falcon, it's a slow and memory-limited antique.
-
#19
by
meberbs
on 08 Jan, 2017 23:36
-
The landing is fixed and known and never changes. There is no computing to determine or find it.
...
Again, wrong. The landing site is known and fixed. It stored on board.
...
The docking target locationis unknown until the first sensor lockon.
Yaw steering is not a look up table, it is computed onboard
Landing cannot be done from a purely pre-computed path, because it has to account for perturbing forces, some of which happen during "engines off" periods. And just like docking, additional sensors (e.g. altitude sensors) are needed to dynamically compute the final solution, because the exact relative location of the target is not known beforehand. (You seem to think that because the landing location is fixed relative to the surface of Earth it is somehow easier for the rocket to know its relative location to the landing site, but this is not true)
Yaw steering has to deal with the atmosphere on the way up, just as any other launch, so it can only be done from pre-computed tables as much as a direct launch would (I don't know to what extent they do). If regular launches can use tables, then so can yaw steering. Your argument that "nope, they just load the one" is meaningless because just because they don't, doesn't mean they couldn't. You would have to provide a reason they couldn't, such as if Delta doesn't have enough RAM. I doubt that would be the case for a Falcon.
Yaw steering doesn't have to use tables, it can be computed onboard as you said. Either way this still only* is a software functionality, you have yet to provide one bit of hardware that would need to change for a Delta or a Falcon.
*This is not to say that software is trivial. Not wanting to do extra software development/testing is plenty of reason to not implement yaw steering unless it is really needed.
-
#20
by
LouScheffer
on 09 Jan, 2017 01:44
-
Is Atlas the only vehicle that can do yaw steering?
Shuttle did it, too
And so did Apollo in 1975 (for the Apollo-Soyuz mission) and Titan in 1966 (for Gemini 12, which rendezvoused with the Atlas launched one orbit earlier, which is why they needed yaw steering.
-
#21
by
Jim
on 09 Jan, 2017 14:52
-
(You seem to think that because the landing location is fixed relative to the surface of Earth it is somehow easier for the rocket to know its relative location to the landing site, but this is not true)
Wrong, the Falcon has INS and GPS, it knows exactly where it is in relation to the landing site
-
#22
by
Jim
on 09 Jan, 2017 14:55
-
1 If regular launches can use tables, then so can yaw steering. Your argument that "nope, they just load the one" is meaningless because just because they don't, doesn't mean they couldn't. You would have to provide a reason they couldn't, such as if Delta doesn't have enough RAM. I doubt that would be the case for a Falcon.
2. Yaw steering doesn't have to use tables, it can be computed onboard as you said. Either way this still only* is a software functionality, you have yet to provide one bit of hardware that would need to change for a Delta or a Falcon.
1. They don't
2. The whole point of yaw steering is a continuous available launch window and not a group of instantaneous launch times.
-
#23
by
meberbs
on 09 Jan, 2017 15:22
-
(You seem to think that because the landing location is fixed relative to the surface of Earth it is somehow easier for the rocket to know its relative location to the landing site, but this is not true)
Wrong, the Falcon has INS and GPS, it knows exactly where it is in relation to the landing site
In that case, vehicles planning to dock with the ISS know exactly where they are relative to the ISS, because they would be preloaded with the orbital parameters of the target, and can have GPS and INS. Yaw steering same thing, the rocket would know the desired orbit, and current position relative to it. This works both ways. Your only explanation so far why that wouldn't be the case is dependence on time of launch, but I already explained why that isn't an issue (except for the obviously required SW changes).
1 If regular launches can use tables, then so can yaw steering. Your argument that "nope, they just load the one" is meaningless because just because they don't, doesn't mean they couldn't. You would have to provide a reason they couldn't, such as if Delta doesn't have enough RAM. I doubt that would be the case for a Falcon.
2. Yaw steering doesn't have to use tables, it can be computed onboard as you said. Either way this still only* is a software functionality, you have yet to provide one bit of hardware that would need to change for a Delta or a Falcon.
1. They don't
2. The whole point of yaw steering is a continuous available launch window and not a group of instantaneous launch times.
1. Ok.
2. The Atlas V Cygnus launches used a series of discrete launch opportunities over the 30 minute window.
-
#24
by
Jim
on 09 Jan, 2017 16:58
-
In that case, vehicles planning to dock with the ISS know exactly where they are relative to the ISS, because they would be preloaded with the orbital parameters of the target,
No, they used sensors for that.
-
#25
by
envy887
on 09 Jan, 2017 18:56
-
I believe the reasons for lacking it are bean counters, not technology. Unless you have a mission that needs it to reach some otherwise un-available orbit, or some customer demands it, then the decision boils down to how often a few minute window would help, how much a delay until the next window costs, versus the cost to develop and certify.
Nope, it is avionics/software architecture. Delta could not if they wanted to
Are you saying this is incorrect:?
...
For yaw (RAAN) steering, it's the robustness of the software and how it converges under highly dispersed conditions (see OA-6).
Atlas has had this capability going back to the Atlas II days. Delta IV will have it this year.
(emphasis mine)
-
#26
by
Jim
on 09 Jan, 2017 19:01
-
I believe the reasons for lacking it are bean counters, not technology. Unless you have a mission that needs it to reach some otherwise un-available orbit, or some customer demands it, then the decision boils down to how often a few minute window would help, how much a delay until the next window costs, versus the cost to develop and certify.
Nope, it is avionics/software architecture. Delta could not if they wanted to
Are you saying this is incorrect:?
...
For yaw (RAAN) steering, it's the robustness of the software and how it converges under highly dispersed conditions (see OA-6).
Atlas has had this capability going back to the Atlas II days. Delta IV will have it this year.
Delta IV is getting a new avionics suite as part of the ULA common avionics upgrade. The old RIFCA based system could not do it.
-
#27
by
meberbs
on 09 Jan, 2017 19:08
-
In that case, vehicles planning to dock with the ISS know exactly where they are relative to the ISS, because they would be preloaded with the orbital parameters of the target,
No, they used sensors for that.
And the Falcon 9 uses sensors (besides INS and GPS) to find the landing site, so by that logic then your statement was incorrect:
Wrong, the Falcon has INS and GPS, it knows exactly where it is in relation to the landing site
-
#28
by
Jim
on 09 Jan, 2017 19:11
-
And the Falcon 9 uses sensors (besides INS and GPS) to find the landing site, so by that logic then your statement was incorrect:
Wrong. It is only has a radar altimeter. It does not use it to find the landing site. It is only for the last final seconds.
And actually, F9 could likely land on land without the radar.
-
#29
by
meberbs
on 09 Jan, 2017 19:35
-
And the Falcon 9 uses sensors (besides INS and GPS) to find the landing site, so by that logic then your statement was incorrect:
Wrong. It is only has a radar altimeter. It does not use it to find the landing site. It is only for the last final seconds.
And actually, F9 could likely land on land without the radar.
Finding the landing site includes finding its location on the z axis. Are you trying to say that the altimeter is not a sensor? Otherwise what are you saying is wrong on my post? The "s" at the end of "sensors"? In that case how sure are you that there are no other landing sensors? (including anything based on the barge and transmitted to the stage) If there was a definitive statement on this, I missed it.
This is all drifting off topic from the original point that the F9 certainly is capable of yaw steering from a processor performance and available information (hardware) perspective, even though it would obviously need software changes to do so. If there is something wrong with this statement please clarify what hardware changes it would need.
-
#30
by
Robotbeat
on 09 Jan, 2017 19:37
-
A Falcon 9 might be able to do yaw-steering with the right software. But it doesn't have enough sensors to actually rendezvous and especially dock in orbit.
It has a radar that helps reduce z-height uncertainty (which can be compounded with a barge-landing since the sea surface isn't always flat). It'd be pretty useless for docking, though.
-
#31
by
LouScheffer
on 09 Jan, 2017 19:45
-
Are you saying this is incorrect:?
For yaw (RAAN) steering, it's the robustness of the software and how it converges under highly dispersed conditions (see OA-6).
Atlas has had this capability going back to the Atlas II days. Delta IV will have it this year.
Delta IV is getting a new avionics suite as part of the ULA common avionics upgrade. The old RIFCA based system could not do it.
If you look at this paper on RIFCA
A report on the flight of Delta II's redundant inertial flight control assembly (RIFCA) (unfortunately behind a paywall) there are many factors that could make adding new features (not just yaw steering) difficult. For safety, it runs programs out of EEPROM, which is slow to program. It has only 64K of program memory and 64K of RAM. Given what it's trying to do (lots of redundancy, sensor checking, etc.) this might very well be full. It talks to the GSE through a single RS-422 data link, which might be slow.
The problem with adding yaw steering is surely not processor speed. The RIFCA has triple BX-1750A microprocessors, which can run at 20 MHz. So it's quite a bit more powerful than the Shuttle computers (which were about 1.2 MIPS) and orders of magnitude more powerful than the Apollo computer. Both of these could do yaw steering.
My guess (and it's a guess) is that the memory is already fully used, so adding *any* new feature is extremely difficult.
I'd be extremely surprised if any of these limitations apply to the SpaceX avionics. In that case, I still believe in the "bean counter" argument - they have not yet done it since the cost exceeds the benefits. Here you need the opportunity costs as well - if the same groups could add yaw steering, or enhance the landing software, I'd suspect they'd be assigned to the latter.
-
#32
by
Jim
on 09 Jan, 2017 20:08
-
In that case how sure are you that there are no other landing sensors? (including anything based on the barge and transmitted to the stage)
Yes, and like I said, it can land on land without it.
-
#33
by
Jim
on 09 Jan, 2017 20:12
-
I'd be extremely surprised if any of these limitations apply to the SpaceX avionics. In that case, I still believe in the "bean counter" argument - they have not yet done it since the cost exceeds the benefits. Here you need the opportunity costs as well - if the same groups could add yaw steering, or enhance the landing software, I'd suspect they'd be assigned to the latter.
It is not just yaw steering. Like for DSCOVR, even with excess performance, there was only a one second launch window.
-
#34
by
LouScheffer
on 09 Jan, 2017 21:07
-
I'd be extremely surprised if any of these limitations apply to the SpaceX avionics. In that case, I still believe in the "bean counter" argument - they have not yet done it since the cost exceeds the benefits. Here you need the opportunity costs as well - if the same groups could add yaw steering, or enhance the landing software, I'd suspect they'd be assigned to the latter.
It is not just yaw steering. Like for DSCOVR, even with excess performance, there was only a one second launch window.
This makes perfect sense. Launches to the moon, or L points, are trying to hit a point that is (almost) fixed in inertial space. (At least, they re moving much slower than the Earth rotates). So the navigation solution depends on the time of launch, as illustrated in
For the booster, all you change is azimuth, to go through the right insertion point. Then the second burn depends on the initial azimuth chosen, and hence on the launch time as well.
So if SpaceX has not implemented real-time trajectory mods, then they could not use non-instantaneous windows for either rendezvous, moon, or L2 missions.
-
#35
by
Jim
on 09 Jan, 2017 23:40
-
For the booster, all you change is azimuth, to go through the right insertion point. Then the second burn depends on the initial azimuth chosen, and hence on the launch time as well.
No, the azimuth and first stage flight stay the same. The second stage burn accounts all the differences
-
#36
by
LouScheffer
on 10 Jan, 2017 00:40
-
For the booster, all you change is azimuth, to go through the right insertion point. Then the second burn depends on the initial azimuth chosen, and hence on the launch time as well.
No, the azimuth and first stage flight stay the same. The second stage burn accounts all the differences
That's not the normal method. Ranger changed the azimuth as a function of launch time - see the diagram I include. So did Apollo. See
Apollo lunar landing launch window: The controlling factors and constraintsFor the Apollo lunar missions, daily launch windows required a range of launch azimuths; the longer the daily launch window, the larger the required range of launch azimuths.
This is because the insertion burn takes place *directly* opposite the desired target, by the nature of orbits. This point moves with respect to the Earth's surface, so you need a different azimuth to get there depending on the time of launch. This applies to the moon, L points, or planetary injections, since they stay relatively fixed as the Earth rotates.
This is also covered on JPLs
JPL PUBLICATION 82-43: Interplanetary Mission Design Handbook, Volume I, Part 2:
As the launch site partakes in the sidereal rotation of the Earth, the continuously changing ascent plane manifests itself in a monotonic increase of the launch azimuth, EL , with lift-off time, tL , (or its angular counterpart, aL , measured in the equator plane) :
They go into lots of detail about this, including Figure 10 (launch geometry) and Figure 12 (launch time vs launch azimuth) and pages of discussion:
Since lift-off times are bounded by preselected launch-site dependent limiting values of launch azimuth EL (e .g ., 70 deg and 115 deg), each of the two declination contours thus contains a segment during which launch is permissible-"a launch window." The two segments on the plot do define the two available daily launch windows .
Of course, you *can* launch at a constant azimuth, and either do yaw steering on ascent (the Shuttle did this for Magellan) or do a plane change at insertion. This gets expensive fast, like all plane changes, and leads to lesser mission margins and shorter launch windows. You still have a navigation solution that depends on the time of launch, since the second stage burn always varies. And if the second stage computer supports this, and the second stage computer also directs the first stage (as it does in all cases I know of, except the Shuttle/IUS combination), then a time-variable azimuth makes sense.
-
#37
by
Jim
on 10 Jan, 2017 00:45
-
That's not the normal method. Ranger changed the azimuth as a function of launch time - see the diagram I include. So did Apollo.
No, stop using 40 year old data. That hasn't been the normal method for decades.
JPL book was made out dated by Challenger.
MRO, MSL, Juno, MAVEN, O-Rex, PNH, etc had windows of 30 minutes or more and flew the same first stage trajectory.
-
#38
by
Newton_V
on 10 Jan, 2017 01:31
-
MRO, MSL, Juno, MAVEN, O-Rex, PNH, etc had windows of 30 minutes or more and flew the same first stage trajectory.
LDCM was a pretty good example of trajectory variability through the window.
-
#39
by
LouScheffer
on 10 Jan, 2017 03:27
-
MRO, MSL, Juno, MAVEN, O-Rex, PNH, etc had windows of 30 minutes or more and flew the same first stage trajectory.
MSL had instantaneous windows, 5 minutes apart, all the way through the almost 2 hour launch window. Are you saying all of these had the same azimuth? If so, why? It's definitely giving up performance. What's the corresponding benefit?
-
#40
by
Newton_V
on 10 Jan, 2017 03:45
-
MRO, MSL, Juno, MAVEN, O-Rex, PNH, etc had windows of 30 minutes or more and flew the same first stage trajectory.
MSL had instantaneous windows, 5 minutes apart, all the way through the almost 2 hour launch window. Are you saying all of these had the same azimuth? If so, why? It's definitely giving up performance. What's the corresponding benefit?
A heck of a lot less range safety analyses/products, telemetry products, analyses, etc.
-
#41
by
Jim
on 10 Jan, 2017 14:23
-
MSL had instantaneous windows, 5 minutes apart, all the way through the almost 2 hour launch window. Are you saying all of these had the same azimuth? If so, why? It's definitely giving up performance. What's the corresponding benefit?
They were not instantaneous windows. It had one continuous window at the same azimuth. They just scheduled launch attempts every 5 minutes. This was for down range tracking and spacecraft acquisition.
The flight profile from liftoff to Centaur MECO-1 were the same for all times and days.
-
#42
by
LouScheffer
on 11 Jan, 2017 00:32
-
MSL had instantaneous windows, 5 minutes apart, all the way through the almost 2 hour launch window. Are you saying all of these had the same azimuth? If so, why? It's definitely giving up performance. What's the corresponding benefit?
They were not instantaneous windows. It had one continuous window at the same azimuth. They just scheduled launch attempts every 5 minutes. This was for down range tracking and spacecraft acquisition.
From
the MAVEN launch"For MAVEN, we've got a two-hour launch opportunity every day," said Jim Sponnick, ULA's vice president of Atlas and Delta programs. "And within those two hours, we have an opportunity to launch once every five minutes. It's those opportunities each day over the launch window make up those 1,000 trajectories. It's fairly consistent with how we have designed, developed and validated trajectories and mission designs for previous missions to Mars."
So you have one opportunity, each five minutes, each with its own trajectory. If you miss one, you wait for the next. That's the very definition of a sequence of instantaneous launch windows. Now if you want to claim it's due to tracking, and not the rocket, that's one thing. But for whatever reason, ULA implemented a sequence of instantaneous launch windows.
The flight profile from liftoff to Centaur MECO-1 were the same for all times and days.
So you are saying the first stage has a continuous window, so you can launch the first stage at any time you want, and it will work perfectly. I'd agree with that. Unfortunately, if you don't pick a time that is also compatible with the second stage working correctly, your mission will fail. Strangely enough, customers want launch windows where everything will work - first stage, second stage, tracking, sunlight, etc. So the mission launch window is the AND of all these constraints. In this case, it's a sequence of instantaneous windows.
-
#43
by
Jim
on 11 Jan, 2017 00:41
-
So you are saying the first stage has a continuous window, so you can launch the first stage at any time you want, and it will work perfectly. I'd agree with that. Unfortunately, if you don't pick a time that is also compatible with the second stage working correctly,
And the second stage has continuous window. It would work perfectly for anytime within the window. There is only one software load for the whole window
-
#44
by
LouScheffer
on 11 Jan, 2017 01:40
-
So you are saying the first stage has a continuous window, so you can launch the first stage at any time you want, and it will work perfectly. I'd agree with that. Unfortunately, if you don't pick a time that is also compatible with the second stage working correctly,
And the second stage has continuous window. It would work perfectly for anytime within the window. There is only one software load for the whole window
So a single software load can include a bunch of trajectories, and the avionics, or the ground, picks one based on the launch time (from previous article):
Based on the rotation of Earth and the alignment of planets, the trajectory to Mars changes throughout the launch window. So engineers pre-developed 1,000 trajectory programs to load into the Atlas 5's guidance computer in case the launch delays into the window.
So if each trajectory has its own launch window, and you can load enough individual trajectories to tile the entire daily launch window, then you could in theory launch at any time. The constraint on the avionics is the ability to load, hold, and pick from enough trajectories. This seems pretty straightforward for any modern avionics, but could well explain why Delta has not pursued this strategy.
Continuous coverage seems like more work than required, since you only really need trajectories that work at the times permitted by other constraints. On the other hand, presumably each of the trajectories is generated by the usual process, which will give a window as one of its outputs (or take it as a constraint). If those windows are big enough (>= 5 minutes in this case) then it's no extra work to get continuous converage.
With 1000 different trajectories, I can see why ULA would hold as much as possible of the flight the same. That way they don't need 1000 different predicts to send to the tracking stations. The disadvantage would be that performance drops off more quickly from the center of the window, so this is probably why the Atlas launch windows are not as long as the more than 2.5 hour Apollo launch windows. Such long windows would require changing the launch azimuth to avoid excessive losses. But the shorter windows seem plenty good enough - i can't recall any planetary mission lately that was in danger of missing the launch window, but might have made it if the daily windows were longer.
-
#45
by
Jim
on 11 Jan, 2017 01:58
-
The disadvantage would be that performance drops off more quickly from the center of the window, so this is probably why the Atlas launch windows are not as long as the more than 2.5 hour Apollo launch windows.
Lunar trajectories are not to be compared to other planetary windows.
-
#46
by
LouScheffer
on 14 Jan, 2017 12:39
-
The disadvantage would be that performance drops off more quickly from the center of the window, so this is probably why the Atlas launch windows are not as long as the more than 2.5 hour Apollo launch windows.
Lunar trajectories are not to be compared to other planetary windows.
Lunar and planetary windows should be pretty similar. In both cases, the orbital mechanics dictate an orbit with the perigee near Earth and an extremely high apogee. So the optimal injection spot is almost directly opposite the desired departure direction. In a two hour window, this spot moves by about 30 degrees in longitude.
A planet is pretty much fixed in place on this time scale, but the moon is moving. Assuming it goes around in 28 days, it will move about 1 degree in a two hour window. So instead of 30 degrees, the optimal spot moves only 29. So a moon window will be about 3% longer for the same amount of allowed mis-alignment.
-
#47
by
leetdan
on 31 Aug, 2020 16:30
-
Bumping this old thread, because I believe we've just seen Falcon 9 fully demonstrate yaw steering capability. The SAOCOM 1B launch involved dog leg maneuvers in both first and second stages, followed by an RLTS landing. Does this mean that, given sufficient prop margins, that some instantaneous launch windows could be expanded?
-
#48
by
intelati
on 31 Aug, 2020 19:55
-
Bumping this old thread, because I believe we've just seen Falcon 9 fully demonstrate yaw steering capability. The SAOCOM 1B launch involved dog leg maneuvers in both first and second stages, followed by an RLTS landing. Does this mean that, given sufficient prop margins, that some instantaneous launch windows could be expanded?
Given margin, yes. But I know SAOCOM was a light payload. Anyone have full numbers for the payload? And the losses incurred compared to other RTLS launches?
-
#49
by
edzieba
on 31 Aug, 2020 22:05
-
Does this mean that, given sufficient prop margins, that some instantaneous launch windows could be expanded?
For Falcon 9, recycle time would be limited by propellant temperature due to the use of subcooling. Unless the window is sufficiently long to allow tanks to be drained and refilled, or clearing the hold condition so rapid that it can be done before the propellants warm, a short window gained through RAAN/yaw steering is of not practical use 'just' for expanding the launch window.
-
#50
by
the_other_Doug
on 01 Sep, 2020 15:04
-
During SAOCOM 1B launch coverage, the SpaceX commentator put it very understandably. He stated that while this launch had a 10-minute launch window, once prop loading began, the launch window became instantaneous at the designated T-0 time, since the props would warm too much even during a short hold to delay beyond the exact launch time.
So, launch of a Falcon 9 has to happen at an exact interval after prop loading begins. Once you start loading the tanks, you've committed to either launching exactly on time, or not launching at all. Such is the world of subcooled propellants...
-
#51
by
Jim
on 24 May, 2022 22:21
-
They can cycle the propellants for a second attempt in their four hour launch windows for GTO launches, but obviously that is limited to payloads that don't care too much about time of day.
I don't think they can recycle Falcon Heavy, only delay prop loading if they have a window. I was there for Arabsat-6A and on the second attempt, I'm pretty sure they said it would be a scrub if there was any problems after commit to prop load, although that was only a ~2hr window. I'm not sure why Jim is dancing around this, unless Psyche itself has an instantaneous launch window...?
I already stated it does. Like for ISS missions, Falcon can only do instantaneous windows for planetary missions. It is a function of its avionics. It can’t do RAAN steering.
-
#52
by
DanClemmensen
on 25 May, 2022 15:40
-
They can cycle the propellants for a second attempt in their four hour launch windows for GTO launches, but obviously that is limited to payloads that don't care too much about time of day.
I don't think they can recycle Falcon Heavy, only delay prop loading if they have a window. I was there for Arabsat-6A and on the second attempt, I'm pretty sure they said it would be a scrub if there was any problems after commit to prop load, although that was only a ~2hr window. I'm not sure why Jim is dancing around this, unless Psyche itself has an instantaneous launch window...?
I already stated it does. Like for ISS missions, Falcon can only do instantaneous windows for planetary missions. It is a function of its avionics. It can’t do RAAN steering.
How does RAAN steering differ from the maneuvers needed to do a dogleg as Falcon 9 has done on occasion? Is it because the dogleg is planned in advance for a particular launch time, while RAAN steering varies in real time as the launch time slips?
-
#53
by
Jim
on 25 May, 2022 17:01
-
They can cycle the propellants for a second attempt in their four hour launch windows for GTO launches, but obviously that is limited to payloads that don't care too much about time of day.
I don't think they can recycle Falcon Heavy, only delay prop loading if they have a window. I was there for Arabsat-6A and on the second attempt, I'm pretty sure they said it would be a scrub if there was any problems after commit to prop load, although that was only a ~2hr window. I'm not sure why Jim is dancing around this, unless Psyche itself has an instantaneous launch window...?
I already stated it does. Like for ISS missions, Falcon can only do instantaneous windows for planetary missions. It is a function of its avionics. It can’t do RAAN steering.
How does RAAN steering differ from the maneuvers needed to do a dogleg as Falcon 9 has done on occasion? Is it because the dogleg is planned in advance for a particular launch time, while RAAN steering varies in real time as the launch time slips?
yes
-
#54
by
DanClemmensen
on 25 May, 2022 17:20
-
They can cycle the propellants for a second attempt in their four hour launch windows for GTO launches, but obviously that is limited to payloads that don't care too much about time of day.
I don't think they can recycle Falcon Heavy, only delay prop loading if they have a window. I was there for Arabsat-6A and on the second attempt, I'm pretty sure they said it would be a scrub if there was any problems after commit to prop load, although that was only a ~2hr window. I'm not sure why Jim is dancing around this, unless Psyche itself has an instantaneous launch window...?
I already stated it does. Like for ISS missions, Falcon can only do instantaneous windows for planetary missions. It is a function of its avionics. It can’t do RAAN steering.
How does RAAN steering differ from the maneuvers needed to do a dogleg as Falcon 9 has done on occasion? Is it because the dogleg is planned in advance for a particular launch time, while RAAN steering varies in real time as the launch time slips?
yes
In that case, we would expect it's just a SMoP. SMoP fills real programmers with dread. A manager says it's a "Small Matter of Programming". The guys who are expected to implement it know they are now in trouble.
-
#55
by
Robotbeat
on 25 May, 2022 17:24
-
They can cycle the propellants for a second attempt in their four hour launch windows for GTO launches, but obviously that is limited to payloads that don't care too much about time of day.
I don't think they can recycle Falcon Heavy, only delay prop loading if they have a window. I was there for Arabsat-6A and on the second attempt, I'm pretty sure they said it would be a scrub if there was any problems after commit to prop load, although that was only a ~2hr window. I'm not sure why Jim is dancing around this, unless Psyche itself has an instantaneous launch window...?
I already stated it does. Like for ISS missions, Falcon can only do instantaneous windows for planetary missions. It is a function of its avionics. It can’t do RAAN steering.
How does RAAN steering differ from the maneuvers needed to do a dogleg as Falcon 9 has done on occasion? Is it because the dogleg is planned in advance for a particular launch time, while RAAN steering varies in real time as the launch time slips?
yes
In that case, we would expect it's just a SMoP. SMoP fills real programmers with dread. A manager says it's a "Small Matter of Programming". The guys who are expected to implement it know they are now in trouble.
Right. You could just pre-compute thousands of trajectories in one second intervals for the whole window. If it’s worth having the capability, SpaceX could easily do it.
-
#56
by
DanClemmensen
on 25 May, 2022 17:28
-
They can cycle the propellants for a second attempt in their four hour launch windows for GTO launches, but obviously that is limited to payloads that don't care too much about time of day.
I don't think they can recycle Falcon Heavy, only delay prop loading if they have a window. I was there for Arabsat-6A and on the second attempt, I'm pretty sure they said it would be a scrub if there was any problems after commit to prop load, although that was only a ~2hr window. I'm not sure why Jim is dancing around this, unless Psyche itself has an instantaneous launch window...?
I already stated it does. Like for ISS missions, Falcon can only do instantaneous windows for planetary missions. It is a function of its avionics. It can’t do RAAN steering.
How does RAAN steering differ from the maneuvers needed to do a dogleg as Falcon 9 has done on occasion? Is it because the dogleg is planned in advance for a particular launch time, while RAAN steering varies in real time as the launch time slips?
yes
In that case, we would expect it's just a SMoP. SMoP fills real programmers with dread. A manager says it's a "Small Matter of Programming". The guys who are expected to implement it know they are now in trouble.
Right. You could just pre-compute thousands of trajectories in one second intervals for the whole window. If it’s worth having the capability, SpaceX could easily do it.
Your statement is an excellent example of SMoP.
-
#57
by
Robotbeat
on 25 May, 2022 17:31
-
Absolutely. The programmers would hate whoever made them do it. “Just solve it in software” LOL. They hate that.
-
#58
by
Jim
on 25 May, 2022 17:32
-
Right. You could just pre-compute thousands of trajectories in one second intervals for the whole window. If it’s worth having the capability, SpaceX could easily do it.
Wrong on both points. 7200 trajectories for a two hour window is too much to manage.
-
#59
by
Robotbeat
on 25 May, 2022 17:35
-
Explain why.
-
#60
by
Barley
on 25 May, 2022 18:08
-
Absolutely. The programmers would hate whoever made them do it. “Just solve it in software” LOL. They hate that.
As a programmer I can say we don't hate solving problems in software. Solving problems in software is our thing. What we hate is being told to solve problems in software at the last minute, without any resources and without a description of what the problem is. Or problems like melting tires -- very hard to solve in software; we did manage to cut it in half, but it really needed a chemist (or a new buyer).
-
#61
by
Jim
on 25 May, 2022 19:33
-
Explain why.
7200 sets of files to manage. 7200 Monte Carlo runs on the trajectories. 7200 runs on the SIL. 7200 trajectories to verify.
-
#62
by
Herb Schaltegger
on 26 May, 2022 00:08
-
Explain why.
7200 sets of files to manage. 7200 Monte Carlo runs on the trajectories. 7200 runs on the SIL. 7200 trajectories to verify.
So Jim, let me ask you: do you know or have an opinion why SpaceX hasn't upgraded F9 avionics to support RAAN steering on ascent? Is it because they don't generally need it? Or because the use of sub-cooled LOX and the desire to hit a target bulk mean temp for oxidizer loads preclude the flexibility RAAN steering might gain them in longer launch windows? Or something else?
-
#63
by
ccdengr
on 26 May, 2022 00:46
-
do you know or have an opinion why SpaceX hasn't upgraded F9 avionics to support RAAN steering on ascent?
I'm not Jim and this topic has drifted rather far from the Psyche specifics (which is fine, since it is a SpaceX thread) but I'd say it's because they haven't needed it and better is the enemy of good enough. Delta II had only instantaneous windows and worked fine for planetary missions (there we could get two windows per day, usually, by reloading parameters.)
-
#64
by
Robotbeat
on 26 May, 2022 01:49
-
Explain why.
7200 sets of files to manage. 7200 Monte Carlo runs on the trajectories. 7200 runs on the SIL. 7200 trajectories to verify.
This... doesn't sound beyond SpaceX's capabilities? We've been running monte carlo runs, trajectories, etc, for decades. Since the 80s, computer power (as well as memory capability) has increased more than 1,000,000 fold (for a given cost). SpaceX runs these calculations in an automated manner already (according to people who ought to know), they would not have to babysit each one.
Again, the programmers would hate it; it'd need to be validated, etc. And frankly, this is probably not the best way to do it (ULA doesn't do it this way). But this is most certainly not beyond SpaceX's capabilities.
(Appreciate the response, BTW.)
-
#65
by
ccdengr
on 26 May, 2022 01:59
-
7200 sets of files to manage. 7200 Monte Carlo runs on the trajectories. 7200 runs on the SIL. 7200 trajectories to verify.
This... doesn't sound beyond SpaceX's capabilities?
In my experience, reloading parameters would be a tedious and error-prone way to do this if you had more than a few sets. Rockets that have this capability simply perform the needed calculations on board. If SpaceX wanted to do that, I'm certain they could, but avoiding unneeded frills is just good systems engineering. Add more features, add more testing, add more error modes, etc. KISS.
-
#66
by
Jim
on 26 May, 2022 16:07
-
L
SpaceX runs these calculations in an automated manner already (according to people who ought to know), they would not have to babysit each one.
verification is not automated. People still review the data.
Launch vehicles don't carry that much memory.
also, an issue is managing the differences in the all the trajectories.
Other vehicles that have the capability to do RAAN steering, do trajectory checks at every minute and launch only on the minute but they only have one software load.
-
#67
by
abaddon
on 26 May, 2022 16:20
-
do you know or have an opinion why SpaceX hasn't upgraded F9 avionics to support RAAN steering on ascent?
I'm not Jim and this topic has drifted rather far from the Psyche specifics (which is fine, since it is a SpaceX thread) but I'd say it's because they haven't needed it and better is the enemy of good enough. Delta II had only instantaneous windows and worked fine for planetary missions (there we could get two windows per day, usually, by reloading parameters.)
This begs the question; why did Lockheed (or ULA) implement it in Atlas V? And when? (And or Boeing/ULA for Delta IV, I know there were some changes made to adopt unified avionics at some point, so perhaps it came from the Delta side).
-
#68
by
ccdengr
on 26 May, 2022 16:37
-
This begs the question; why did Lockheed (or ULA) implement it in Atlas V? And when?
I don't know, but this topic was covered rather extensively in
https://forum.nasaspaceflight.com/index.php?topic=41982.0 and this is just a rehash of many of those points. Atlas II, Shuttle, and Apollo could do yaw steering.
-
#69
by
abaddon
on 26 May, 2022 17:28
-
-
#70
by
Newton_V
on 26 May, 2022 23:18
-
Example of RAAN steering (coincidentally with a yaw maneuver that has nothing to do with RAAN target):
No RAAN steering case:
Just look at the red ground track only. Because of a flight azimuth constraint, and a lower target inclination than the azimuth allows, the vehicle yaws left (when allowed) to get to the inclination. The ground track will look identical for launch any time of day. You just wait for the correct time of day to get the desired RAAN of your orbit. Orbit will always be 200 km circ at 65 deg for example. If customer has a tolerance requirement of 0.1 deg, the launch window will be essentially instantaneous. If the requirement was +/- 7.5 deg, then you have about an hour window. No RAAN steering needed.
With RAAN steering:
If a customer still has the 0.1 accuracy requirement, the launch vehicle (LV) can utilize RAAN steering to increase the window (to get more launch opportunities that day, due to weather, anomaly resolution, etc), or sometimes a customer might have the longer window requirement (for the same reasons), and still want/require the 0.1 deg tolerance. In this case, you still determine the window optimal launch time that gets the RAAN you want (the red track), but now the vehicle is targeting this inertial plane. If you launch earlier (Earth hasn’t quite rotated around enough), the ground track will look like the purple plot. If you launch later, the olive track. The vehicle still goes to the same 200 km @ 65 deg orbit, the difference being WHERE you inject in the orbit (lat, long, time from liftoff, etc). The flight software only works for this period of validity that the flight software parameters were designed to. You can launch any time from window open to close. Any second, fraction of a second. Whatever. When you see launches only every minute, or 5 minutes, those are operational decisions, and have nothing to do with the LV capabilities. It just makes life easier for the customer and their ops for post-SV separation.
Atlas has had this capability going back to the Atlas II days. Titan IV had it as well. Delta IV did when common avionics came along.
One other note: You can do “psedo” RAAN steering, by just having discrete, optimized cases, at specific intervals, every 5, 10, or 30 minutes, etc, but then this requires uploading at new flight software parameter set throughout the launch window. Delta has done this. I believe Falcon might or might not have.
-
#71
by
matthewkantar
on 26 May, 2022 23:32
-
Would RAAN steering ever put the drone ship out of landing range?
-
#72
by
Joffan
on 27 May, 2022 15:54
-
Would RAAN steering ever put the drone ship out of landing range?
That seems possible, but unlikely.
As I understand it, RAAN steering is trying to hit a plane in sidereal coordinates, so Earth coordinates are essentially ignored (hence "possible"). However most of the steering to selected orbit for Falcon 9 is done by the second stage (when it is not an orbit achievable from direct launch azimuth). That of course means the booster would already be headed back to its chosen landing site by the time significant launch-time-dependent steering started. See
OneSpeed's assessment of Falcon second stage steering from launch data.
-
#73
by
Newton_V
on 27 May, 2022 15:55
-
Would RAAN steering ever put the drone ship out of landing range?
Begin the RAAN steering in upperstage flight. Costs more performance, but solves one issue.
-
#74
by
Jim
on 27 May, 2022 21:06
-
And even further back, Gemini XII used lots of yaw steering, since they were rendezvousing with a target launched 90 minutes earlier. From the Gemini 12 mission report
Radio guidance and not inertial
-
#75
by
Jim
on 27 May, 2022 21:10
-
Bumping this old thread, because I believe we've just seen Falcon 9 fully demonstrate yaw steering capability. The SAOCOM 1B launch involved dog leg maneuvers in both first and second stages, followed by an RLTS landing. Does this mean that, given sufficient prop margins, that some instantaneous launch windows could be expanded?
doglegs are not the same as yaw steering.
-
#76
by
Jim
on 27 May, 2022 21:12
-
-
#77
by
Jim
on 27 May, 2022 21:18
-
MSL had instantaneous windows, 5 minutes apart, all the way through the almost 2 hour launch window. Are you saying all of these had the same azimuth? If so, why? It's definitely giving up performance. What's the corresponding benefit?
They were not instantaneous windows. It had one continuous window at the same azimuth. They just scheduled launch attempts every 5 minutes. This was for down range tracking and spacecraft acquisition.
From the MAVEN launch
"For MAVEN, we've got a two-hour launch opportunity every day," said Jim Sponnick, ULA's vice president of Atlas and Delta programs. "And within those two hours, we have an opportunity to launch once every five minutes. It's those opportunities each day over the launch window make up those 1,000 trajectories. It's fairly consistent with how we have designed, developed and validated trajectories and mission designs for previous missions to Mars."
So you have one opportunity, each five minutes, each with its own trajectory. If you miss one, you wait for the next. That's the very definition of a sequence of instantaneous launch windows. Now if you want to claim it's due to tracking, and not the rocket, that's one thing. But for whatever reason, ULA implemented a sequence of instantaneous launch windows.
The flight profile from liftoff to Centaur MECO-1 were the same for all times and days.
So you are saying the first stage has a continuous window, so you can launch the first stage at any time you want, and it will work perfectly. I'd agree with that. Unfortunately, if you don't pick a time that is also compatible with the second stage working correctly, your mission will fail. Strangely enough, customers want launch windows where everything will work - first stage, second stage, tracking, sunlight, etc. So the mission launch window is the AND of all these constraints. In this case, it's a sequence of instantaneous windows.
Wrong, it is a continuous launch window that they choose only to launch on certain times for tracking and spacecraft acquisition. The launch vehicle still can launch at any second and there is no change to the software load. The only thing is done is just picking the launch time and starting the timing so it arrives on the planned interval. The space craft has done its analysis for those specific times and can setup tracking antennas for the expected trajectory.
