It's been a while since I published on precision landing, but here's a new article:tinyurl.com/h6kp5n7 Big thanks to @NAE_DC + @SpaceX.
Real-time terrain relative navigation test results from a relevant environment for Mars landingJohnson, Andrew E.; Cheng, Yang; Montgomery, James; Trawny, Nikolas; Tweddle, Brent; Zheng, JasonURI: http://hdl.handle.net/2014/45631Date: 2015-01-05Keywords: EDL; Lander Vision System; GNC; Pin-point Landing; Mars 2020Publisher: Pasadena, CA : Jet Propulsion Laboratory, National Aeronautics and Space Administration, 2015Citation: AIAA Scitech 2015, Kissimee, Florida, January 5-9, 2015Abstract:Terrain Relative Navigation (TRN) is an on-board GN&C function that generates a position estimate of a spacecraft relative to a map of a planetary surface. When coupled with a divert, the position estimate enables access to more challenging landing sites through pin-point landing or large hazard avoidance. The Lander Vision System (LVS) is a smart sensor system that performs terrain relative navigation by matching descent camera imagery to a map of the landing site and then fusing this with inertial measurements to obtain high rate map relative position, velocity and attitude estimates. A prototype of the LVS was recently tested in a helicopter field test over Mars analog terrain at altitudes representative of Mars Entry Descent and Landing conditions. TRN ran in real-time on the LVS during the flights without human intervention or tuning. The system was able to compute estimates accurate to 40m (3 sigma) in 10 seconds on a flight like processing system. This paper describes the Mars operational test space definition, how the field test was designed to cover that operational envelope, the resulting TRN performance across the envelope and an assessment of test space coverage.
Great paper by Lars Blackmore (principal rocket landing engineer at SpaceX) on the challenges of precision landing:
Nice of him to be gracious enough to give credit to how others have been advancing on the same problem... particularly Blue Origin. I don't blame him for not giving away too many particulars as to how SpaceX does it.
Landing on a barge is much harder though. You have one shot and no change of abort and redo.
Hey, unlike certain people around here, I don't consider rendezvous and landing as problems of similar magnitude. Not even close. If it were close, the problem would probably have been mastered long ago.
Wrong. It wasn't controls or guidance that prevented it from long ago. It was the incorporation of Supersonic retropropulsion and engine throttling, and the use of many smaller engines that allow them to be used for landing an empty stage. Autonomous rendezvous with a non cooperative target is harder.
(Ah - moved to a better thread, thanks Chris.)This was in response to a discussion started on one of the mission threads, comparing landing an F9 with orbital docking of say, visiting vehicles to the ISS.-----The problem is not programming. It's the inherent control problem that's so crazy difficult.In a docking situation, there are more control inputs than there are degrees of freedom. Just count the number of RCS thrusters on any visiting vehicle.So if you want to, for example, translate in Y, you fire off a matching pair of thrusters, drift a little bit, then stop.So if you consider paired thrusters, you can also say that the degrees of freedom are decoupled.The docking procedure dictates that the vehicles be aligned from an angular point of view, then made collinear, by translation, then just control the main axis coast until captured.All of this makes the control problem trivial - plus, there are hardly any disturbing forces.OTOH, on a landing:- You're trying to zero 12 degrees of freedom (6 position/rotation of rigid body in space, plus all first derivatives)- You have only 2 strong inputs (tip/tilt of engine plume), a sluggish throttle control, and 3 (x,y,theta) controls from the grid fins, which are losing effectiveness rapidly as you're slowing down.- The 2 strong inputs don't go through the C.M, so everything is coupled. If you want to translate, you need to induce a rotation. Then you need to stop the rotation, reverse it, stop the translation, and undo the rotation again.- The landing procedure includes intentional maneuvering (divert) in multiple axes- Meanwhile, the wind is very significant, variable, and unknown except for its effects.So good luck "just doing a little bit of programming" on a docking vehicle's avionics and teaching it how to land an F9 on a barge.
Quote from: Jim on 01/08/2017 02:08 pmWrong. It wasn't controls or guidance that prevented it from long ago. It was the incorporation of Supersonic retropropulsion and engine throttling, and the use of many smaller engines that allow them to be used for landing an empty stage. Autonomous rendezvous with a non cooperative target is harder.What about nobody wanted it? As in, why bother landing the empty stage and reusing it when to do so negatively affects the payload capacity and we don't have the budget or time to develop a reuseable system anyway? That was certainly the case for Apollo. Pre-Apollo we were trying just to get into space at all. Post-Apollo there was the Shuttle reuse experiment. Now there's SpaceX.I've gotta agree with Jim that it wasn't a guidance or controls problem, but from what I can see it wasn't a technical problem at all. It was a question of settling on reuseability as a goal. In spaceflight, once a goal is set and the funding is adequate, stuff gets done. It's just rocket science.
Quote from: meekGee on 01/07/2017 06:30 pm...a sluggish throttle control...You forgot to mention the most important problem - delay. Nonlinear, unstable systems are relatively easily controllable when there is no delay. Introduce the delay in your control loop and things go south.
...a sluggish throttle control...
Quote from: laszlo on 01/08/2017 03:09 pmI've gotta agree with Jim that it wasn't a guidance or controls problem, but from what I can see it wasn't a technical problem at all. It was a question of settling on reuseability as a goal. In spaceflight, once a goal is set and the funding is adequate, stuff gets done. It's just rocket science.Bingo
I've gotta agree with Jim that it wasn't a guidance or controls problem, but from what I can see it wasn't a technical problem at all. It was a question of settling on reuseability as a goal. In spaceflight, once a goal is set and the funding is adequate, stuff gets done. It's just rocket science.
True, but we had to develop the onboard compute horsepower to support autonomous hoverslam landings. That certainly didn't exist during Apollo nor during Shuttle development.
Quote from: dglow on 01/10/2017 05:22 pmTrue, but we had to develop the onboard compute horsepower to support autonomous hoverslam landings. That certainly didn't exist during Apollo nor during Shuttle development.That wasn't a constraint. Shuttle avionics could have done it.
No.
Quote from: dglow on 01/10/2017 05:49 pmNo.Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.
Quote from: Jim on 01/10/2017 05:54 pmQuote from: dglow on 01/10/2017 05:49 pmNo.Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.How do you know that?
Having to go from orbit at a specific landing site with no propulsion by using energy management. Going from Mach 25 to zero through the subsonic, transonic, supersonic, hypersonic and high-hypersonic flight regimes with a winged vehicle having variable stability utilizing blended reaction and aerodynamic control. And this was before GPS (there was TACAN and MSBLS)
Since no stage prior to the F9 stage 1 had ever been designed to do so. In that sense the total problem of stage return is the tougher one.
The first modern-era missile defense hit-to-kill intercept (that is, autonomous rendezvous with a non-cooperating target) was the IFT-3 flight test of the Ground Based Interceptor with the Raytheon Exoatmospheric Kill Vehicle which took place in 1999, and having seen an EKV up close I can tell you that there's not much room for compute horsepower, particularly with late-90's embedded systems.
Quote from: dglow on 01/10/2017 05:22 pmTrue, but we had to develop the onboard compute horsepower to support autonomous hoverslam landings. That certainly didn't exist during Apollo nor during Shuttle development.The first modern-era missile defense hit-to-kill intercept (that is, autonomous rendezvous with a non-cooperating target) was the IFT-3 flight test of the Ground Based Interceptor with the Raytheon Exoatmospheric Kill Vehicle which took place in 1999, and having seen an EKV up close I can tell you that there's not much room for compute horsepower, particularly with late-90's embedded systems. And that aside, the very first hit-to-kill intercept was the Nike Zeus in 1961. Most of the analog electrical engineering experts are retired by now, but it's enjoyable to listen to their stories.
Intuitively obvious. Having to go from orbit at a specific landing site with no propulsion by using energy management. Going from Mach 25 to zero through the subsonic, transonic, supersonic, hypersonic and high-hypersonic flight regimes with a winged vehicle having variable stability utilizing blended reaction and aerodynamic control. And this was before GPS (there was TACAN and MSBLS)
The interesting part of this thread is what landing techniques lend themselves to precision. For landings on earth, GPS is the obvious choice with no immediate rivals. What about Mars, the Moon, or Titan? Do you first orbit a constellation of GPS satellites? Do you land a MLS type system onto the surface? Or do you need a combination of the two to get good precision?
STS did not go from orbit to landing site with no propulsion. The OMS engines delivered the impulse to direct STS to it entry interface corridor. This is analogous to F9's boostback burn.
Quote from: Stan-1967 on 01/11/2017 03:52 amSTS did not go from orbit to landing site with no propulsion. The OMS engines delivered the impulse to direct STS to it entry interface corridor. This is analogous to F9's boostback burn. Wrong. The OMS just changed the orbit to one that intersected the atmosphere, so it is not analogous to the boost back burn.
Quote from: FutureSpaceTourist on 01/01/2017 06:40 amGreat paper by Lars Blackmore (principal rocket landing engineer at SpaceX) on the challenges of precision landing:A nice round up of the problem (it's hard), and how results have been improving over the last 4 decades. Not much on how SX gets from 10Km on Mars to 10m on Earth though. [EDIT Beyond basically we run CVXGen to produce a chunk of custom software that solves the problem on the lander. It's not clear if they create a new version for each launch DOLILU style or if they ran the system for a while to get a really well optimized program this class of problem ]
Give it a rest, that diagram is getting over used. And, landing an F9 IS easier than autonomous docking a spacecraft. There is no question.
Quote from: Jim on 01/11/2017 01:27 pmQuote from: Stan-1967 on 01/11/2017 03:52 amSTS did not go from orbit to landing site with no propulsion. The OMS engines delivered the impulse to direct STS to it entry interface corridor. This is analogous to F9's boostback burn. Wrong. The OMS just changed the orbit to one that intersected the atmosphere, so it is not analogous to the boost back burn.Sounds like Woody telling Buzz Lightyear he's not flying, but just falling with style.But what do you really think about the tools that could enable precision landing? You correctly pointed out the enabling technologies that STS used, will any of those have application to Mars EDL or other likely destinations?
I'm a software engineer, just looking at the problem from where I am, docking is an easier SW problem than landing the F9 booster. Call it intuition, since you seem to accept that as valid.
Jim, I take your statement as a working assumption: "software is easy".If software is easy, how is orbital mechanics hard? Newtons laws are fantastically simple. You dont need fancy long term trajectory prediction (over centuries, which are complicated) for a rendezvous. So if software is easy and your computer knows the orbit of your target, the software can predict its position far enough into the future for a rendezvous and subsequent docking. The rendezvous procedure is also fantastically simple. Here is the pseudocode:1. Approach from a lower orbit2. Align orbital planes3. Raise your orbit slowly timed such that you approach your target from behind4. Initiate dockingFor the docking, the target docking port needs to provide a signal of some kind that you can target. Keeping stationary requires frequent adjustments using thrusters, but thats all software which is, as you say easy. So here is the pseudo code for docking:1. Align your spacecraft and the docking port in a defined state2. Approach the docking port within a defined trajectory envelope3. if envelope is violated, abort docking and go back to step 1.4. otherwise approach until dockedThis is also not very hard. trajectory prediction requires orbital mechanics. But thats software which is easy. So.. how is docking hard?From your proposition that software is easy and no other statement about the difficulty of the task, we arrive at the conclusion that docking is easy. Which contradicts your statement that docking is hard. So one has to go or you need to provide more information what exactly is hard here.Also, I want to reiterate my last request: Please state your metric that you use to measure difficulty. Its really the hinging point of this conversation. Unless we agree on the metric, we will never agree on the difficulty statement.
The idea that software is easy... Is wrong.
Also, I want to reiterate my last request: Please state your metric that you use to measure difficulty. Its really the hinging point of this conversation. Unless we agree on the metric, we will never agree on the difficulty statement.
computer knows the orbit of your target3. Raise your orbit slowly timed such that you approach your target from behindFor the docking, the target docking port needs to provide a signal of some kind that you can target.
I must have missed the uncooperative part in the past. Why do you assume an uncooperative target? Thats not done unless you try to attack something. Why is that even part of the conversation?
I must have missed the uncooperative part in the past.
So Jim, you take a particular hard case that is very special which requires a dedicated mission of docking with an uncooperative target and compare it with a routine operation of landing the first stage? Why would you do that? A comparison with a routine docking operation i.e. the ISS would make much more sense.
Doesnt the ASDS or the landing pad qualify as an "uncooperative" target? It's stationary ok but it's not exchanging any data with the vehicle just like the ISS.For me the F9 landing is more than just the sw to get it there. Theres a lot of systems work gone into the vehicle to make this happen from attitude control, restartable engines, shielding and so on. All been done before in different ways but never the way to F9 does it.As an ex realtime process control sw head I think the F9 sw work is top notch. It's a difficult problem to solve and yes they have tuned it time and time again with their landings and perfected it , but still a difficult problem to solve.
It is part of the conversion because it is hard. "Uncooperative" means it doesn't have any interaction with the chaser spacecraft.
That is what autonomous robotic servicing spacecraft will have to do. They will have approach a spacecraft that is not designed for routine rendezvous and docking. It will have to use onboard sensors to find the target spacecraft and then will have to find an area such as the launch adapter as a mating point.
And the visiting vehicles have so many more control inputs...Those sort of differences are not "software", they are inherent parameters of the control problem.ISS may be non-cooperative, but it's certainly not trying to evade. Given its own very poor control authority, suppose it was cooperating, what exactly would it have done other than just hold 3 axis stable, and wait for the VV to take its time, line up, and then glide forward?
Quote from: Semmel on 01/12/2017 02:53 pmcomputer knows the orbit of your target3. Raise your orbit slowly timed such that you approach your target from behindFor the docking, the target docking port needs to provide a signal of some kind that you can target.I said an uncooperative target. No data is exchanged between vehicles nor its the target attitude known.3. Why? What says the docking adaptor is in that location
Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.
The eight programs used during a typical mission average about 75 percent CPU utilization for most flight regimes, which leaves us well within the capability of this machine. Very early on in the development phase, we did have some trouble with excessive CPU utilization. We went through a very detailed scrub of the software requirements and the code to achieve the CPU utilization we have today.
How about the Shuttle? According to The Space Shuttle Primary Computer System, the Shuttle computer was about 75% busy, which already took considerable optimization:QuoteThe eight programs used during a typical mission average about 75 percent CPU utilization for most flight regimes, which leaves us well within the capability of this machine. Very early on in the development phase, we did have some trouble with excessive CPU utilization. We went through a very detailed scrub of the software requirements and the code to achieve the CPU utilization we have today. Given that rocket landings are several times more fast paced than Shuttle landings, the Shuttle computers seem marginal for this job. Interestingly, the Delta RIFCA computers seem about an order of magnitude faster than the Shuttle computers, and probably have the compute horsepower for the job. However, other aspects of the system they are embedded in seem to hobble them quite severely, since they can't even accomodate yaw steering, which Titan, Apollo, and the Shuttle could do.
With some time to think about what you said, I might have a clue what you are getting at.I dont remember where I heard that from and I dont find the source, but shuttle was designed to catch a satellite and carry it back to earth for analysis. The satellite didnt necessarily have to be operational for that capture operation or cooperative for that matter (i.e. the requirement was to be able to capture a Russian spy satellite, it was cold war after all). I dont know if that capability was ever used, but I think to remember that this was a requirement by the air force to the space shuttle. Therefore, it needed the capability to rendezvous and "dock" with a non-cooperative target.
Exactly. It was THE major problems that had to be solved by the folks of ConXpress (and other orbital recovery projects in the early 2000's): How to rendez-vous and dock with an uncooperative target? There is some good documentation out there about that particular problem. And it confirms what Jim has been stating for the past few days.
Doesnt the ASDS or the landing pad qualify as an "uncooperative" target? It's stationary ok but it's not exchanging any data with the vehicle just like the ISS.
Quote from: Jim on 01/12/2017 04:29 pmIt is part of the conversion because it is hard. "Uncooperative" means it doesn't have any interaction with the chaser spacecraft.Except that does not apply to ISS IIRC. All contract winners had to provide systems to ISS to allow it to stop the berthing (not docking so far that will be for CRS2) QuoteThat is what autonomous robotic servicing spacecraft will have to do. They will have approach a spacecraft that is not designed for routine rendezvous and docking. It will have to use onboard sensors to find the target spacecraft and then will have to find an area such as the launch adapter as a mating point. True, but that's not a description of what happens (and what did happen with Shuttle) WRT ISS.
Next, in rendezvous the control inputs are largely orthogonal. Designers explicitly build in combinations of thrusters that do a single operation - three types of translation, and three types of rotation.
Next, rendezvous is almost completely insensitive to modelling and performance errors. If your performance is worse than you expect, or your estimated mass is wrong, it still works fine. This is because you perform each maneuver by thrusting in the desired direction until the IMU tells you that you have the correct delta V. This technique has saved many missions where the rocket performance was less than expected.
But for landing, your model needs to be precisely correct. If you are at 100 meters, and sinking with rate X m/s, there is one and only one acceleration that will bring you to zero speed at zero altitude. If your model (or your hardware) is wrong, and you get any less (or more) acceleration, it's a bad day.
Quote from: kevinof on 01/12/2017 05:12 pmDoesnt the ASDS or the landing pad qualify as an "uncooperative" target? It's stationary ok but it's not exchanging any data with the vehicle just like the ISS.Its location is known and programmed into F9
Quote from: Semmel on 01/10/2017 06:09 pmQuote from: Jim on 01/10/2017 05:54 pmWrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.How do you know that?He doesn't. His experiences lead his to certain biases.Consider the matter, if you are on top of a 4 story building, and you have a hang glider and a pogo stick with a brake, and your task is to land safely--which do you want to use?The Shuttle is the glider.The Falcon is the pogo stick.
Quote from: Jim on 01/10/2017 05:54 pmWrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.How do you know that?
1. Please dont speak for Jim. I dont know who you are but speaking for Jim is just asking for trouble. You can be lucky if your post is not deleted. I would hive it a dislike if that would exist.2. I am not looking for an analogy. I am looking for hard, cold, engineering reasoning. Its always harder than you think. LouScheffer gave some good insight. But thats probably all we can get.3. Lar gave us a shot in front of our metaphorical bow. If we continue with the "I know better than you what is more difficult", posts get deleted. Arguments get hurt and ultimately, threads get closed. So I would very much appreciate to get back on topic and discuss the challenges of landing falcon first stages. Discussing whats more difficult is not helpful.4. The initial question "why wasnt booster landing done before?" got answered way back: The solution was not interesting enough for the rocket builders of the past. It had nothing to do with the difficulty of the job, far less with being impossible for the computer hardware. It might have been impossible, but it was not tried so we will not know.
He doesn't. His experiences lead his to certain biases.
GPS has become so ubiquitous that people don't seem to be able to consider navigation problems without it. It makes life simple but I don't believe it's essential.
One of the old timers at work was giving a presentation last year, and in discussing the present-day work on the problem of collaborative swarm navigation of autonomous vehicles[e.g.] while GPS-denied in the presence of enemy jamming, he noted that before the 90's, ALL navigation was "GPS-denied."
Or maybe I should say velocity sensors, since the barge position is not only uncertain in seas but it's rate of movement in all directions is constantly changing.
Quote from: JamesH65 on 01/12/2017 08:31 amI'm a software engineer, just looking at the problem from where I am, docking is an easier SW problem than landing the F9 booster. Call it intuition, since you seem to accept that as valid.That is because you don't understand orbital mechanics. It is not just docking, it is rendezvous. The landing spot for F9 never changes, the vehicle's attitude at landing is the same.
The flight path back to the it [landing spot] is never out of plane.
Quote from: Nomadd on 01/14/2017 03:53 pmOr maybe I should say velocity sensors, since the barge position is not only uncertain in seas but it's rate of movement in all directions is constantly changing. I reckon that's a benefit of the hoverslam - everything is over before the barge has a chance to move much. Sent from my iPhone using Tapatalk
I don't know, Lou, I'm starting to come around to Jim's point of view. The evidence? SpaceX just made that landing look really easy.
So here is a question: Some industry professionals have declared that landing a returning stage on a carriage without use of landing legs is a stupid idea, and impossible. If they manage to do so, will it have been more difficult than orbital rendezvous? In their opinion of course.Matthew
So hey - Suppose SpaceX shows 10 consecutive landings that are within say 0.5 m, and thatthey have cores to spare.Will we see a legless S1 trying to nail a cradle landing? Or is the concept to difficult to pull off with a tiny little rocket like F9 and will have to wait for larger ones?
Quote from: meekGee on 01/14/2017 06:56 pmSo hey - Suppose SpaceX shows 10 consecutive landings that are within say 0.5 m, and thatthey have cores to spare.Will we see a legless S1 trying to nail a cradle landing? Or is the concept to difficult to pull off with a tiny little rocket like F9 and will have to wait for larger ones?Maybe not legless for the F9, but they could install four harness points on the landing surface for the leg tips to align with.
There needs to be a seize-proof acceptance cone - something that will capture the stumps (both top and bottom), allow for some X-Y tolerance, and dissipate Z momentum as it captures the rocket. It should help the rocket align itself vertically, since once the bottom gets moved in X-Y, the rocket can no longer stay vertical on its own.
Ideal would be if the contact point for the alignment mechanism would be at the hight of the centre of mass of the almost empty landing stage. That way, no rotation forces are caused by the alignment. Does anyone know the hight of the centre of mass of a landing F9? Its definitely below the upper connection point of the legs. Could partly-deployed legs do the trick?
Quote from: Semmel on 01/14/2017 10:38 pmIdeal would be if the contact point for the alignment mechanism would be at the hight of the centre of mass of the almost empty landing stage. That way, no rotation forces are caused by the alignment. Does anyone know the hight of the centre of mass of a landing F9? Its definitely below the upper connection point of the legs. Could partly-deployed legs do the trick?That would be sweet. Of course, once the legs no longer bear the load of the rocket you can reduce their mass and reap some savings. Without the need to extend as far, same for the telescoping pistons. Now you start asking, wait why are these even legs in the first place? And maybe that just brings us around to fins/alignment structures as described for ITS.But start with normal leg landings and build from there. No capture mechanism at first, just a precise set of markers on the pad. Make any mods to the F9's tracking system, e.g. enhancements to the landing radar (perhaps beacons on the pad?) or the addition of cameras.Musk noted that ITS would accomplish this with maneuvering thrusters. Would the F9 benefit from an additional set of nitrogen thrusters toward the bottom of the stage?
A couple of data points. The first test on a fly by wire system of an unstable aircraft was done using a spare Apollo Guidance Computer running about 32KIPS. The original IBM 4Pi processor was rated about 400KIPs so 75% of capacity would have been about 300 KIPS. The upgrade version brought it up to about 1 MIPS. IIRC SX uses ARM processors running in the 100s MHz range so an order of magnitude above the RIFCA
Wind soundings are first obtained, from which a smoothed wind velocity vs altitude relationship is established. Design for conditions at the end of the boost phase with initial pitch and yaw maneuvers, followed by zero total angle of attack through the filtered wind establishes the required vehicle attitude as a function of altitude. Polynomial coefficients for pitch and yaw attitude vs altitude are determined and are transmitted for validation and loading into the Centaur airborne computer.
In this case, there exists a feasible trajectory to the target, so the algorithm returns the minimum-fuel solution to the target. This solution requires 399.4 kg of fuel and has t_f of 78.4 s. The total computation time required was 14.3 s, and 23 iterations of golden search were used. Note that almost all of the available fuel was required to reach the target. This example illustrates the value of the convex optimization, which guarantees finding a solution if one exists; even cases at the edge of the physical capabilities of the spacecraft can be solved.
Quote from: dglow on 01/14/2017 11:46 pmQuote from: Semmel on 01/14/2017 10:38 pmIdeal would be if the contact point for the alignment mechanism would be at the hight of the centre of mass of the almost empty landing stage. That way, no rotation forces are caused by the alignment. Does anyone know the hight of the centre of mass of a landing F9? Its definitely below the upper connection point of the legs. Could partly-deployed legs do the trick?That would be sweet. Of course, once the legs no longer bear the load of the rocket you can reduce their mass and reap some savings. Without the need to extend as far, same for the telescoping pistons. Now you start asking, wait why are these even legs in the first place? And maybe that just brings us around to fins/alignment structures as described for ITS.But start with normal leg landings and build from there. No capture mechanism at first, just a precise set of markers on the pad. Make any mods to the F9's tracking system, e.g. enhancements to the landing radar (perhaps beacons on the pad?) or the addition of cameras.Musk noted that ITS would accomplish this with maneuvering thrusters. Would the F9 benefit from an additional set of nitrogen thrusters toward the bottom of the stage?what weighs less. Legs or additional N2 thrusters and fuel?
However, these state of the art methods use convex optimization, which requires significant computer power. From Minimum-Landing-Error Powered-Descent Guidance for Mars Landing Using Convex Optimization, where they used a MacBook Pro:QuoteIn this case, there exists a feasible trajectory to the target, so the algorithm returns the minimum-fuel solution to the target. This solution requires 399.4 kg of fuel and has t_f of 78.4 s. The total computation time required was 14.3 s, and 23 iterations of golden search were used. Note that almost all of the available fuel was required to reach the target. This example illustrates the value of the convex optimization, which guarantees finding a solution if one exists; even cases at the edge of the physical capabilities of the spacecraft can be solved.Even allowing for optimizations, an algorithm that takes 14 seconds on a MacBook pro is not something you'll want the Shuttle computers to try during descent.So yes, SpaceX made it look easy. What you can't see is how much fuel (and nitrogen, and hydraulic fluid) is left in the tanks at landing. And what's even harder to see is how much more of each would have been required, had you used methods that could be implemented by slower computers.
The paper that started this mentioned that SX uses something called CVXGen.AFAIK This thing creates a convex optimization program tailored to the specific parameters of a problem (any problem), rather than a general purpose optimization package running on the OBC. Being more specific about the parameter ranges other factors should result in a more resource efficient optimizer at the expense of potentially quite a lot of pre processing (hours?) creating time, and a design that may only be numerically stable over the range of the problem. Neither of which is a problem for SX as long as the resulting program (not a solution, a software package for computing the solution in real time) runs fast enough on the day and the parameters remain in the ranges they've specified
Optimization is a core part of SpaceX booster landings in a way that was not needed for Shuttle landings.
CVXgen generates C code for solving a convex problem with a particular structure. This C code is then compiled and runs on something like real-time linux on the returning stage. While the problem structure remains the same, the problem is resolved in real-time during the landing using different parameters. These parameters in particular depend on the current estimate for the state obtained (indirectly) from GPS data, IMUs, radar, sensors inside the stage etc. Both generating and compiling the generated C code will take some time, but we're probably talking about minutes, not hours. But it's mostly irrelevant since it's only done once and before take-off.
Much more important is that the resulting C code is able to calculate a control action very quickly and reliably after obtaining sensor measurements, probably within milliseconds. This allows the stage to react to external disturbances such as gusts of wind, waves etc and adjust the flight trajectory accordingly.
But for booster landing, consumables used for landing come directly out of launch performance. Given that rocket launches are already low-margin operations, there is a huge incentive to use a near-optimal landing strategy, getting as close as possible to the limits of what the hardware can do.
This. It's also a radically different control problem.
A glider like the Shuttle is a well-behaving and stable system. A rocket under power is the very opposite of that.
A glider like the Shuttle is a well-behaving and stable system.
My instinct is that the stage cannot measure local wind conditions directly (IE no air data system). It has to infer them from internal measurements and uncommanded position and attitude shifts.
I have a book called "Frontiers of Space" by Kenneth Gatland, published in 1969. In it he shows where Boeing did a study to put a heat shield on top of a Saturn V first stage and parachute it into the ocean, to be tugged back to the cape. It would land nose down with the engines up out of the water. So reuse was studied. Also replacing the J-2 engine on the third stage with a plug nozzle engine for use as a heat shield to land the third stage. Third stage could have also been used as a SSTO vehicle for small satellite launcher. So, landing and reuse was studied, but NO MONEY was appropriated by congress to make Saturn reusable. To me this would have been a cheaper upgrade than going to shuttle, and sooner. Heavier payloads, and more in space construction, earlier. Now SpaceX is doing it, hopefully they will fly one of the landed stages soon.
I have a book called "Frontiers of Space" by Kenneth Gatland, published in 1969. In it he shows where Boeing did a study to put a heat shield on top of a Saturn V first stage and parachute it into the ocean, to be tugged back to the cape. It would land nose down with the engines up out of the water. So reuse was studied. Also replacing the J-2 engine on the third stage with a plug nozzle engine for use as a heat shield to land the third stage. Third stage could have also been used as a SSTO vehicle for small satellite launcher.
SpaceX didn't invent the idea of reuse.They "merely" a) decided to do it without waiting for a gov. check, b) made a long string of right decisions, and c) had the agility to change course when they made bad ones. d) nailed everything else..
SpaceX’s self-landing rocket is a flying robot that’s great at math
Alumni stories: Meet the principal rocket landing engineer at SpaceXFrom a young age, Lars Blackmore was interested in space travel and had a goal to one day work on electronics for spacecraft. It’s been a journey that’s led him from studying Engineering at Cambridge to completing a PhD in Aeronautics and Astronautics at Massachusetts Institute of Technology (MIT), before going on to land engineering roles at both NASA and SpaceX.
What’s next for Lars?Sending people to the Moon and Mars! I’m now leading entry and landing for Starship, a fully reusable rocket that will one day be able to land up to 100 people on the surface of Mars.[...]Landing Starship will be much harder than landing Falcon 9, but if we can do it, it will be revolutionary.
Yesterday I met the fourth employee at SpaceX. Hans Koenigsmann. I asked him how they did the code that lands rockets back on earth so they can be reused. “Oh, one person wrote that.” What? Yeah, it’s better for a single human, he told me, to write it because one person could keep the whole system in their head. Get more people involved and it gets confusing, he told me.He admitted other people were involved, but most of it was done by one person. Reminds me of @stevewoz who was the last human to have an entire computer in his head. So, why can’t Lockheed or Boeing figure this out? The committee can’t decide who is smart enough to do the code. :-)