Halloween is looming, and [Jonathan Gleich] decided that an ideal centerpiece would be a flame-spitting dragon’s head. It started with an economical wall-mount dragon’s head, combined with a variety of off-the-shelf components to become something greater.
The fire comes from a kind of propane torch sold as a weed killer set, which looks a little like a miniature tiger torch. The flow of propane is limited by a regulator (which keeps the flame short and fixed), and controlled with a gas-rated 12 V solenoid valve. Ignition is done with the help of a spark igniter that fires up on demand, fed by a high-voltage ignition coil. The two combine at the Dragon’s mouth, where the flame originates, but the electrical components are otherwise isolated from the gas elements as much as possible.
The dragon head is made of acrylic, and if exposed to enough heat acrylic will first melt, then burn. To help avoid a meltdown, the dragon breathes fire only intermittently. [Jonathan] also gave the mouth area a heat-resistant barrier made from generous layers of flame-blocking mortar and sealants from the hardware store. The finishing touch comes in the form of bright red LEDs in the eyes, which give the head a bit more life.
Watch the ignitor in action and see the head spewing flames in the two short videos embedded below. The head should make for some good pictures come Halloween, and is a good example of how repurposing off-the-shelf items can sometimes be just what is needed for a project.
SpaceX has always been willing to break from aerospace tradition if they feel there’s a more pragmatic solution. Today this is most visible in their use of standard construction equipment like cranes in their Starship development facility. But the same focus on problem solving can also be found in their software parts we don’t see. Recently we got two different views behind the scenes. First, a four-part series about “software in space” published by StackOverflow blog, followed quickly by an Ask Me Anything (AMA) session on SpaceX Reddit.
Some of the StackOverflow series cover ground that has been previously discussed. Mostly in the first part dealing with their workhorse Falcon and Dragon vehicles, and some in the second part discussing Starlink whose beta program is reaching more and more people. Both confirmed that spaceflight software has to meet very stringent requirements and are mostly close to the metal bespoke C++ code. But we receive fascinating new information in part three, which focuses on code verification and testing. Here they leverage a lot of open source infrastructure more common to software startups than aerospace companies. The fourth and final component of this series covers software to support SpaceX hardware manufacturing, which had been rarely discussed before this point. (Unfortunately, there was nothing about how often SpaceX software developers copy and paste code from StackOverflow.)
The recent Reddit AMA likewise had some overlap with the SpaceX software AMA a year ago, but there were new information about SpaceX work within the past year. There was Crew Dragon’s transition from a test to an operational vehicle, and the aforementioned Starship development program. Our comments section had a lot of discussion about the practicality of touchscreen interfaces in real spacecraft, and here we learn SpaceX put a lot of study into building something functional and effective.
It also showed us that essentially every Sci-Fi Movie Interface was unrealistic and would be unreadable under extreme conditions.
In the course of this research, they learned a lot of pitfalls about fictional touch interfaces. Though to be fair, movie and television spacecraft UI are more concerned about looking cool than being useful.
If the standard AMA format is not to your liking, one of the contributors compiled all SpaceX answers alongside their related questions in a much more readable form here. And even though there’s an obvious recruiting side to these events, we’re happy to learn more about how SpaceX have continued to focus on getting the job done instead of rigidly conforming to aerospace tradition. An attitude that goes all the way back to the beginning of this company.
When the Space Shuttle Atlantis rolled to a stop on its final mission in 2011, it was truly the end of an era. Few could deny that the program had become too complex and expensive to keep running, but even still, humanity’s ability to do useful work in low Earth orbit took a serious hit with the retirement of the Shuttle fleet. Worse, there was no indication of when or if another spacecraft would be developed that could truly rival the capabilities of the winged orbiters first conceived in the late 1960s.
While its primary function was to carry large payloads such as satellites into orbit, the Shuttle’s ability to retrieve objects from space and bring them back was arguably just as important. Throughout its storied career, sensitive experiments conducted at the International Space Station or aboard the Orbiter itself were returned gently to Earth thanks to the craft’s unique design. Unlike traditional spacecraft that ended their flight with a rough splashdown in the open ocean, the Shuttle eased itself down to the tarmac like an airplane. Once landed, experiments could be quickly unloaded and transferred to the nearby Space Station Processing Facility where science teams would be waiting to perform further processing or analysis.
For 30 years, the Space Shuttle and its assorted facilities at Kennedy Space Center provided a reliable way to deliver fragile or time-sensitive scientific experiments into the hands of researchers just a few hours after leaving orbit. It was a valuable service that simply didn’t exist before the Shuttle, and one that scientists have been deprived of ever since its retirement.
Until now. With the successful splashdown of the first Cargo Dragon 2 off the coast of Florida, NASA is one step closer to regaining a critical capability it hasn’t had for a decade. While it’s still not quite as convenient as simply rolling the Shuttle into the Orbiter Processing Facility after a mission, the fact that SpaceX can guide their capsule down into the waters near the Space Coast greatly reduces the time required to return experiments to the researchers who designed them.
Various outlets have mentioned Chromium in this context, but without answering the obvious follow-up question: how deep does Chromium go? In this AMA we learn it does not go very deep at all. Chromium is only the UI rendering engine, their fault tolerant flight software interaction is elsewhere. Components such as Chromium are isolated to help keep system behavior predictable, so a frozen tab won’t crash the capsule. Somewhat surprisingly they don’t use a specialized real-time operating system, but instead a lightly customized Linux built with PREEMPT_RT patches for better real-time behavior.
In addition to Falcon rocket and Dragon capsule, this AMA also covered software work for Starlink which offered interesting contrasts in design tradeoffs. Because there are so many satellites (and even more being launched) loss of individual spacecraft is not a mission failure. This gives them elbow room for rapid iteration, treating the constellation more like racks of servers in a datacenter instead of typical satellite operations. Where the Crew Dragon code has been frozen for several months, Starlink code is updated rapidly. Quickly enough that by the time newly launched Starlink satellites reach orbit, their code has usually fallen behind the rest of the constellation.
Finally there are a few scattered answers outside of space bound code. Their ground support displays (visible in Hawthorne mission control room) are built with LabVIEW. They also confirmed that contrary to some claims, the SpaceX ISS docking simulator isn’t actually running the same code as Crew Dragon. Ah well.
Anyone interested in what it takes to write software for space would enjoy reading through these and other details in the AMA. And since it had a convenient side effect of serving as a recruiting event, there are plenty of invitations to apply if anyone has ambitions to join the team. We certainly can’t deny the attraction of helping to write the next chapter in human spaceflight.
With the launch of the SpaceX Demo-2 mission, the United States has achieved something it hasn’t done in nearly a decade: put a human into low Earth orbit with a domestic booster and vehicle. It was a lapse in capability that stretched on far longer than anyone inside or outside of NASA could have imagined. Through a series of delays and program cancellations, the same agency that put boot prints on the Moon and built the iconic Space Shuttle had been forced to rely on Russia to carry its astronauts into space since 2011.
But America’s slow return to human spaceflight can’t be blamed on the CST-100, or even Boeing, for that matter. Since the retirement of the Space Shuttle, NASA has been hindered by politics and indecisiveness. With a constantly evolving mandate from the White House, the agency’s human spaceflight program has struggled to make significant progress towards any one goal.
Complexity is a funny thing. In prehistoric times, a caveman might float across a lake on a log. That’s simple. But as you add a rudder, a sail, or even a motor, it gets more and more complex. But if you add enough complexity — a GPS and an autopilot, for example, it becomes simple again. The SpaceX Dragon capsule actually docks itself to the ISS. However, the crew on the station can take over manually if they need to. What would that be like? Try the simulation and find out. If you don’t make it on the first, try, [Scott Manley’s] video below might help you out.
This isn’t a flashy Star Wars-style simulator. Think more 2001. Movement is slow and it is easy to get out of control. The user interface is decidedly modern compared to the old Apollo era
Under the current Administration, NASA has been tasked with returning American astronauts to the Moon as quickly as possible. The Artemis program would launch a crewed mission to our nearest celestial neighbor as soon as 2024, and establish a system for sustainable exploration and habitation by 2028. It’s an extremely aggressive timeline, to put it mildly.
To have any chance of meeting these goals, NASA will have to enlist the help of not only its international partners, but private industry. There simply isn’t enough time for the agency to design, build, and test all of the hardware that will eventually be required for any sort of sustained presence on or around the Moon. By awarding a series of contracts, NASA plans to offload some of the logistical components of the Artemis program to qualified companies and agencies.
For anyone who’s been following the New Space race these last few years, it should come as no surprise to hear that SpaceX has already been awarded one of these lucrative logistics contracts. They’ve been selected as the first commercial provider for cargo deliveries to Gateway, a small space station that NASA intendeds to operate in lunar orbit. Considering SpaceX already has a contract to resupply the International Space Station, they were the ideal candidate to offer similar services for a future lunar outpost.
But that certainly doesn’t mean it will be easy. The so-called “Gateway Logistics Services” contract stipulates that providers must be able to deliver at least 3,400 kilograms (7,500 pounds) of pressurized cargo and 1,000 kilograms (2,200 pounds) of unpressurized cargo to lunar orbit. That’s beyond the capabilities of SpaceX’s Dragon spacecraft, which was only designed to service low Earth orbit.
To complete this new mission, the company is proposing a new vehicle they’re calling the Dragon XL that would ride to orbit on the Falcon Heavy booster. But even for this New Space darling, there’s not a lot of time to design, test, and build a brand-new spacecraft. To get the Dragon XL flying as quickly as possible, SpaceX is going to need to strip the craft down to the bare minimum.