Station Crew Docks Dragon Capsule to ISS(nasa.gov) |
Station Crew Docks Dragon Capsule to ISS(nasa.gov) |
SpaceX plans to beat that record soon with launches a week apart becoming routine.
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...
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.
While I love Customary volumes (powers of 2 base units), the rest could stand a change and am glad SpaceX is using Metric.
http://upload.wikimedia.org/wikipedia/commons/thumb/a/ab/Met...
Do they push it back to earth? Into space, leave it in orbit?
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.
[1] http://www.nasa.gov/content/expedition-41-trio-waits-for-dra...
[2] http://www.spaceflight101.com/dragon-spacecraft-information....
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.
http://en.wikipedia.org/wiki/Automated_Transfer_Vehicle
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.
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 ...
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.
Even though it might be possible to 'computerize' the control, realistically there's no benefit to doing so.
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.
[1]: http://www.space.com/1033-remote-access-canadarm-2-hand-grou...
[2]: http://spaceflightnow.com/falcon9/013/140923arrival/#.VCHgLy...
http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_...
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.
(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.
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.)
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.
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.)
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.
http://en.wikipedia.org/wiki/Buran_%28spacecraft%29#Flight_i...
Buran was an amazing piece of technology. It's sad it didn't get its chance.
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.
[1] http://www.space.com/2560-shuttle-carry-tools-repair-remote-...I'm confused. Comments have up/down voting, and posts have up voting and flagging.
> 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.
I've seen both people posting "you're hellbanned and it doesn't look warranted" and productive, moderator-accepted complaints about changing titles.
The voting system exists so that the community can raise productive comments, and lower unproductive comments. It's impossible for Paul Graham himself to come to every thread and say which comments are good and bad. We have to help how we can.
>I've seen both people posting "you're hellbanned and it doesn't look warranted" and productive, moderator-accepted complaints about changing titles.
The Y Combinator is reasonable, and human. It has a set of rules it attempts to operate by, but human agents occasionally violate their own rules. Ultimately, all decision-making authority rests with them, not the community.
But the fact they exist is difference enough to demonstrate my point.
The Air Force's shuttle is actually autonomous not just automated. Its, say, more like a drone than a R/C car. Its many steps ahead of what the US and the USSR were doing in the 80s. From what we know its a very interesting technical achievement.Over 600 days in space for a spacecraft is pretty impressive also.
>OTV-3 had spent 600 days in orbit by 8 August 2014
http://en.wikipedia.org/wiki/Boeing_X-37
I don't know why this metric isn't mentioned more often. This this is practically launch and forget, give occasional orders to, and land once in a while sci-fi spacecraft. From an intel point-of-view this is pretty much a spy satellite that can go anywhere in orbit, change its mission at any time, and then land and go back at any time. It may also have anti-satellite weapons. I guess we won't know its full capabilities until its declassified, but from what we know its a very interesting project from a technical achievement point of view.
Check out this article: http://techcrunch.com/2014/03/29/after-stepping-aside-from-y...
Also, your comment was still allowed to post.
There are plenty of applications where it makes sense to do something different because you need to accommodate special hardware (e.g. FPGAs), because you want a different representation density/range, or because external policy effectively dictates the most natural format (e.g. finance). But in the absence of a pressing concrete reason to ditch 754 floats, they are BY FAR the best option for high performance, reproducible, portable, debuggable math with abundant documentation and pre-existing pools of expertise. They're far from trivial but so is the fixed-point code you would replace them with.
If someone couldn't be bothered to learn the relevant intricacies of IEEE754, why do you expect them to do a better job re-implementing the stuff on top of integer math (or picking apart the in-house attempt to do so)? Shifting from problems of the "intern forgot to reset the rounding mode" variety to the "Newton's method code erroneously terminates one cycle too early if the last bit is a 1" variety hardly seems productive.