Author Topic: SpaceX paper on precision landing - and landing technology Thread  (Read 17764 times)

Offline FutureSpaceTourist

  • Senior Member
  • *****
  • Posts: 2154
  • UK
    • Plan 28
  • Liked: 1358
  • Likes Given: 527
Great paper by Lars Blackmore (principal rocket landing engineer at SpaceX) on the challenges of precision landing:

Quote
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.

https://twitter.com/larsblackmore/status/815354936741412864
« Last Edit: 01/01/2017 06:41 AM by FutureSpaceTourist »

Offline FutureSpaceTourist

  • Senior Member
  • *****
  • Posts: 2154
  • UK
    • Plan 28
  • Liked: 1358
  • Likes Given: 527
The attached figure shows how dispersions (largest possible trajectory variations) vary through the different stages of flight.

Offline FutureSpaceTourist

  • Senior Member
  • *****
  • Posts: 2154
  • UK
    • Plan 28
  • Liked: 1358
  • Likes Given: 527
Some good references in Lars' article. Way out of my field but I found the discussion in the last section, about knowing accurately where you are on Mars with no GPS, particularly interesting. The following terrain navigation paper he cites is atrached:

Quote
Real-time terrain relative navigation test results from a relevant environment for Mars landing

Johnson, Andrew E.; Cheng, Yang; Montgomery, James; Trawny, Nikolas; Tweddle, Brent; Zheng, Jason

URI: http://hdl.handle.net/2014/45631
Date: 2015-01-05
Keywords: EDL; Lander Vision System; GNC; Pin-point Landing; Mars 2020
Publisher: Pasadena, CA : Jet Propulsion Laboratory, National Aeronautics and Space Administration, 2015
Citation: AIAA Scitech 2015, Kissimee, Florida, January 5-9, 2015

Abstract:
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.

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
Great 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 ]
« Last Edit: 01/01/2017 01:00 PM by john smith 19 »
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Online AnalogMan

  • Member
  • Senior Member
  • *****
  • Posts: 2903
  • Cambridge, UK
  • Liked: 572
  • Likes Given: 19
I extracted the article by Lars Blackmore from The Bridge periodical linked/attached in the opening post.
« Last Edit: 01/01/2017 12:37 PM by AnalogMan »

Offline Robotbeat

  • Senior Member
  • *****
  • Posts: 25677
  • Minnesota
  • Liked: 5803
  • Likes Given: 4314
Sweet.
Chris  Whoever loves correction loves knowledge, but he who hates reproof is stupid.

To the maximum extent practicable, the Federal Government shall plan missions to accommodate the space transportation services capabilities of United States commercial providers. US law http://goo.gl/YZYNt0

Offline rpapo

  • Cybernetic Mole
  • Full Member
  • ****
  • Posts: 941
  • Michigan, USA
  • Liked: 399
  • Likes Given: 330
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.
An Apollo fanboy . . . fifty years ago.

Offline Lar

  • Fan boy at large
  • Global Moderator
  • Senior Member
  • *****
  • Posts: 7439
  • Saw Gemini live on TV
  • A large LEGO storage facility ... in Michigan
  • Liked: 4331
  • Likes Given: 2933
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.

After I read it I felt like I hadn't learned much. But then MAYBE I'm a sigma (or 3!! ) above the average reader in my knowledge in this area (thanks, NSF!!!!)  :)
"I think it would be great to be born on Earth and to die on Mars. Just hopefully not at the point of impact." -Elon Musk
"We're a little bit like the dog who caught the bus" - Musk after CRS-8 S1 successfully landed on ASDS OCISLY

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
(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.
« Last Edit: 01/07/2017 08:42 PM by meekGee »
ABCD - Always Be Counting Down

Offline Robotbeat

  • Senior Member
  • *****
  • Posts: 25677
  • Minnesota
  • Liked: 5803
  • Likes Given: 4314
Docking isn't trivial, either. You can afford to take longer. But you have to hit a smaller target and the pieces are less forgiving for relative velocity.

Landing on a barge is much harder though. You have one shot and no change of abort and redo.
Chris  Whoever loves correction loves knowledge, but he who hates reproof is stupid.

To the maximum extent practicable, the Federal Government shall plan missions to accommodate the space transportation services capabilities of United States commercial providers. US law http://goo.gl/YZYNt0

Offline rpapo

  • Cybernetic Mole
  • Full Member
  • ****
  • Posts: 941
  • Michigan, USA
  • Liked: 399
  • Likes Given: 330
Landing on a barge is much harder though. You have one shot and no change of abort and redo.
You don't get to abort or redo on land either.  Not with thrust/weight > 1.

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.
An Apollo fanboy . . . fifty years ago.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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.
« Last Edit: 01/08/2017 02:09 PM by Jim »

Offline laszlo

  • Full Member
  • *
  • Posts: 117
  • Liked: 141
  • Likes Given: 17

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.

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.

Offline MarekCyzio

(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.


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.


Sent from my iPhone using Tapatalk

Offline DOCinCT


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.

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.
One NASA planning document outlined a reusable lander that would make multiple trips to LMO to bring additional cargo to the surface.  Required MethaLox engines and ISRU production of fuel.

Offline Oersted

  • Member
  • Full Member
  • ****
  • Posts: 566
  • Liked: 260
  • Likes Given: 147
...
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.

He did mention delay when he referred to a "sluggish throttle control".
« Last Edit: 01/10/2017 11:04 AM by Oersted »

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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.

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.


Bingo

Offline dglow

  • Full Member
  • ****
  • Posts: 712
  • California
  • Liked: 519
  • Likes Given: 1216
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.


Bingo

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.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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.

That wasn't a constraint. Shuttle avionics could have done it.

Offline dglow

  • Full Member
  • ****
  • Posts: 712
  • California
  • Liked: 519
  • Likes Given: 1216

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.

That wasn't a constraint. Shuttle avionics could have done it.

No.

Offline envy887

  • Full Member
  • ****
  • Posts: 1497
  • Liked: 642
  • Likes Given: 347

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.

That wasn't a constraint. Shuttle avionics could have done it.

Shuttle avionics did support autonomous nav, guidance, and control for landing.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

No.

Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous  RTLS and hoverslam landing.
« Last Edit: 01/10/2017 06:05 PM by Jim »

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677

No.

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?

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

No.

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?

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)
« Last Edit: 01/10/2017 06:30 PM by Jim »

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
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.
Except on that basis Grasshopper should have shaken out any residual issues and the first landing should have been successful.

It wasn't. 

All the major LV mfg's in the 60's talked about 1st stage reuse. None of them had to do it. SX's experience suggests they would have seriously struggled to do so. The fact that SX only succeed after they fitted grid fins to the top end suggest that any strategy that relied on engine retro thrust was doomed to fail.

The operative word in rocket science is science and science cannot be rushed.  :(



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)
You missed having the big lump of the SSME's at the back, demanding a constantly operating computer system driving constantly moving aerosurfaces. Dyna Soar was expected to use a similar hybrid control system and the X15 was able to test such a system over a significant section of the speed / altitude range.

Shuttle was designed to come back to Earth. 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.
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
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.

not avionics wise

Offline Lars-J

  • Senior Member
  • *****
  • Posts: 2690
  • California
  • Liked: 2114
  • Likes Given: 1209

No.

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?

Simple. Because it is SpaceX.  ;)

