Private (uncrewed) suborbital flights to start this year.

All of Armadillo Aerospace, Blue Origins, and Masten Space Systems plan on making uncrewed suborbital test flights this year. And Blue Origins believes they can begin crewed suborbital test flights next year. This could be the time frame in which SpaceShipTwo will be making its first suborbital test flights.
See the links to the respective suborbital programs here:

Suborbital RLV.
https://c3.ndc.nasa.gov/flightopportunities/platforms/suborbital


Bob Clark

Fingers crossed for a exciting year!

Thanks for posting.

I have wondered why Armadillo haven't gone higher with their launches (or perhaps they have!), but hopefully this year we will see something pretty special. I'm guessing they are pretty busy with their paying customers.

Also hopeful for Masten to push some higher altitudes.

The real dark horse is Blue Origin - they could really jump the queue on this one - lots of cash and staff and no need, unlike Armadillo, to keep in profit in order to keep going sensibly. Bezos does have a few quid after all!

Not sure about the Lynx - seems to be a lot of work required there before anything flies, whilst SS2 I think should do a powered flight this year.

Out of all those, I reckon Armadillo vs Blue Origin for the first one to 100km, with SS2 a close third.

Fingers crossed!

Interestingly, though orbital flight has been considered much more difficult than suborbital flight, and indeed the "cost" in energy and velocity is much higher, surprisingly it can be done now actually at a lower monetary cost than at least that of the Virgin Galactic suborbital system.
As I mentioned here a reusable launch vehicle can be constructed for an amount in the range of $10 million to $20 million:

An SSTO as "God and Robert Heinlein intended".
viewtopic.php?p=44625#p44625

Compare that to the estimated $150 million to $200 million Virgin Galactic will be paying to develop the WhiteKnightTwo/SpaceShipTwo suborbital system.

This reusable SSTO is of the DC-X powered-landing format not the X-33 lifting-body format and is derived from 1970's technology Delta Thor lightweight structures and NK-33 high efficiency engines, which is why I have argued SSTO's with significant payload capability have been possible for decades. However, to get the SSTO you need to use both weight optimized structures and high efficiency engines at the same time. Previously, and frustratingly still now, launchers have been given one or the other but not both.
Of the suborbital flight companies mentioned Blue Origin and Virgin Galactic have sufficient financing to easily build this SSTO. And indeed it is of such simple design an operational prototype could probably be flying by the time they have their manned suborbital flights in operation.
As I said this SSTO is of the DC-X design. Since Blue Origin is already going to use this powered landing approach for their suborbital vehicle they may have a leg up in the race to first field this SSTO. However SSTO's of comparable size that used instead horizontal landing would work just as well. Then Virgin Galactic with partnerships both with Scaled Composites with the winged SpaceShipTwo and now with Sierra Nevada with the lifting-body Dream Chaser could also easily field a horizontal landing type SSTO.


Bob Clark

AA is limited at Caddo Mills to 6000 feet. We'll be flying much higher at Spaceport America this year, it's just a long drive.



This is not the case.

Ben

Which bit? Does Bezos not have the cash, or do Armadillo not require paying customers to maintain their development/development speed? My thoughts were that without paying customers your development would still be there but at a slower rate, giving the chance to Blue Origin and others to 'overtake'. Perhaps JC has more money that I imagine (surely not as much as Bezos though)!

Or...are BO so far behind they are out of the race? I cannot find any information about their progress at all.

Blue development is at a specific rate, Bezos allots a fixed sum and the team accomplishes what they can with that. It is a lot of money, though, I'd guess 10-30M/year.

Armadillo does have customer projects, but John has publicly stated recently that after the acquisition of id software by Zenimax, he has more money he could put into it if it looks like it will speed up the process. In his words, he "doesn't want to be just another small aerospace contractor". It's entirely possible we'll be going faster on our projects once the current customer ones wrap up.

AA spends around $1M/year; we can't afford to do big liquid hydrogen projects like Bezos, but we've flown more vehicles since I started here last year than they have in the history of their company.

It's going to be very interesting to see how the results come out - big traditional rocket development - plans lots, fly little, vs the 'Agile' AA approach of incremental improvement through multiple iterations (Very Scrumlike for those from software development arena).

Since the Agile process seems to produce faster better results in software, let's hope the same applies to rockets!

The Agile approach is certainly more fun from a onlooker perspective - more flights == more excitement!

