The SmallSat Launcher War

Over the last decade or so the definition of what a ‘small satellite’ is has ballooned beyond the original cubesat design specification to satellites of 50 or 100 kg. Today a ‘smallsat’ is defined far more around the cost, and sometimes the technologies used, than the size and shape of the box that goes into orbit.

There are now more than fifty companies working on launch vehicles dedicated to lifting these small satellites into orbit, and while nobody really expects all of those to survive the next few years, it’s going to be an interesting time in the launcher market. Because I have a sneaking suspicion that Jeff Bezos’ statement that “there’s not that much interesting about cubesats” may well turn out to be the twenty first century’s “nobody needs more than 640kb,” and it’s possible that everybody is wrong about how many of the launcher companies will survive in the long term.

Continue reading “The SmallSat Launcher War”

Steve Collins: When Things Go Wrong In Space

[Steve Collins] is a regular around Hackaday. He’s brought homebrew LIDARs to our regular meetups, he’s given a talk on a lifetime’s worth of hacking, and he is the owner of the most immaculate Hackaday t-shirt we’ve ever seen.

For the 2016 Hackaday SuperConference,  [Steve] took a break from his day job of driving spacecraft around the Solar System. As you can imagine, NASA plans on things going wrong. How do you plan for that? [Steve] answers all your questions by telling you what happens when things go wrong in space.

Continue reading “Steve Collins: When Things Go Wrong In Space”

Fail of the Week: NASA Edition

There’s a reason we often use the phrase “It ain’t Rocket Science”. Because real rocket science IS difficult. It is dangerous and complicated, and a lot of things can and do go wrong, often with disastrous consequences. It is imperative that the lessons learned from past failures must be documented and disseminated to prevent future mishaps. This is much easier said than done. There’s a large number of agencies and laboratories working on multiple projects over long periods of time. Which is why NASA has set up NASA Lessons Learned — a central, online database of issues documented by contributors from within NASA as well as other organizations.

The system is managed by a steering committee consisting of members from all NASA centers. Public access is limited to a summary of the original driving event, lessons learned and recommendations. But even this information can be quite useful for common folks. For example, this lesson on Guidance for NASA Selection & Application of DC-DC Converters contains several bits of useful wisdom. Or this one about IC’s being damaged due to capacitor residual discharge during assembly. If you ever need to add a conformal coating to your hardware, check how Glass Cased Components Fractured as a Result of Shrinkage in Coating/Bonding Materials Applied in Excessive Amounts. Finally, something we have all experienced when working with polarized components — Reverse Polarity Concerns With Tantalum Capacitors. Here is a more specific Technical Note on polarized capacitors (pdf): Preventing Incorrect Installation of Polarized Capacitors.

Unfortunately, all of this body of past knowledge is sometimes still not enough to prevent problems. Case in point is a recently discovered issue on the ISS — a completely avoidable power supply mistake. Science payloads attach to the ISS via holders called the ExPRESS logistics carriers. These provide mechanical anchoring, electrical power and data links. Inside the carriers, the power supply meant to supply 28V to the payloads was found to have a few capacitors mounted the other way around. This has forced the payloads to use the 120V supply instead, requiring them to have an additional 120V to 28V converter retrofit. This means modifying the existing hardware and factoring in additional weight, volume, heat, cost and other issues when adding the extra converter. If you’d like to dig into the details, check out this article about NASA’s power supply fail.

Thanks to [Jarek] for tipping us about this.

The First Bug On Mars

Interplanetary probes were a constant in the tech news bulletins of the 1960s and 1970s. The Space Race was at its height, and alongside their manned flights the two superpowers sent unmanned missions throughout the Solar System. By the 1980s and early 1990s the Space Race had cooled down, the bean counters moved in, and aside from the spectacular images of the planets periodically arriving from the Voyager series of craft there were scant pickings for the deep space enthusiast.

The launch in late 1996 of the Mars Pathfinder mission with its Sojourner rover then was exciting news indeed. Before Spirit, the exceptionally long-lived Opportunity, and the relatively huge Curiosity rover (get a sense of scale from our recent tour of JPL), the little Sojourner operated on the surface of the planet for 85 days, and proved the technology for the rovers that followed.