Offline mvpel

  • Full Member
  • ****
  • Posts: 1099
  • New Hampshire
  • Liked: 1268
  • Likes Given: 1604
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.

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.
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline dglow

  • Full Member
  • ****
  • Posts: 712
  • California
  • Liked: 519
  • Likes Given: 1216
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.

The first shuttle computer was early 1970s hardware, with .4 MIPS and ~416K of core memory.

http://commons.erau.edu/cgi/viewcontent.cgi?article=2024&context=space-congress-proceedings


Thank you for the anecdotes, especially the Nike! Analog computing is very romantic.  :)

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
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.

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.

An intercept requires zeroing 3 independent DOFs.  An F9 landing requires zeroing 6 coupled DOFs + their first derivatives, or 12.  Not remotely the same.

Whether STS computers were powerful enough doesn't matter.  This was about the statement that "landing an F9 is easier than docking a spacecraft".

Compute power is just a part of it. Solving the control problem was a bigger part.  Doing the system engineering, yet another. Finding a way to finance it - yet another.

To paint it as "it simply wasn't done since nobody wanted it" is transparent denial and self-gratification...

It wasn't done for many reasons: Nobody had (simultaneously) the vision of doing it, the capability to do it, and the audacity.



ABCD - Always Be Counting Down

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
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.

Just as "it simply wasn't done since nobody wanted it" is reality.  Trying to paint it otherwise is just more sycophancy.

I have provided plenty of support.  Just some people are too biased to accept the truth.
The landing site is known vs the unknown location of the target spacecraft.  Stopping at the end is not big deal.  We have landed on other bodies before.
As for autonomous docking, you have made the assumption that the docking adapter is point towards the approaching vehicle.  As I stated before, it is an uncooperative target, meaning it does not provide location or attitude to the chaser spacecraft.
« Last Edit: 01/11/2017 02:37 AM by Andy USA »

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
God I hope you're kidding but I suspect you aren't.
Waiting for this exchange to be nuked already.
Peace - out.
ABCD - Always Be Counting Down

Online Stan-1967

  • Full Member
  • ***
  • Posts: 395
  • Denver, Colorado
  • Liked: 216
  • Likes Given: 135
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)

Wrong
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.  Both have their own needs in regards to accuracy. 

Comparing STS to F9 is not helpful.  Specifically from an energy management perspective as you did, not to mention complete different types of vehicles.  There was a good thread comparing F9 to New Shepard.  In the end even those two are very imperfect comparisons, STS vs. F9 is worse.

STS's challenge was in shedding enormous amounts of energy.  To do that it had plentiful aerodynamic means to do so.  The STS's crossrange is testament to that.  F9 doesn't face the high hypersonic regime, but is challenged in the hypersonic to subsonic regimes because it has a near insignificant L/D to manage energy, whereas STS has ample aerodynamic L/D options and trajectory solutions to manage energy.  ( look at the wide turns it made on mid range ground tracks, as well as the turn to final approach.  The radius of the STS turn to final is where energy can get fine tuned for the landing )  Once STS is within close range of the runway, there is little doubt that it will land intact barring pilot error or landing gear collapse.

F9 on the other hand is energy poor from the perspective of nulling the vertical & horizontal velocity components.   It has just enough energy in the propellant for a single shot at landing.  STS had a runway to null the last remaining energy in the vehicle.  There is no 15,000 ft deep net to catch it should its velocity be not exact when it's over the numbers at the end of it's runway.  ( errr..drone ship)

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?




Offline FutureSpaceTourist

  • Senior Member
  • *****
  • Posts: 2154
  • UK
    • Plan 28
  • Liked: 1358
  • Likes Given: 527
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?

Yes, please let's get the thread back to this topic (unless there's another thread that's already covered it, in which case please link).

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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. 


Wrong.  The OMS just changed the orbit to one that intersected the atmosphere, so it is not analogous to the boost back burn.

