The eight programs used during a typical mission average about 75 percent CPU utilization for most flight regimes, which leaves us well within the capability of this machine. Very early on in the development phase, we did have some trouble with excessive CPU utilization. We went through a very detailed scrub of the software requirements and the code to achieve the CPU utilization we have today.
How about the Shuttle? According to The Space Shuttle Primary Computer System, the Shuttle computer was about 75% busy, which already took considerable optimization:QuoteThe eight programs used during a typical mission average about 75 percent CPU utilization for most flight regimes, which leaves us well within the capability of this machine. Very early on in the development phase, we did have some trouble with excessive CPU utilization. We went through a very detailed scrub of the software requirements and the code to achieve the CPU utilization we have today. Given that rocket landings are several times more fast paced than Shuttle landings, the Shuttle computers seem marginal for this job. Interestingly, the Delta RIFCA computers seem about an order of magnitude faster than the Shuttle computers, and probably have the compute horsepower for the job. However, other aspects of the system they are embedded in seem to hobble them quite severely, since they can't even accomodate yaw steering, which Titan, Apollo, and the Shuttle could do.
With some time to think about what you said, I might have a clue what you are getting at.I dont remember where I heard that from and I dont find the source, but shuttle was designed to catch a satellite and carry it back to earth for analysis. The satellite didnt necessarily have to be operational for that capture operation or cooperative for that matter (i.e. the requirement was to be able to capture a Russian spy satellite, it was cold war after all). I dont know if that capability was ever used, but I think to remember that this was a requirement by the air force to the space shuttle. Therefore, it needed the capability to rendezvous and "dock" with a non-cooperative target.
Exactly. It was THE major problems that had to be solved by the folks of ConXpress (and other orbital recovery projects in the early 2000's): How to rendez-vous and dock with an uncooperative target? There is some good documentation out there about that particular problem. And it confirms what Jim has been stating for the past few days.
Doesnt the ASDS or the landing pad qualify as an "uncooperative" target? It's stationary ok but it's not exchanging any data with the vehicle just like the ISS.
Quote from: Jim on 01/12/2017 04:29 pmIt is part of the conversion because it is hard. "Uncooperative" means it doesn't have any interaction with the chaser spacecraft.Except that does not apply to ISS IIRC. All contract winners had to provide systems to ISS to allow it to stop the berthing (not docking so far that will be for CRS2) QuoteThat is what autonomous robotic servicing spacecraft will have to do. They will have approach a spacecraft that is not designed for routine rendezvous and docking. It will have to use onboard sensors to find the target spacecraft and then will have to find an area such as the launch adapter as a mating point. True, but that's not a description of what happens (and what did happen with Shuttle) WRT ISS.
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.
Next, in rendezvous the control inputs are largely orthogonal. Designers explicitly build in combinations of thrusters that do a single operation - three types of translation, and three types of rotation.
Next, rendezvous is almost completely insensitive to modelling and performance errors. If your performance is worse than you expect, or your estimated mass is wrong, it still works fine. This is because you perform each maneuver by thrusting in the desired direction until the IMU tells you that you have the correct delta V. This technique has saved many missions where the rocket performance was less than expected.
But for landing, your model needs to be precisely correct. If you are at 100 meters, and sinking with rate X m/s, there is one and only one acceleration that will bring you to zero speed at zero altitude. If your model (or your hardware) is wrong, and you get any less (or more) acceleration, it's a bad day.
Quote from: Jim on 01/10/2017 05:54 pmQuote from: dglow on 01/10/2017 05:49 pmNo.Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.How do you know that?
Quote from: dglow on 01/10/2017 05:49 pmNo.Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.
No.
Quote from: kevinof on 01/12/2017 05:12 pmDoesnt the ASDS or the landing pad qualify as an "uncooperative" target? It's stationary ok but it's not exchanging any data with the vehicle just like the ISS.Its location is known and programmed into F9
Quote from: Semmel on 01/10/2017 06:09 pmQuote from: Jim on 01/10/2017 05:54 pmWrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.How do you know that?He doesn't. His experiences lead his to certain biases.Consider the matter, if you are on top of a 4 story building, and you have a hang glider and a pogo stick with a brake, and your task is to land safely--which do you want to use?The Shuttle is the glider.The Falcon is the pogo stick.
Quote from: Jim on 01/10/2017 05:54 pmWrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.How do you know that?
Wrong, the ability to fly autonomously from orbit to runway landing is actually more difficult than autonomous RTLS and hoverslam landing.
1. Please dont speak for Jim. I dont know who you are but speaking for Jim is just asking for trouble. You can be lucky if your post is not deleted. I would hive it a dislike if that would exist.2. I am not looking for an analogy. I am looking for hard, cold, engineering reasoning. Its always harder than you think. LouScheffer gave some good insight. But thats probably all we can get.3. Lar gave us a shot in front of our metaphorical bow. If we continue with the "I know better than you what is more difficult", posts get deleted. Arguments get hurt and ultimately, threads get closed. So I would very much appreciate to get back on topic and discuss the challenges of landing falcon first stages. Discussing whats more difficult is not helpful.4. The initial question "why wasnt booster landing done before?" got answered way back: The solution was not interesting enough for the rocket builders of the past. It had nothing to do with the difficulty of the job, far less with being impossible for the computer hardware. It might have been impossible, but it was not tried so we will not know.
He doesn't. His experiences lead his to certain biases.
GPS has become so ubiquitous that people don't seem to be able to consider navigation problems without it. It makes life simple but I don't believe it's essential.
One of the old timers at work was giving a presentation last year, and in discussing the present-day work on the problem of collaborative swarm navigation of autonomous vehicles[e.g.] while GPS-denied in the presence of enemy jamming, he noted that before the 90's, ALL navigation was "GPS-denied."
Or maybe I should say velocity sensors, since the barge position is not only uncertain in seas but it's rate of movement in all directions is constantly changing.
Quote from: JamesH65 on 01/12/2017 08:31 amI'm a software engineer, just looking at the problem from where I am, docking is an easier SW problem than landing the F9 booster. Call it intuition, since you seem to accept that as valid.That is because you don't understand orbital mechanics. It is not just docking, it is rendezvous. The landing spot for F9 never changes, the vehicle's attitude at landing is the same.
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.
The flight path back to the it [landing spot] is never out of plane.
Quote from: Nomadd on 01/14/2017 03:53 pmOr maybe I should say velocity sensors, since the barge position is not only uncertain in seas but it's rate of movement in all directions is constantly changing. I reckon that's a benefit of the hoverslam - everything is over before the barge has a chance to move much. Sent from my iPhone using Tapatalk