In these days of constant online information we’d see every nuance of the operation as it happened, but those of us watching with interest in 1997 missed one of the mission’s dramas. Pathfinder’s lander suffered what is being written up today as the first bug on Mars. When the lander collected Martian weather data, its computer would crash.

Like many other spacecraft, the lander’s computer system ran the real-time OS VxWorks. Of the threads running on the craft, the weather thread was a low priority, while the more important task of servicing its information bus was a high priority one. The weather task would hog the resources, causing the operating system equivalent of an unholy row in our Martian outpost. A priority inversion bug, and one that had been spotted before launch but assigned a low priority.

You can’t walk up to a computer on another planet and swap out a few disks, so the Pathfinder team had to investigate the problem on their Earthbound replica of the lander. The fix involved executing some C code on an interpreter prompt on the spacecraft itself, something that would give most engineers an extremely anxious moment.

The write-up is an interesting read, it’s a translation from a Russian original that is linked within it. If the work of the JPL scientists and engineers interests you, this talk from the recent Hackaday superconference might be of interest.

[via Hacker News]

Extra Curricular Tour of NASA’s Jet Propulsion Laboratory

Last week, Hackaday had the chance to tour NASA’s Jet Propulsion Laboratory (JPL) in Pasadena, California. Tours are given all the time at JPL, but ours was special. Steve Collins invited us, and acted as our tour guide, and a new friendship with Michelle Easter got us a look inside the labs where equipment for the 2020 Mars mission is being built.

Continue reading “Extra Curricular Tour of NASA’s Jet Propulsion Laboratory”

That NASA EM Drive Paper: An Expert Opinion

A week or two ago we featured a research paper from NASA scientists that reported a tiny but measurable thrust from an electromagnetic drive mounted on a torsion balance in a vacuum chamber. This was interesting news because electromagnetic drives do not eject mass in the way that a traditional rocket engine does, so any thrust they may produce would violate Newton’s Third Law. Either the Laws Of Physics are not as inviolate as we have been led to believe, or some other factor has evaded the attempts of the team to exclude or explain everything that might otherwise produce a force.

As you might imagine, opinion has entrenched itself on both sides of this issue. Those who believe that EM drives have allowed us to stumble upon some hitherto undiscovered branch of physics seized upon the fact that the NASA paper was peer-reviewed to support their case, while those who believe the mechanism through which the force is generated will eventually be explained by conventional means stuck to their guns. The rest of us who sit on the fence await further developments from either side with interest.

Over at they have an interview from the University of Connecticut with [Brice Cassenti], a propulsion expert, which brings his specialist knowledge to the issue. He believes that eventually the results will be explained by conventional means, but explains why the paper made it through peer review and addresses some of the speculation about the device being tested in space. If you are firmly in one of the opposing camps the interview may not persuade you to change your mind, but it nevertheless makes for an interesting read.

If EM drives are of interest, you might find our overview from last year to be an illuminating read. Meanwhile our coverage of the NASA paper should give you some background to this story, and we’ve even had one entered in the Hackaday Prize.

Hacking Your Way Through NASA

The 2016 Hackaday SuperConference took place last month in sunny Pasadena, California. Also calling Pasadena home is the Jet Propulsion Laboratory, the place where Mars rovers are built, where probes are guided around the solar system, and where awesome space stuff happens.

JPL had a large contingent at the SuperCon and two of them teamed up to present their talk: Charles Dandino and Lucy Du. Lucy is a mechatronics engineer at JPL and already has a little bit of fame from fielding a Battlebot in the last two seasons of ABC’s series. Charles is also in mechatronics, with experience with Curiosity, the Mars 2020 rover, and the (hopefully) upcoming asteroid redirect mission.

In their talk, Charles and Lucy uncovered some of the hacks happening in the background at JPL. There’s a lot of them, and their impact goes much further than you would expect. Everything from remote control cars to keeping spacecraft alive on the other side of the solar system.

Continue reading “Hacking Your Way Through NASA”