Online Stan-1967

  • Full Member
  • ***
  • Posts: 395
  • Denver, Colorado
  • Liked: 216
  • Likes Given: 135

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. 


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?

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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?

Extra propellant is needed until a local navigation system is provided.

Offline Joel

  • Full Member
  • ****
  • Posts: 532
  • Madison, WI
  • Liked: 42
  • Likes Given: 41
Great 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 ]
My understanding is that the trajectory planning uses a first-principle model of the reentering stage, higher-fidelity model for Earth than for Mars as stated in the paper. By using CVXGen, you can solve the resulting convex problems (should be a Second-Order Cone Program) very fast, probably in milliseconds. The controller is then fast enough to e.g. react to a wind shift. Embedded optimization like this first appeared in the chemical process industry in the 1980ies, with much slower processes. Only spread to aerospace applications in the last decade or so. Is still very much a hot research topic, both in terms of algorithms and software.

Offline JamesH65

  • Full Member
  • ****
  • Posts: 485
  • Liked: 263
  • Likes Given: 6
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.


Sorry, I don't believe you - you have not shown this in any of your posts. And I doubt you can provide any SW evidence to back up this claim.

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.
« Last Edit: 01/12/2017 08:34 AM by JamesH65 »

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
Maybe we should define what "difficulty" means in this context. We can run in circles all day long if we all have different metrics on the term "difficulty".

So please, define your metric and then we can measure the "difficulty" of landing F9, landing Shuttle, docking and others activities.

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392

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. 


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?
There is a study of landing error Vs improved models for the European reentry demonstrator (the lifting body I think it was called Colibri?)
Fixed g to proper evaluation of the inverse square law went from 120 x 50 Km --> 8x5 Km landing ellipse
Moving to an interpolated L/D ratio dropped that to 4 x 3.5Km
Going from an exponential to a US std model of the atmosphere dropped that to 0.7x1.7Km

IIRC Image recognition could bring that down to 0.4x0.4Km.

So a really good model of the precise gravity field around a planet (from a fixed number to the the 300 term and now 2000+ term from the satellite part funded by the USAF) helps a lot.

Likewise a good model of the atmosphere. On Earth the outer fringes of which can vary 10x by hour of the day and season. Or you have some kind of on board sensor (they seem to like the name "sounder") that maps the atmosphere on a pass and uses those values for the day.

Astronav systems using 40 guidance stars (which are daylight visible with the right filters) can pin down a location on Earth to 6m, provided you have an accurate time reference.

My instinct is that INS with a good enough baseline can do a lot. There drift over the time for decent is small enough not to be a problem. Worst case puts a radar altimeter on the vehicle. It may only have a 500m range but the ground is a pretty big target.

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.
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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.

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 is never out of plane.     
 
Software?  Easy - most of it is just a continuation of the launch flight program.  The flip around, boost back and braking burns are something most other launch vehicles avionics could execute.  Adding booster ACS and grid fins aren't hard additions from a software POV.  Landing has been done by many vehicles on many planets.

The challenge for Spacex was to keep enough propellant reserves to cover dispersions to ensure landing but at the same time provide enough dV to the second stage.  Spacex was able to determine this incrementally though flight tests during launches and grasshopper flights.  Spacex was also able to determine control gains through these tests.   These tests helped determine time and efficiency of all the burns after separation. 

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
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 orbit
2. Align orbital planes
3. Raise your orbit slowly timed such that you approach your target from behind
4. Initiate docking

For 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 state
2. Approach the docking port within a defined trajectory envelope
3. if envelope is violated, abort docking and go back to step 1.
4. otherwise approach until docked

This 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.

Online llanitedave

  • Senior Member
  • *****
  • Posts: 2042
  • Nevada Desert
  • Liked: 1239
  • Likes Given: 1417
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 orbit
2. Align orbital planes
3. Raise your orbit slowly timed such that you approach your target from behind
4. Initiate docking

For 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 state
2. Approach the docking port within a defined trajectory envelope
3. if envelope is violated, abort docking and go back to step 1.
4. otherwise approach until docked

This 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.


Way too much mistaking of intuition for objective fact on this thread.  Engineers should know better.
"I've just abducted an alien -- now what?"

Offline Robotbeat

  • Senior Member
  • *****
  • Posts: 25677
  • Minnesota
  • Liked: 5803
  • Likes Given: 4314
The idea that software is easy... Is wrong. :)
Chris  Whoever loves correction loves knowledge, but he who hates reproof is stupid.

To the maximum extent practicable, the Federal Government shall plan missions to accommodate the space transportation services capabilities of United States commercial providers. US law http://goo.gl/YZYNt0

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
The idea that software is easy... Is wrong. :)

Thats what I wanted to show. But maybe there are other things that are hard that Jim is getting at. I like to understand that.

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.
« Last Edit: 01/12/2017 03:29 PM by Semmel »

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
computer knows the orbit of your target

3.  Raise your orbit slowly timed such that you approach your target from behind

For 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

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
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?

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
Orbital mechanics, or orbital bodies, are the most predictable things there are.

Time spans for rendezvous and docking are hours..  minutes at the end... 

Meanwhile landing occurs in wind, in seconds, with control time constants that are also measured in seconds.

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?

ABCD - Always Be Counting Down

Offline rpapo

  • Cybernetic Mole
  • Full Member
  • ****
  • Posts: 941
  • Michigan, USA
  • Liked: 399
  • Likes Given: 330
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 could imagine rescue missions as "uncooperative", but I don't believe that was ever part of this conversation.
An Apollo fanboy . . . fifty years ago.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
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?

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. 

Offline kch

  • Full Member
  • ****
  • Posts: 1714
  • Liked: 455
  • Likes Given: 7978