Well, in software one of the reasons that agile development methods work better than the old monolithic waterfall process, is that requirements are often unknown, and mistakes are cheap to fix. So it makes sense to just start building, because once the customer sees something, they can usually tell if that is what they wanted, even if they couldn't tell you what they wanted before you started. If it turns out that what you built is not right, you just change it and recompile.

However, if you're building a space transportation system, then the requirements are often pretty simple: x kg to LEO (or to 100 km), reliably, and as cheaply as possible. The solution however is complicated and expensive to build and change, especially for larger vehicles. So maybe for small rockets an agile process works, but as the rockets get bigger, I think it becomes unaffordable. Agile works for building Pixel, but it doesn't for building a Space Shuttle.

In the software project I work on, we have a six-month release cycle, and we do write down requirements. I don't think we could do anything more agile, since there are too many stakeholders from too many different backgrounds. We need a bit more process to keep chaos at bay. On the other hand, six month is not that much time, so it's a good compromise I think. Call it the SpaceX option .

While I think you are more or less dead on with your comparison of agile development in software vs. in rocket engineering, I do think you miss an important point.

While nobody would want to build a whole shuttle in an agile process, there are lots of subsystems of such a complex machine and those could be very well suited to an agile R&D approach. Even if that is not the case, then there is a lot of potential benefits for future large rockets/spaceplanes to be gained from agile R&D on small vehicles like Masten and Armadillo are doing.

The whole aerospace sector is still full of unproven/untested/ ideas but no big project want's to realize them because of the costs and risks associated with them. But if somebody could prove them on a smaller scale, in an agile process that doesn't consume lots of money in theoretical studies, it is more likely to be used on a bigger project later on.

So even if a large space transportation system might not be suitable for an agile/responsive development process, it could certainly benefit in an indirect manner.

I agree, but I'd call that rapid prototyping. If I understand correctly, agile projects are pretty much always in development, it's a continuous process and the software keeps evolving with its users' needs. That's good for a piece of software that's used directly by end users, but for a library that others need to build on you need API stability. The same thing goes for Shuttle parts. You can develop things in rapid iterations, throwing things away and replacing them as you figure out the right way to solve the problem. But in the end you have to evolve towards a stable configuration and get lots of testing and flights on exactly that component to retire the risk. You can't go and change it on every flight. Of course that is also because potential consequences of failure are much higher; I'd use the latest SVN version of software developed by agile methods (if it were Free Software that is), but I don't think I'd step into a rocket controlled by last week's checkout of the flight computer software, the design of which was done in a 20 minute stand-up meeting...

They build the Soyuz rocket in batches of two, with each batch incorporating fixes or alterations from previous rockets. It is the most reliable human launcher ever.

Because it is expendable they are forced to build new ones, but the same is done with reusable vehicles. Compare a modern U-2 or 747 to the first of each craft. They're very reliable, yet they have continuously changed since they were introduced.

One must not ask too much of the Shuttle program. They did make some improvements over time, but ultimately it was not just a space transportation system, but a system for federal pork and a jobs program.

@Lourens

There is agile design and there is agile production. Both of which just mean having the processes and capabilities to make "running" changes to the design without needing to completely halt ongoing operations.

If you build in the requisite checks and quality controls, there is no reason why "agile" can't be used for aerospace projects. The US aircraft industry got very good at it during WW2. You simply streamline in your QA and testing procedures into your production environment. Yeah it will still take months, but it won't take years like it currently does. At least if the FAA and other regulatory bureaucracies permit it.

Okay, when I think of agile development methods I think of iterations measured in weeks, of not having much in terms of designs or documentation, continuously changing requirements, close cooperation between users and developers, and so on. Two Soyuz per year is quite a long cycle by those standards, and I assume that they have some design drawings somewhere at least. Probably not as much as NASA would have, but still.

I agree with what you are saying actually, and of course you want to take advantage of new technologies or design improvements that improve performance or safety. But for systems upon which lives depend, I'd like a bit more than twenty minutes to be spent on (part of) the design of anything, and a bit more than a few weeks on making sure it actually works properly. Anyway, I don't think we disagree, except on what we mean exactly with the term "agile" .

Well, the Agile projects I have worked on had design (although not to the same level of waterfall methods), documentation (done on each iteration), and an initial set of requirements, that does change, but not continuously. Agile isn't (or shouldn't be if you want it to be successful) the free for all that some think it is.