And that is what I find fascinating. Weekly launches into even low earth orbit is a tremendous capability to lob stuff up there. I do look forward to the Dragon2 tests, and the next F9R landing attempt.
Falcon 9 v1.1 is almost certainly safer than the Titan II Gemini Launch Vehicle. As with prior Dragon flights, humans could have flown and been just fine.
Of note, there is an Earth observation instrument, RapidScat, being carried in the Dragon's trunk, which will be (has been?) plucked off the capsule by operators on the ground. This one measures wind. Another, called CATS, will be similarly deployed on the outside of the ISS in December-ish; it will measure clouds and aerosols.
These are part of a collection of low-cost (well, lower than a full satellite) Earth observation instruments to take advantage of the external mount points on the ISS. NASA recently had a media briefing about this: http://www.nasa.gov/press/2014/september/nasa-hosts-media-br...
Is it common to use metric system when launching rockets to space or is it a peculiarity of SpaceX? I heard the speaker on SpaceX channel always referring to kilometers and kilometers per second when talking about height and speed.
It's common for pretty much all of engineering really. It's ludicrous to make calculations a bit more complicated by using weird non-SI units.
The fact that NASA managed to crash a probe into Mars because they hadn't yet learned the lesson says it all really. Just use SI units and stop worrying about it.
It's Lockheed Martin that still insists on using imperial units instead of SI, even after the loss of mission that confusion caused in their work with metric-using JPL on Mars Climate Orbiter.
No, the important lesson is to always label your units, and another one might be to always be careful passing dimensionful numbers between codes and teams. You can run into the same problem by accidentally even forgetting to convert between, e.g., newtons and millinewtons.
That is precisely the policy adopted by NASA, and it lead to the Mars disaster, so you are suggesting as a solution the exactly policy that caused the problem.
Furthermore, you are suggesting that the same entities--highly trained engineers and scientists and project managers--that proved inadequate to follow the policy you are suggesting last time can somehow be expected to follow the policy correctly at all times in the future.
Reducing needless complexity--in this case by enforcing a standard of common units so that when the inevitable inevitably occurs and someone forgets to label things--there is a much reduced (but still non-zero) chance of undetected mis-matches occurring.
Furthermore, it is very difficult to confuse milli-newtons with newtons even if a project was for some reason using both, because they differ by three orders of magnitude, which tends to get noticed. Whereas kilograms and pounds differ only by a factor of 2.54, which might be--and in fact has been--missed.
Are you seriously claiming that a policy of labeling and
testing units caused MCO to be lost?
Have you actually studied the mishap? If labeling and verifying the units was done carefully it would have prevented the accident.
A millinewton/newton mix-up could easily occur in a case like this one, too. The particular numbers which were misinterpreted in MCO's case were often small, and I can easily believe no one noticing similar ones being a few orders of magnitude off. (I do have a hard time imagining it with MCO's particular numbers, though.) Similarly, you can be bitten by a meters/centimeters switch or accidentally using different representations of the same quantity, such as specific impulse and its corresponding characteristic exhaust velocity, which only differ by a factor of about 10 when both are expressed in SI units.
I maintain that the key lesson is to always label your units, and to test them carefully and routinely, including at interfaces. I believe that claiming that using English units (as gross as they often are) caused the failure misses the more fundamental root problem.
(Also, I'm not claiming that labeling and verifying units is easy. I emphasize it partly because it's hard. Little of our current software ecosystem includes any concept of dimensionful numbers.)
SI units don't include millinewtons, so the problem wouldn't arise. That's part of the point.
You measure mass in kg, not g, not tonnes.
You measure distance in metres. Not kilometers. Not nautical miles.
You measure time in seconds.
A Newton is a derived SI unit — 1 kg m / s^2
Incidentally, this is why engineering notation works the way it does. You pick your units and you get the significant figures from the mantissa and the descriptive prefix (giga, nano, micro, kilo, etc.) from the exponent.
Also, remember, people are representing these numbers on computers. Derived units are very useful—in fact they are often critical to achieving necessary accuracies using compact representations. Further, representing quantities in terms of other unique, problem-specific units is often extremely helpful for ensuring good numerical behavior.
Tloewald's point was that microseconds and nanoseconds are not SI base units, so standardizing on base units eliminates the ambiguity (the second alone is the SI base unit of time). Of course additional mechanisms of double and triple checking are probably still warranted to account for human fallibility.
It's common in science in general to use Metric and not Customary. NASA is a/the notable hold out. Engineering is sometimes done in customary because of contracts and such, especially when dealing with government agencies.
While I love Customary volumes (powers of 2 base units), the rest could stand a change and am glad SpaceX is using Metric.
Consider too that a lot of aerospace stuff is done in collaboration with other countries. No one wants to be converting vyorsts to hogsheads all the time.
Whenever I see ISS dockings I wonder why the arm isn't computer controlled. There's no specific information on this page but I'm assuming it was a manual docking. Can anyone explain why the process is still manual?
The cynical part of me thinks because manned spaceflight, at least in the context of being stuck in a LEO tin can, is of questionable utility and we try to find things for people to do? We can automate quite a bit of this, in fact, the ESA's Automated Transfer Vehicle just docks itself. Wikipedia:
At a distance of 249 m, the ATV computers use videometer and telegoniometer data for final approach and docking manoeuvres. The actual docking to Zvezda is fully automatic. If there are any last-minute problems, a pre-programmed sequence of anti-collision manoeuvres, fully independent of the main navigation system, can be activated by the flight engineers aboard the station.
Or what's that apocryphal story about early astronauts fighting with NASA engineers to put in pilot controls with manual override so these guys could claim to be pilots and not mere passengers? The ugly truth is a lot of this stuff is best left to automation, robots, etc.
In the Shuttle, the landing gear control was intentionally left outside computer control so that the vehicle could not be flown unmanned. Flight control software could autoland the shuttle from orbit, but it took a human being to let the wheels down. So I don't think your cynicism is excessive.
Towards the end of the program, a "jumper cable" was carried to get around that:
The cable would connect an avionics bay in Discovery's middeck with the
controls one level up on its flight deck, effectively allowing flight
controllers in Houston to perform landing activities currently done by
shuttle astronauts.
Those manual activities include starting the shuttle's auxiliary power units,
deploying an air data probe, unstowing the orbiter's landing gear and
releasing its drag chute after landing, Herring said.
Best described as a scaling problem with manual or prototype, vs automated.
Lets say you need a prototype ability tool and die maker machinist on staff to handle "things" during development. And you need a simple piece of threaded rod. You could blow a lot of extra time and money on getting a CNC programmer and the software and a numerically controlled lathe or machining center dropped in to make that boring simple little piece of threaded rod. Or you could say, "dude, I know this is beneath your skill, but you're just sitting there burning oxygen and it'll only take ten minutes for you to machine a piece of threaded rod, so ..."
If you have a tool that's designed to do anything, and the tool and op are just sitting there, even if you could automate a one-off, the overall system cost and productivity is higher if the op just does it by hand.
If you have a VERY active schedule, and maybe 3 simultaneously operating 24x7 arms all over the station with only one dude available to run all the arms and everything at 150% of designed thruput capacity etc, then it would make economic sense to automate this task so the arm op can work on something more human oriented, but ...
I bet the trainers that certify an astronaut is precise enough to get it done are a lot cheaper than the engineers required to certify a computer wouldn't karate chop the station.
The arm almost certainly has a control system that can resolve that. Since humans suck at higher order control, the arm almost certainly has a control system that takes the operator's desired output (which will be a series of joint angles), and converts into the required motor torques. In this process, the control system almost certainly also does sanity checks to prevent self-intersections, collision with the space station, overtorqeuing the motors, and etc.
Replacing the human with a computer program therefore likely doesn't literally involve verifying that it will not karate chop the station - lower level control will take care of that for you.
However, as anyone who has worked with robot manipulators before, actually getting good performance out of them in variable environments (ie, not a controlled factory assembly line) is quite a bit of work - work that probably isn't worth it.
considering the first flight where they were rewriting code while it sat outside the station; reconfigured the LIDAR on the fly; I would put it down being overly cautious, maybe a bit of fear? Let us be honest, with all the difficulty of getting that module into space docking isn't that big of a deal. If there were no people on board no one would care.
Plus I have to ask, if a thruster suddenly misfires or goes haywire who is going to be faster? In Apollo days I would put odds on the astronauts, today - I am betting on a computer. We will sooner trust a car to drive itself before we allow a freighter to dock with a space station.
In fact the arm can be remotely controlled. As of 2005[1] ground controllers can uplink sequences of commands for the arm to complete. According to an article[2] about this Dragon launch, DEXTRE (two-armed human-like remote manipulator) will be remotely commanded to unpack cargo from the Dragon's unpressurized trunk and mount it on the station. I believe this is not a new thing at all.
It stays on the ISS while it is emptied and loaded for the return trip. Dragon is the only vehicle with a substantial down mass capability (3000kg) so it can return with things that need fixing and completed experiments etc. Shuttle is retired and Progress, ATV, HTV and Cygnus are one way trips so only good for taking out the garbage. Soyuz is full of people.
They set Dragon free with the arm, Dragon departs, does a de-orbit burn, jettisons the trunk (with the solar arrays), re-enters the atmosphere and parachutes down into the ocean and is recovered.
Although the Dragon is reusable, SpaceX's contract with NASA stipulates that new capsules be used for each resupply mission. Not sure if the contract allows SpaceX to refurbish the capsules for other commercial missions, but the other CRS Dragons are being used for showpieces at the moment.
Interesting - I didn't know that. Do you know if this is due to NASA being general cautions with a new, relatively unproved vehicle? Or is it a condition of human-rating the Dragon?
NASA was unwilling to believe any discount offered for use of a refurbished spacecraft until they'd actually done it, so the bid was made on the basis of a new capsule for each mission.
(The human-rated Dragon is going to be a different version anyway, with altered docking support, much beefier propulsion, altered solar panels, and of course, internal controls and life support. Current plan is new spacecraft permission there, too, though, perhaps for the same reason.)
Please don't comment on HN like you would on Reddit. If you don't have questions or information to add to the thread, you should probably use that as a cue to refrain from posting.
Joke posts might not seem bad, but in aggregate they lower the signal to noise ratio we have come to appreciate about HN. Additionally, once these kinds of jocular posts start, it becomes infectious.
I'm not trying to be mean; I'm guilty of making posts like this too. Many of us simply do not want to see HN devolve into the equivalent of a spammy subreddit. It's important that we all remind each other of the value of this community so that we can protect it from spiraling into a bad state.
The reason why hacker news is good is because it remains serious.
It's important to remember that Hacker News is not a democracy. There isn't a voting system so people can democratically decide what content is good or bad. Rather, Hacker News is a dictatorship, controlled by Paul Graham and the Y Combinator. Within this space, the Y Combinator has absolute control over all content.
In a democratic system like Reddit, there might be objections to changing the titles or shadowbanning trolls (reddit does shadowban, but mods can't shadowban people for disturbing the quality of a subreddit). On Hacker News, these features are welcomed because they raise the quality of discourse.
Your only choice when it comes to hacker news is to stay and be a productive member, or leave. You are free to leave. Nobody is forcing you to stay here. The source code for Hacker News is even publicly available; if you want to make Joker News you're free to do so.
In this way, Hacker News circumvents tyranny of the majority in favor of quality of content. (I suspect that it also has to do with the Y Combinator's libertarian politics -- Hacker News is an excellent example of what the world could be like it if were organized into voluntary units with absolute internal control, but free choice and movement between those units.)