I must have missed the uncooperative part in the past.

Yes, you did:


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.

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
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.

Out of curiosity.. when was there ever a docking with an uncooperative target?

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
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.



The point was software and modern avionics were not the enabler for the ability to land the stage.

https://forum.nasaspaceflight.com/index.php?topic=41935.msg1627456#msg1627456
« Last Edit: 01/12/2017 05:02 PM by Jim »

Offline kevinof

  • Full Member
  • ****
  • Posts: 447
  • Dublin/London
  • Liked: 203
  • Likes Given: 253
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.

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
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.

ISS keeps itself stable in three axis, and there's positional feedback for closing the loop at end-of-docking.

Additionally, before the closed loop is enabled, ISS tells everyone where it is

That's not very uncooperative.

In a control sense of the word, ISS doesn't actively try to "dock back", so will it counter (AFAIK) any impulse given to it by the VV, but given the difference in sizes, that's immaterial.  It had more relevancy when talking about a Gemini-Gemini docking, or something like that.   As far as the VV is concerned, ISS is an inertial and stable target - best thing you can ask for.
ABCD - Always Be Counting Down

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
It 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)
Quote
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.
True, but that's not a description of what happens (and what did happen with Shuttle) WRT ISS.
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392

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?
True.

You also forgot the big ones.

F9 stage is mostly empty and has very high aspect ratio. It is (relatively) "floppy" causing a moving Cg. You've got 2 tank ends part way up as a point mass and another at the top to act as a 2nd point mass.

