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.
That's fine until you start using floating point values in order to satisfy this SI fetish. (I guess you like farads and henries too.) It's much better to use fixed point and keep track of your multiplier. A sufficiently advanced type system could do this, but at some point it will require careful thinking about precision.
Floating point is treated differently by compilers, involves different components of the processor, generates different types of errors, and has different performance. Perhaps there is some perspective from which that proposition is true?
A perspective where one is more familiar with IEEE754 than your in-house custom fixed-point implementation of choice?
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.
I won't cover the ground the other response covered (implementing your own fixed point because IEEE754 isn't good enough for you is ... nutty) but the issue here is using daft units vs. using SI units, and the thinner and thinner straws people clutch at to claim that using SI units isn't simply better. Good grief.
Yes but you eliminate errors when working within a type of unit. NASA's problem came from converting one kind of length to another. You are clutching at straws here.
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.
Except automation in spaceflight was a solved problem long ago. The Buran had more automation than the STS because of US politics in regard to the STS than some major innovation. In fact, the Buran is the poster-boy of lack of innovation. Its just a slightly souped up COPY of the STS long after the STS was in production. This like calling a 2014 Kia that looks like a 2003 Mercedes innovative because it has the option for a bluetooth stereo.
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
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.
I was only being sort of half serious but this thing is amazing, I remember seing amature satelite spotted _photograph_ this thing in orbit on its top secret mission. Glad to know more about it.
I think that was meant mostly as a compliment. Both trying everything and doing the right thing are rare enough behaviors, even by themselves. We should strive to be as good as we were, when he said that.
From an algorithmic point of view, you could rephrase it as "You can always count on Americans to pick the optimal solution by brute-forcing through the entire search space".
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.)
> There isn't a voting system so people can democratically decide what content is good or bad.
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.
>I'm confused. Comments have up/down voting, and posts have up voting and flagging.
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 voting system exists so that the community can raise productive comments, and lower unproductive comments" sounds like "a voting system so people can democratically decide what content is good or bad". What's the distinction you're trying to make?
I accidentally downvoted you when attempting to pinch-zoom on my phone. I'm sorry! I didn't mean to make that mistake. I wish we had the feature to undo things like that.
