What’s the Point?

What’s the Point?

That is a question that comes up from time to time when people see Xaero-B and Xodiac. Both vehicles seem to be doing what other rocket companies have already *demonstrated* and to greater lengths at that. The underlying premise of the question is this: you are not seeing anything that hasn’t already been done. And there is some truth to that on the surface, the VTVL part is not any different. It is in this perception of us vs them that the question sort of belies the real activity at hand.

Developing rocket technology is more than a skin deep proposition.

So to frame this conversation and to add some early perspective into it, one thing to be considered is that Xaero-B and Xodiac are technology demonstrators. With this write-up, we want to share some insight on why people come to Masten for flight testing while also shedding some light on the 1s and 0s of what you can’t see that makes it all possible.

For a hardware and software developer, it [the why test with Masten?] is usually a matter of very focused resource allocations and the cost of building a rocket-powered test bed just may not fit the budget or longer-term need. Those developers whether individuals, research groups, academia or a government agency have a need to prove out and or advance the TRL of what they have. Either through direct funding or with some help from a program, if selected, like NASA’s Flight Opportunities Program (NASA FOP) their technology is matched with a flight service provider who can meet their needs. This then leads to the technology getting rolled up into a payload that is configured for attaching to the flight vehicle.

NASA’s Flight Opportunities program strives to advance innovative space technologies of interest to the agency while also stimulating the growth and use of the U.S. commercial spaceflight industry as well as supporting capability development in the suborbital and orbital small satellite launch vehicle market.

NASA Flight Opportunities

Flight Testing


Presently, it is not convenient to test on the Moon or Mars but terrestrially it is a very different story. You see, there can be a large swath of development testing space between the launch and landing parts. Someone with a payload may want to work inside of this area but lack the access to it. In that same vein,  as rocket technology innovators, we at Masten are not immune from the need to do technology/development related testing. To address this we have built several Engineering Test Articles (ETAs) over the years and currently operate two ETAs named Xaero-B and Xodiac. Our vehicles aid us in the design of technologies for rockets, space applications and landers by allowing one to test in ways you just can’t test on an airplane, helicopter or in some cases even other VTVL rockets. And we have made both vehicles available commercially as a test bed service where we can and have ‘handed over the keys’ for a technology developer’s use.

The goals for any payload flying with Masten are typically to test early in the design cycle, to test often, to buy down risk prior to final implementation, and to not harm the payload in the process. Now, not every payload we fly interacts directly with the vehicle, but usually that is where the interest is in what we offer; a tailored flight test environment and the ability to interface directly at the GN&C level of the vehicle. With this comes a flexibility to turn an in-flight payload failure into an agile and iterative development environment. More about this in a bit.


In founding Masten Space Systems, I had (and still have) the belief that we have to confront the technical realities of today to address the ambitions of tomorrow by not being afraid to test early in the design process and by testing often. -Dave Masten


Payload Development

For our payload definitions- A payload that is interfaced with the vehicle may be open loop or closed loop. Open loop means we are the active flight control system. Closed loop means the payload is the active flight control system.

Payloads that are open loop while not in direct control are still part of an immersive test campaign. Jointly we collaborate to craft a unique flight trajectory that meets their needs and fits inside the capabilities of the vehicle. Then Masten will fly that trajectory with their payload onboard while they carry out their mission. Usually, this is a precursor to closed loop flight.

Payloads that come to Masten for closed looped flight testing get a sandbox of flight performance inside which they can ask the vehicles to do just about anything. Some may only want to do the ‘GN’ part, while some may need to do a full-up demonstration of their hardware and GN&C (Guidance, Navigation and Control) with an actual VTVL rocket. Whatever the level of interaction may be we give those payload providers a platform to do that testing with.

Generic flight profiles

Given that these are technologies in development it is possible that the payload may want to land where we know we can’t land, fly a trajectory that would deplete the fuel supply or otherwise just be outside of expected behavior.

Reasons may include:

*Payload simulation not sufficiently accurate to predict behavior
*Payload con guration error
*Payload loss of vehicle control
*Payload hardware or IMU failure
*Payload software failure
*Payload navigation error


Despite best efforts these sort of things can happen. -It is why we test-

Bring it all home


In offering this service, we didn’t want to lose our vehicle due to a payload failure so we needed a way to mitigate the risks of testing closed loop payloads and to make sure we get our vehicle back the way it left. To that end, we have implemented onboard the vehicle a kind of hypervisor system that we call SENSEI™, a virtual guardian of sorts. It is constantly monitoring in real-time what is being executed on the vehicle such that if by direction of the payload the vehicle violates predetermined boundaries we can revert control back to our native GN&C system. Our system will execute an ‘Abort’, which for us just means to cancel the current flight trajectory and initiate a safe vehicle recovery to landing as soon as possible.

And while we have never really talked about it, for years now and over hundreds of flights, our vehicles have had this autonomous precision landing ‘Abort’ capability with real-time divert and landing pad select options. The combined test team works very hard so that this ‘Abort’ scenario never comes into play. But if it is needed we get the vehicle with payload back to try again. This is important for our own needs while also a benefit to our payloads.  It is this freedom to take risks in testing that is the crux of why people test with Masten. Payloads can confidently push the boundaries in a way they could not otherwise.

Ok- you said it is *why* payloads fly with you but I still don’t understand why would anyone *want* to test this way. Why use a terrestrial test bed to aid development when you can use very high fidelity simulations, extensive hardware-in-the-loop testing, vibe testing, build an Iron Bird and so forth? Good question and points made. Those are ways of testing that are valid early in the development phase, as a part of ongoing hardware/software maintenance, to check out block configuration changes later on and so on. They are tools of testing diligence that reduce the risk. But the question still remains, why fly on a rocket-powered test bed at all?

Well, it is simple really. Flight testing is the only place where everything is rendered in perfect HD. Physics are modeled to the utmost level of precision. Variable permutations are intrinsically infinite. Flight testing is an assessment of just how accurate all of the analytics and ground-based testing were.

What we provide to our clients in a nutshell:

*Fully autonomous flight.
*SENSEI™ allows safe testing of new GN&C components, systems, algorithms, software and a fully redundant system to fall back to.
*Fully autonomous flight safety system with flight to safe state.
*Demonstrated in flight recalculation of trajectories.
*Demonstrated touchdown accuracy of inches.
*Navigation sensors & filters allow sub 1” position knowledge.


Our payload developers recognize that they don’t intend to put their test bench, support hardware with development software into commercial service. When that transition from lab to real-world implementation happens, failures can be expensive – and not just financially. Before you traveled to the Moon or Mars if you had the opportunity to test your integrated solution in a ‘representative’ configuration, why wouldn’t you?

When you see videos of Xaero-B or Xodiac flying very rarely did we fly just because we wanted to (although we always do want to). The operation of 3rd party hardware and or software is transparent to the visuals of the vehicles flying, which is good and all but looking from the outside in it can be hard to appreciate the grand efforts. That make it seem…. almost redundant to what others have demonstrated, but alas it is anything but redundant. Just like we want options of capability in the cars and trucks we buy, we very much need technology options for our rocket powered vehicles and not just for the *VTVL* part of it all 🙂

We recently tested on Xodiac a payload called COBALT. The flight testing of that sensor package with its capability to provide an unprecedented level of landing precision, where GPS or any other existing aids are not available, is a technology option that until now- no one had plain and simple. To routinely access space and exoplanets we will need options for reaching areas of interest using precision landing to be right where we need to be and on-site capabilities for when we are safely there.

When you boil it all down to what we do and what virtually every other rocket technology developer does, it is very much complementary. We need to be successful at what we do and we need them to be successful at what they do. Space with all that it holds beckons to us.  And we are going to need lots of options to explore it.

We at Masten are going to space, to the Moon and beyond. Xaero-B and Xodiac are part of solving the technical challenges in doing that.

For us, it goes without saying that we are proud of what we do and we are pretty dang good at it if we do say so ourselves.