As it has turned out the control problem is in fact impossible without the use of grid fins since the engines simply lack the control authority over the structure.  :(

Realizing that, figuring what to do about it and making the solution work is rocket science.

OT This seems to be a recurring theme of aerospace problems. The physically simplest systems (in terms of geometry) seem to have very complex behaviors and require a lot of manual tuning. I'm thinking of ramjets, SCramjets and lifting bodies. High AR tank structures would also seem to be in this category.

I suspect there is something in the underlying mathematics of all these problems that makes them sensitive to apparently minor changes in geometry. Unfortunately I have no idea what that is.  :(
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline woods170

  • IRAS fan
  • Senior Member
  • *****
  • Posts: 6691
  • IRAS fan
  • The Netherlands
  • Liked: 2141
  • Likes Given: 639
computer knows the orbit of your target

3.  Raise your orbit slowly timed such that you approach your target from behind

For 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

Exactly. It was THE major problem 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.
« Last Edit: 01/13/2017 07:50 AM by woods170 »

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
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.

Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous  RTLS and hoverslam landing.

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.

Also, there was a requirement for the space shuttle to land back at the cape after just one orbit. This requirement actually meant that it needed extreme cross range capability and quite tough control algorithms.

I dont know if you meant these things but if so, it would have been easier to actually name them as example when you made your initial statements. At least we would have known what you specifically are talking about and didnt need to have this "believe me because I am an authority on the topic". I get that you sometimes have to restrict your comments to simple statements because of some stuff you are working on is secret. But in case of things that are public knowledge like the above, it is not necessary. You could simply follow your statement with an argument why things are the way they are.

It makes sense that "docking" with an uncooperative target is a tough problem to solve, but I don't understand why you think its tougher than the hoverslam landing of an F9. I dont say the hoverslam is harder, I simply dont know. So please provide your argument in a way that actually provides some insight into the matter.

For the record, I think a hoverslam landing was possible in the shuttle area. In the 70th and 80th, people simply didnt care to solve the problem because they didnt think it was worthwhile or maybe because they never thought of that idea in the first place. SpaceX can now prove that they are able to deliver the cheap re-usability that the shuttle promised but never was able to deliver. In terms of economic re-usability, shuttle was a failure. I hope F9 is the opposite.

Offline LouScheffer

  • Full Member
  • ****
  • Posts: 1349
  • Liked: 1363
  • Likes Given: 173
An engineering view of why landing is harder than rendezvous.  By rendezvous I mean up to stationkeeping, in the same orbit, as a non-maneuvering but otherwise non-cooperative target whose orbit is known.  Actual docking from that point can range from fairly easy (if it's designed in) to hideously difficult (a spinning target not designed for docking).

In both cases we need to match location and velocity, with near-zero angular rates.  In one case the target is in inertial space, in the other an Earth-based frame.  This in itself makes very little difference as rockets already have to deal with both frames, and they are related by the uniform angular velocity of the Earth's rotation.

The variables in rendezvous are separable.  This means you can fix one, and it stays fixed while you adjust the others.  For example, you can start by zeroing angular rates.  If after that, if you thrust through the center of gravity (which you control) the rates stay zero.  And if you do end up with any angular rates, you can re-zero them without screwing anything else up.  Next, you can enter a common orbital plane.  After that, as long as your burns are in plane (which you control) this variable stays fixed.  Then a single burn magnitude matches the apogee, and after that it stays fixed (provided you do futher maneuvers at apogee, which you control).  You can set position in the orbit by timing this burn (also under your control).  The two variables of the burn do not interact in any way, and don't disturb the plane, which you already set.  Finally you burn at apogee to synchonize the orbits, and this does not disturb the timing of the orbit, or the apogee, or the plane, or the angular rates.  It only affects the perigee.

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.  Even the worst combination changes only two closely related variables - a +X burn changes only X and X dot, not anything else. For main engine burns, orthogonality is achievable because of the slow pace of rendezvous - there is time to turn to the needed attitude, so your main engine thrust only affects the variables you want to change.

For landing, the variables are not separable and the controls are not orthogonal.   Suppose you have a perfect trajectory with the only problem that you need a few hundred meters of X translation (perhaps due to winds).  You can only translate the rocket by including the main engine, since the grid fins (and thrusters) do not work through the center of mass.  So a translation in X requires modifying your previously correct Z , Z dot, and at least one angular rate.  Furthermore, you can only reduce Z dot - there is no way to get the rocket to fall faster to get back to the previous solution.  So you need to plan another maneuver later, also affecting all these state variables, that hopefully restores a different but feasible solution.  Overall, rendezvous is like playing Battleship - you keep getting closer to a solution and never backtrack.  Landing is more akin to solving Rubik's cube - there are sequences that do what you want, but they necessarily make lots of other stuff worse, and then hopefully converge back to a good solution.  You need to think ahead.

Next, rendezvous can go as slow as desired, and designers take full advantage of this.  There is a reason why final approach to ISS takes many minutes, with many stops and double checks along the way.  There are very few single opportunity events - you can always stop and try again later, and this usually costs minimal, if any, fuel.  Landing must be conducted in real time, with no second chances.

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.

Next, rendezvous has a complete lack of external variation.  There is a reason why rendezvous computations wait until the vehicle is out of the atmosphere.  At this point you can plan the entire rendezvous sequence, and only correct for execution dispersions thereafter.  Landing, on the other hand, needs to compensate for variable and uncertain winds, and must do so as they happen.

So what computers could do these operations?  Almost any computer could solve the rendezvous problem.  After all, it was solved in Gemini 12 by astronauts using charts.  And Apollo did it around the moon, and could do so with no help from the ground, while accounting for most plausible malfunctions.  How about the landing problem?  Apollo, almost certainly not.  It was kept busy just trying to hit a point in 3D space.  How about the Shuttle?  According to The Space Shuttle Primary Computer System, the Shuttle computer was about 75% busy, which already took considerable optimization:
Quote
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.
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.

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
How about the Shuttle?  According to The Space Shuttle Primary Computer System, the Shuttle computer was about 75% busy, which already took considerable optimization:
Quote
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.
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.
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
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.
Yes that would be a worst case scenario. It seems to have also driven the huge cross range requirement for the Shuttle as well.

It was about the most insane mission I've ever heard of since it would have either had to be mounted during WW III or would probably have started WW III.  :(

Actually STS was used to capture and repair a couple of satellites IIRC (with the owners consent). One at least was randomly tumbling. IIRC the astonaut grabbed on and used their EMU to gradually bring it under enough control that it could be grappled by the arm.
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.
So it seems Jim is comparing a maneuver that's never actually been done (but is within the range of all possible orbital maneuvers) with one that has been done but only after multiple failures.

I'd suggest that what made this problem hard would be decide what the satellites orientation was and if it was changing (IE tumbling) how to slow it down. That suggests either radar/lidar and/or image recognition. IIRC both can be very compute intensive at high data rates and high throughput rad hard computers were (and are) expensive, unless you go to a more fault tolerant architecture.

BTW for de-orbiting com sats IIRC the tactic seems to approach and lock onto the Apogee motor nozzle since its clearly defined (big round black hole)
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
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.

Its location is known and programmed into F9

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
It 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)
Quote
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.
True, but that's not a description of what happens (and what did happen with Shuttle) WRT ISS.

ISS and shuttle have nothing to with this thread

Offline ChrisC

  • Veteran
  • Full Member
  • ****
  • Posts: 1360
  • Liked: 200
  • Likes Given: 183
(facepalm)

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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. 

Not really.  Most vehicles do not do rotational couples.  There is translation with rotation.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

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.


You are mixing up rendezvous and orbital insertion.  Orbital insertion doesn't care the vehicle enters orbit.

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.


That is not changing the actual program, it is only a tweaking of the gains and constants used.
Just add more propellant, increase thrust or burn earlier and longer.  That is what flight testing is for.
The same programming is used.

Again, this isn't about determining all the necessary constants and gains.  This is about the avionics and programming.

« Last Edit: 01/17/2017 09:10 AM by Jim »

Offline Lar

  • Fan boy at large
  • Global Moderator
  • Senior Member
  • *****
  • Posts: 7439
  • Saw Gemini live on TV
  • A large LEGO storage facility ... in Michigan
  • Liked: 4331
  • Likes Given: 2933
Guys, can we try to get back on topic. rendezvous with ISS is not landing on an ASDS or on land.
« Last Edit: 01/13/2017 05:35 PM by Lar »
"I think it would be great to be born on Earth and to die on Mars. Just hopefully not at the point of impact." -Elon Musk
"We're a little bit like the dog who caught the bus" - Musk after CRS-8 S1 successfully landed on ASDS OCISLY

Online tdperk

  • Member
  • Posts: 70
  • Liked: 13
  • Likes Given: 4

No.

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?

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.

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.

Its location is known and programmed into F9

But AFAIK it does not maneuver to "catch" the Falcon.  It is more or less successful and holding a position and attitude.
« Last Edit: 01/13/2017 07:09 PM by Chris Bergin »

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
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?
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.


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.
« Last Edit: 01/13/2017 08:30 PM by Semmel »

Online tdperk

  • Member
  • Posts: 70
  • Liked: 13
  • Likes Given: 4
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.

I have yet to claim to speak for Jim.  Were I to speak for Jim, I would unavoidably be more loquacious  :P

Without numbers we don't have, its all analogy.

I'm responding to Jim, whose post Lar chose not to remove, and which post was peremptory almost to the point of rudeness as well as being obviously incorrect from an engineering standpoint.  Without numbers we don't have, we have analogy.  To put more flesh and relative energy accuracy on the analogy.
a) STS is like jumping off a 9 or 10 story building with a hang glider and an open field in front of us.  You have to land within 1" inch of on orange cone which is in the middle of your glide pattern, but you can take a few steps to zero forward momentum out.
b) Falcon is like jumping off a 4 story building with a ballistically deployed parachute which has a high enough sink rate it's use alone will cause you to RUD.  You also have a pogo stick with a brake, you have to use the brake to come to a halt vertically and balanced without bouncing or hitting too hard.
B is harder.  Neither is for the faint hearted.

" The initial question "why wasnt booster landing done before?" got answered way back "  <--  Well then the threads already over, isn't it?  It was not, as matter of fact, an engineering goal to reduce the cost of a pound to LEO--where there might be a pound of people (or several hundred pounds).  So the best means of doing so was not pursued.
« Last Edit: 01/14/2017 12:30 AM by tdperk »

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274

He doesn't.   His experiences lead his to certain biases.

Yes, I do and also it is not biases.
« Last Edit: 01/14/2017 02:44 AM by Jim »

Offline mvpel

  • Full Member
  • ****
  • Posts: 1099
  • New Hampshire
  • Liked: 1268
  • Likes Given: 1604
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."  ;D
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
Mulling things over I think the comparison between Shuttle and the F9 1st stage is unfair.

Turning it on its head the analogy would be Shuttle with SRB, SSME and OMS but almost no RCS thrusters and NASA flying several missions as they decided the minimal numbers to add to carry out their reference missions (for example because mass is phenomenally critical).

I know that is an analogy stretched almost to the point of absurdity but SX have turned a structure whose key design task (until now) has never been to return to base and many of whose best design choices actively discourage you from doing so into doing exactly that with minimal changes (IE no changes to main structures load directions, so no wings. No secondary engines etc).

This really is turning a sows ear into a silk purse.  It's hugely impressive.
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
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."  ;D
Exactly.

And the modern solution (outside military systems) is to switch to another satellite constellation.  :(

On Earth GPS and WAIS can deliver high accuracy on terminal approach but on Mars this will not be an academic exercise. The closer ITS can land to each other the less transport that has to take place before useful work can begin.  :(
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline Nomadd

  • Senior Member
  • *****
  • Posts: 2266
  • Boca Chica, Texas
  • Liked: 2387
  • Likes Given: 173
 One thing I've didn't find in this paper or anywhere else was terminal, as in the last few feet, guidance. I keep remembering the way the barge was moving all over the place including up and down during the first landing that ended vertical, but have never found any mention of final adjustments via altitude or relative position sensors on the rocket. 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.

Offline mvpel

  • Full Member
  • ****
  • Posts: 1099
  • New Hampshire
  • Liked: 1268
  • Likes Given: 1604
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.
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
"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." - Eric S. Raymond

Offline LouScheffer

  • Full Member
  • ****
  • Posts: 1349
  • Liked: 1363
  • Likes Given: 173

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.

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.   
From the navigation point of view, these statements seem wrong.  The pad location never changes in Earth based coordinates.  But that's not what inertial navigation systems use - they use (surprise) inertial coordinates.  (They could in theory use Earth based coordinates, but then you need to add Coriolis forces and other complications.  So I believe the inertial navigation systems are indeed inertial.)  In inertial space system, the pad location is constantly changing.  Basically it's moving in a circular orbit with a period of 24 hours, with a center offset from the center of the Earth.  Of course when you get close you will switch to Earth based coordinates, just as in rendezvous, where when you get close you start measuring your distance and rates relative to the target, not the Earth.

The same applies to the vehicles attitude at launch and landing.  They are both vertical, but only in a rotating Earth based frame.  From the INS point of view, the rocket's body vertical will vary as 360 degrees/24 hours* (landing-launch times).  This is about 2.1 degrees for a typical 500 second launch-landing sequence, and so can't be neglected.   (This particular effect was the cause of a Soviet launch failure.  They aligned the INS, then called a hold.  30 minutes later, the INS calculated the rocket was 8 degrees from vertical, and triggered the abort system as being out of allowable range.)
Quote
The flight path back to the it [landing spot] is never out of plane.
This seems wrong as well.  The initial plane is defined by the launch azimuth and the center of the Earth.  This plane also (nearly) includes the landing site, but only at the time of launch.  By the time the rocket get back, about 500 seconds later, the rotation of the Earth has carried the landing site about 200 km to the East.  This is a quite large correction - the Atlas launches to ISS could only cope with a 5 minute (300 second) offset from the launch plane.

Offline dglow

  • Full Member
  • ****
  • Posts: 712
  • California
  • Liked: 519
  • Likes Given: 1216
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.

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
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.
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

That IMO is critical, and why I never like the posts advocating adding "hover" abilities.

Slam it, baby!

The faster you go through the last layer of variable surface winds, the less you have to worry about them, or at least about their variability.  The stage has some notion of winds aloft, but wind sheer in the last 100 m has an effect and needs to be minimized. We've seen how the stage "leans" in the last few seconds, and basically "uncrabs" just in time for touch down.

(Show me a docking craft doing THAT....)

-----------------------

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?

I get bored easily.
« Last Edit: 01/14/2017 07:49 PM by meekGee »
ABCD - Always Be Counting Down

Offline JamesH65

  • Full Member
  • ****
  • Posts: 485
  • Liked: 263
  • Likes Given: 6
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.

Every shuttle landing looked easy too. They never missed the runway....the difference is that planes have been landing on runways for years before the shuttle did.

Offline Darkseraph

  • Full Member
  • ****
  • Posts: 402
  • Liked: 138
  • Likes Given: 76
The landing being easier than what Shuttle did may be a moot point. If reuse with SpaceX's landing method turns out a whole lot cheaper and faster than how Shuttle did it, easier may end up being the better thing to do! Why make anything more difficult than it needs to be? :/


 
"For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." R.P.Feynman

Offline mme

  • Full Member
  • ****
  • Posts: 887
  • Santa Barbara, CA, USA, Earth, Solar System, Milky Way Galaxy, Virgo Supercluster
  • Liked: 1057
  • Likes Given: 2396
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
It will be impossible until it's impractical followed by sure it's possible but totally unnecessary until it is easy and obvious and "anyone could have done it."  I can't wait to see the experimental attempts and have no idea if it will pan out.  But if it does pan out, people will update their Bayesian priors AND their recollection of their opinion on the matter.
Space is not Highlander.  There can, and will, be more than one.

Offline dglow

  • Full Member
  • ****
  • Posts: 712
  • California
  • Liked: 519
  • Likes Given: 1216
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?

Maybe not legless for the F9, but they could install four harness points on the landing surface for the leg tips to align with.

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
They will probably not do that on a drone ship since the orientation of the drone ship is determined by wave direction. F9 does not know anything about the current drone ship orientation, so thats not going to happen. Down to land landings.

On land, if F9 repeatedly lands on the correct spot and on the correct orientation, it might be possible. I dont think that they qualify a new F9 S1 version for this test. So maybe they could mount 4 V-shaped guiders for the lags. At the center, they could make a launch mount-like structure that closes automatically with the landing first stage. Can be made completely passive locking mechanism.

It sounds logically that they try this approach for F9 before going to BFR. I thought initially that concept of landing back at the launch mount is crazy. Much more crazy than on a drone ship. I will probably think differently after a hand full of successful bulls-eyes on land.

Offline Joel

  • Full Member
  • ****
  • Posts: 532
  • Madison, WI
  • Liked: 42
  • Likes Given: 41
The trajectory planning is resolved perhaps 100 times per second (educated guess) during the landing phase. That's what makes this problem so computationally challenging and why it's tractable only thanks to recently developed algorithms and software. Comparisons with other parts of the flight phase are irrelevant.

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
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?

Maybe not legless for the F9, but they could install four harness points on the landing surface for the leg tips to align with.

No guts no glory...

It's a learning exercise, it has to be similar.

And yes - for sure on land.

The cradle has to be comparable in size to the deployed legs, right?  And either be sparse enough for the flame to exit radially, or sit on a flame trench.  And since this is a learning exercise, I vote for a flame trench.

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.

ABCD - Always Be Counting Down

Online Semmel

  • Full Member
  • ****
  • Posts: 775
  • Germany
  • Liked: 521
  • Likes Given: 1677
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.

Ohh thats a great point! Yes, the maximum shift in X-Y at the base limits the landing error before the stage tips over. 0.5m might not be such a bad estimate there. A shift of 0.5m will introduce a significant shift and pendulum motion for sure. So the landing mount will have to arrest that  motion. I dont think a grable arm that takes the stage at the top is a viable concept. The running rocket motor will shake it violently. To catch the rocket and stop it from topping over, it would have to be very fast and, precise which would make it pretty nimble.

Remember, SpaceX wants to prove that return to the launch mount is possible. That means, no fancy technology at the experimental landing mount that would not be present at the launch mount as well. I dont think the TEL has the capability of grabbing the stage at the top and I dont think the launch table can move in X-Y to align it self with the incoming rocket. The launch clamps or similar devices have to do the catching and the landing will have to be precise enough so that the rocket does not bend itself apart or topple over.

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?

Offline dglow

  • Full Member
  • ****
  • Posts: 712
  • California
  • Liked: 519
  • Likes Given: 1216
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?

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?

Offline rsdavis9

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?

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?
bob

Offline LouScheffer

  • Full Member
  • ****
  • Posts: 1349
  • Liked: 1363
  • Likes Given: 173
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.
I think the full answer is:
(a) Is it possible to do powered landings with Shuttle computer power?  Yes.
(b) Can you implement state-of-the-art landing algorithms on Shuttle hardware?  No.

So you could do powered landing with old computers, but your performance and margins will suffer.

As John Smith points out, the direct calculation of the flight laws is not not very demanding:
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

But you also need a trajectory for the rocket to follow.  For launch, this is done on the ground with a powerful computer and software such as POST or ADDJUST.  Then the result is uploaded to the rocket, which just needs to follow the flight laws:
Quote
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.
There appear to be no fundamental barriers to extending this to booster landing.  The ground computers do the hard work, and the rocket computer follows the pre-computed trajectory, which is not very computationally demanding.

However, the state of the art for landing computations involves computing new optimal trajectories on the fly. This needed for autonomous landings on unknown terrain - for example, if as you descend, you see a rock where you want to land.   However, it will also increase your margins even on an obstacle-free landing to a known location, since every time you solve, you are using known (not estimated) data up to that point.  This can include measured vehicle performance, observed winds (on the way up, instead of 2 hours old from balloons), status of consumables, non-functional actuators, and more.

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:
Quote
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.
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.

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
Why would you need more propellant? It is the same, or better, landing profile.

------

Anyway, yes - the top nubs should be at the height of the CG. They should protrude further out, so that they engage first.

The rails they engage should slant inwards, until the rocket is centered. Then the bottom nubs, located at the thrust structure, should hit arresting slides that eat up the vertical velocity.

Since this mechanism is non-flying mass, these shock absorbers can have much longer travel, and dissipate more velocity, than the legs can.

This will allow more "slam".  More slam means better lateral precision, which is critical, since the system is not forgiving to a "miss".

We're talking hundreds and then thousands of landings, so it has to be better than 3 sigma good.


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?

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?
« Last Edit: 01/15/2017 06:58 PM by meekGee »
ABCD - Always Be Counting Down

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
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:
Quote
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.
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

Another data point. Historically update rates for LV's and the Shuttle have been about 50Hz IE 20ms a cycle. OTOH VTO is in some ways much more controlled that a vertical landing so I'm not sure if that's good enough for something this (relatively) unpredictable (like a deck of a landing barge on fairly heavy seas with a strong cross wind).
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline Joel

  • Full Member
  • ****
  • Posts: 532
  • Madison, WI
  • Liked: 42
  • Likes Given: 41
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

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.

Offline LouScheffer

  • Full Member
  • ****
  • Posts: 1349
  • Liked: 1363
  • Likes Given: 173
Optimization is a core part of SpaceX booster landings in a way that was not needed for Shuttle landings.  The main "consumable" on the Shuttle landings was cross range (or energy or altitude, take your pick).  Once in orbit, the Shuttle had 1100 nm available, and they never needed more than 813 nm.  They could always afford a conservative landing trajectory, the one with the highest margins.  There was no way to trade cross range for launch performance (this was fixed when the Shuttle was designed), and hence no incentive to push the landing performance to the limit of what the hardware could achieve.

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.

Offline Joel

  • Full Member
  • ****
  • Posts: 532
  • Madison, WI
  • Liked: 42
  • Likes Given: 41
Optimization is a core part of SpaceX booster landings in a way that was not needed for Shuttle landings. 
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.

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
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.
Exactly.
Quote
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.
Both factors which are critical to making this work.

BTW the cost of this process should not be underestimated. NASA estimated that all the mission planning stuff around Shuttle was about 1/3 of the whole cost of a launch.

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. Not a problem as long as the system is fast enough.  It's very impressive.
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.
True. 

The long range goal in all this is to understand the vehicle dynamics well enough that you can consistently reduce the landing ellipse for the current level of reserve fuel. At that point you can safely remove some of that reserve and return it to payload.
This. It's also a radically different control problem.
True.
Quote
A glider like the Shuttle is a well-behaving and stable system. A rocket under power is the very opposite of that.
It's not quite that black and white.

Large commercial aircraft are usually built to be trimmable in level flight. Shuttle was not stable. IIRC the SSME's at the back put the Cg behind the Cp, making it unstable without continuous control movements. No human could react fast enough or precisely enough to make these, which is one reason there is no mechanical backup to the flight controls (making the landing scenes in "Space Cowboys" hilarious rather than heroic).

That said unstable (military) aircraft were starting to come in when Shuttle was in development (IIRC the F16 was an early example) so a knowledge base was being built up to do this.

In contrast vertical landing a high aspect ratio (relatively) low stiffness structure was pretty much unknown before SX started development. There's a reason all those Philip Bono SSTO concepts looked kind of squat.
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
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.

And Spacex didn't do it in one launch.  It was able test incrementally to find what propellant was needed for each flight phase and also went as far as stretching the booster to increase propellant available.
« Last Edit: 01/17/2017 09:15 AM by Jim »

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 30297
  • Cape Canaveral Spaceport
  • Liked: 8570
  • Likes Given: 274
A glider like the Shuttle is a well-behaving and stable system.

Wrong.  Gliding is only applicable for the last few minutes of flight and the Orbiter is not a stable vehicle.  Also, conveniently ignoring "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."
« Last Edit: 01/17/2017 09:14 AM by Jim »

Offline Joel

  • Full Member
  • ****
  • Posts: 532
  • Madison, WI
  • Liked: 42
  • Likes Given: 41
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.
Yeah. To the extent that estimates of local wind conditions are actually fed into the controller (that's a toss-up for me), they are probably obtained from some sort of state estimator, most likely a Kalman filter. If they felt like being really fancy, they could have used CVXgen for this as well, posing the state estimation as an optimization problem. But I doubt that they actually did that.

Online spacenut

  • Full Member
  • ****
  • Posts: 1722
  • East Alabama
  • Liked: 187
  • Likes Given: 148
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. 

Online meekGee

  • Senior Member
  • *****
  • Posts: 7168
  • N. California
  • Liked: 3596
  • Likes Given: 739
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.
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..


ABCD - Always Be Counting Down

Offline john smith 19

  • Senior Member
  • *****
  • Posts: 5158
  • Everyplaceelse
  • Liked: 636
  • Likes Given: 3392
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. 
Indeed. However the fact that SX needed grid fins on the 1st stage to make it possible suggests that all such studies were very shallow and did not realize the true complexity of the task.

Likewise I think the experience with the Shuttle SRB's showed it was simpler to float them nose up. Getting something that's nose light to land nose down is difficult.
"Solids are a branch of fireworks, not rocketry. :-) :-) ", Henry Spencer 1/28/11  Averse to bold? You must be in marketing."It's all in the sequencing" K. Mattingly.  STS-Keeping most of the stakeholders happy most of the time.

Online tdperk

  • Member
  • Posts: 70
  • Liked: 13
  • Likes Given: 4
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..

And they have invented the hardware which (or an approach to hardware which) at least potentially permits refueling and reuse as opposed to remanufacturing and reuse.

Offline FutureSpaceTourist

  • Senior Member
  • *****
  • Posts: 2154
  • UK
    • Plan 28
  • Liked: 1358
  • Likes Given: 527
As background to the CRS-10 landing success, Quartz has just posted an article talking about Lars Blackmore's work on precision landing from JPL 10 years ago to SpaceX today:

Quote
SpaceXís self-landing rocket is a flying robot thatís great at math

https://qz.com/915702/the-spacex-falcon-9-rocket-you-see-landing-on-earth-is-really-a-sophisticated-flying-robot/

Tags: