We are about to go on a pretty incredible journey, one that has never before been attempted. On Wednesday, February 26, we will launch Odin into Deep Space. This will be the first privately constructed spacecraft to attempt to go this far out into our solar system. But before we launch, I want to share how we’re thinking about the mission objectives. Specifically, I want to clearly define what “success” means for Odin.
I want to set expectations clearly. I asked the team at AstroForge to work with incredible speed—and that speed comes at a price. We are taking exceptional risks on this mission, more risks than most companies would be willing to accept. If this mission fails, the fault lies with me alone. I was involved in the intimate details of every trade-off we made—and we made a lot.
The core principle of iteration is the guiding light at AstroForge. We learn a lot from making it to a failure; we learn nothing by stagnation.
From the start, Odin has always been a first-of-its-kind test mission. Brokkr, our first mission, was a much simpler cubesat that was meant to show that we can launch something quickly.
With Odin, the process of building a spacecraft from the ground up in less than 10 months (more on that later) has already generated a massive amount of learning on how to design, construct and test complex missions for Deep Space. So our main objective for this mission is to make it past the moon and into Deep Space.
The second objective is to do a fly-by of our target asteroid, 2022 OB5. This objective is going to take much longer to achieve and therefore has a far lower likelihood of success.
Why? Well, the simple answer is we can do a lot of testing here on Earth. But what we can’t do is remove gravity and fully test a spacecraft while it’s still on Earth. So the only way to truly know what could go wrong with a spacecraft is to send it into Deep Space. We believe that iterating as quickly and as often as possible is the only way to burn down risk on building a spacecraft - at a reasonable price point - that is capable of mining an asteroid.
Our emphasis on speed helps us identify where and how we’re wrong as quickly and as effectively as possible. Since starting to build Odin last year, we’ve been wrong a lot. In a previous blog, we talked about our first critical mistake of trying to buy our satellite bus. At the time, we believed that we could be horizontally integrated, enabling us to focus on the subsystems that matter most to us like mining technology. When that bus failed its first vibe test, it was a gut punch of a lesson in how misaligned incentives with vendors would make horizontal integration really difficult.
Fortunately, we learned this lesson pre-launch, and we had enough time to make a shift towards more vertical integration. We went from having effectively nothing in May of 2024, to a working spacecraft that is currently on a Falcon 9 getting ready for launch. That is an unheard-of-timeline in the space industry. But building a fully functional spacecraft in less than 10 months didn’t come for free.
We took a lot of engineering risk and prioritized answering real engineering questions over what can be perceived as media milestones.
With all that being said, here are the upcoming critical events for AstroForge and Odin as we embark on Mission 2.
For the purposes of this post, we’re going to intentionally leave the timelines out. It’s not that they’re unimportant; rather they’re quite dynamic and have a lot of interdependencies. Said differently, it’s very easy to slip on timelines and still have mission objectives be in good status, and vice versa. So instead, we’ll focus on the key events and which mission objective they most directly impact. Our main objective is to get past the Moon and reach Deep Space. The following events are critical to us achieving this objective:
Our scheduled launch is on Wednesday, February 26th, in the afternoon (PT). We’ve been integrating with the rocket for the past month, enabling us to conduct testing to ensure we survive launch. With over 300 successful launches and a mission success rate exceeding 98%, Falcon 9 has established itself as one of the most reliable rockets ever built, and its launch environments are very well understood. This is one of the rare parts of the mission that we can fully test—and even over-test—on the ground. Our vibration testing, despite the failure of the vendor-provided bus, went off without a hitch.
When we get thrown off the side of the Falcon 9, numerous forces can be imparted on the spacecraft. So the first thing we need to do is to stop Odin’s tumble through space using a series of maneuvers with our reaction wheels to become stable. Once stable, we then need to become power positive, which means generating enough power from our solar panels to recharge the batteries and ensure our power systems are functional and can sustain a long–duration mission. This is done by using our sun sensors to determine the position of the sun relative to the spacecraft then commanding the vehicle to point the solar panels at the giant ball of fire in the sky.
The risk here is twofold. First, we can never fully test the non-gravitational algorithm used to rotate and spin the spacecraft on Earth. If someone can figure out how to turn off gravity, please let us know because we’ll be your first customer. Until then, we consistently simulate it and verify that the correct reaction wheels are spinning at the right time. As with most hardware solutions, the real test will be done in the environment, and the environment for us just happens to be thousands of miles above the Earth in the vacuum of space.
The nice part of this process is that we have large batteries that can support the vehicle for hours giving us a high probability of fixing any issues that arise. Once we achieve a power-positive state, we’ll have days to troubleshoot and fix any potential issues.
Command (Earth → Spacecraft) and data (Spacecraft → Earth) are critical communication functions focused on data exchange and control of the spacecraft. Command sends instructions from Earth to the spacecraft, such as course corrections, system resets, or experiment activations. Data sends status from the spacecraft to mission control. This data includes health data, position information, and sensor status.
Talking with a craft that is constantly getting further away from Earth is challenging. Unlike what has become a normal space launch—a craft orbiting Earth in Low Earth Orbit (LEO)—we will be communicating over extreme distances of millions of miles. That also means we need to use some of the few really large dishes that are distributed across the world. Not all dishes can both transmit and receive data from the spacecraft; there’s a minimum size of dish we need to receive given the distances we’re covering. Additionally, a dish needs a minimum amount of power to transmit data to the spacecraft.
The first test will be our ability to command because we have a known issue: the spacecraft power amplifier will not turn on automatically. This component boosts output power to reach Earth, but we leave it off on Earth as broadcasting at this massive energy level is dangerous to people. During additional testing post-integration on the rocket, we noticed that the line of code to turn on the power amplifier would not work. So, before we hear from the spacecraft, we'll need to command the power amplifier manually until we push a small software update.
We’ll attempt to command this small software update during the first pass via a dish in Australia, owned by Capricorn. We have conducted full testing at this dish and understand how to work with them; they were the ground station provider we brought in to help us recover from the first mission. The term “pass” refers to the period when a spacecraft is visible from a ground station. For a spacecraft in LEO, a pass is typically the time for the craft to fly overhead—usually around 45 minutes. For us, however, a pass can last up to 12 hours.
Over the next eight days, command and data will be performed using a plethora of large dishes around the world. The challenge here—still being worked on—is scheduling time. We want to do our best to ensure that we can transmit and receive simultaneously; however, it appears that this will be somewhat of a luxury. This means that at some point during this mission it’s likely we’ll need to do a “blind update” (executing a command without having first received data back).
The large dishes are also used for: ranging–Determining the spacecraft’s position using the signals sent to and from it. This feeds into our planning algorithms to determine if we need to execute a correction burn.
We have encountered some significant challenges when it comes to ranging. Last Wednesday (2/19), we conducted what we thought would be our final test with a large dish we planned to use in India. This test was designed to simulate the mission as closely as possible on Earth. Unfortunately, it failed.
A cell phone company installed a new antenna near the dish, and it was leaking into the frequency band causing the failure. Not our fault, but definitely our problem, and one we hope to fix thanks to the secondary planning we've done. First, we are working with our partners at KSAT to fix the issue, and we hope it can be resolved by the time we fly. Second, we are looking at alternative receiving sites that can provide overlapping coverage. This will allow us to post-process the signal and determine the range to the spacecraft. Third, we are collaborating with some external groups on doppler and radar tracking, which will also provide an update on our position. Doppler ranging would give us a sense of the spacecraft’s speed relative to the Earth, but it doesn’t give us absolute distance. Radar ranging would measure the spacecraft’s exact distance from Earth but is only accurate up to about 100,000 miles away for a spacecraft as small as Odin.
As a last resort, we are preparing for a scenario in which our first pass (and data transmission) will be our last, making all software and trajectory updates all at once to ensure Odin can reach the asteroid without any further interaction from us until we come back into transmit range at the end of 2025.
System checkout is where our mission engineers verify that all of Odin’s systems function properly in space. This process ensures that the spacecraft is fully operational before it begins its main mission objectives. This includes checking propulsion, thermal management, and all the on-board computers.
System checkouts themselves aren’t inherently risky, but they do help identify if we are facing mission risk due to a system not being functional. These checks are especially important for Deep Space craft; unlike spacecraft that orbit the Earth, Odin only has a finite window to conduct these tests and attempt to make a correction. Spacecraft that orbit the Earth don’t face this time constraint. So with a finite window of opportunity, the name of the game is contingency planning. If we do have broken components, we have to figure if we have any course of action. And then we have to determine if and how that might change the mission objective or what we do in any remaining communication windows.
We’ve always planned to perform in-mission software updates. This is something I learned directly from Bird—always be ready to change software at any time. Thankfully, this capability has been built into the spacecraft from the start.
As I mentioned above, we already have a very small update we need to do to turn on the power amplifier. But this is one of many software updates we will make to the spacecraft during its mission.
The largest of these updates was always planned to be done in flight. It has to do with image compression. Our current flight software can download images that will still look great, but they won't contain the level of data we want for the asteroid flyby. This was a priority call, where the entire team focused on testing the critical software to get us past the moon and pushing off until the asteroid intercept software until after we already shipped the vehicle.
This is where we are different. We prioritize the ability to iterate, and are willing to launch something as complex as Odin knowing that we don’t have the full capabilities on board. This is common for satellites in Low Earth Orbit (LEO), but they have months, or even years to fix any issue that pop-up. In Deep Space, we have 2 days.
Prior to reaching the asteroid, we'll calibrate our imagers by taking pictures of Earth. We've tested this extensively on the ground, but the challenge will be downloading the images to verify calibration needs.
We have shown that we can download large files, while transmitting from a large dish like the one in India, but we have yet to try it from space. The nice thing about this is the cost is low. If we fail to get calibrated photos of Earth, we'll have about 9 months to analyze logs and fix issues before reaching 2022 OB5.
Since we’re not the primary passenger on the rocket, our launch timing is largely beyond our control. The biggest implication is on our trajectory mapping, as we have to recalculate based on a number of factors. One of those is where SpaceX predicts they will drop off Odin, e.g. where we hop off. Based on that position, we calculate an optimal trajectory that maximizes the benefit of the moon's gravity and Odin's onboard propulsion. Because we have to aim for a point further away and further in the future, our trajectory needs to be more accurate than typically done for Earth orbiting spacecraft. This optimized trajectory lines us up to be in just the right place at the right time - months later - to encounter 2022 OB5. Along the way, we will use updated orbit estimates to do course corrections and keep Odin on track. Making these trajectory corrections accurate requires improving our understanding of the spacecraft and thrusters as we go, so we can predict the next maneuver better than the last one.
The plan is to not impact the moon. However, depending on where the Falcon 9 drops us off, we might initially start on a collision course with the Moon. If this is the case, we’ve planned a correction burn that will enable us to use the Moon’s gravity to slingshot around it and avoid impacting the moon. The primary risk in this is not whether the correction burn works but rather if we successfully get through the Systems Checkout. We also have to get through checkout fast enough to plan and implement that burn within the first few days of flight.
We’ll have to do correction burns later in the mission too, in order to accurately target the asteroid flyby. However, we will have a lot more time to prepare for each of those burns and a lot more experience flying Odin by then. The challenge with these later correction burns is keeping the trajectory accurate so we get very close to 2022 OB5 when we plan to.
This is a really important milestone, both technically and emotionally. If we fly by the moon, which should happen on day 5, then we’ve overcome the majority of our potentially mission-altering technical challenges. That means that the likelihood of making it to 2022 OB5 increases significantly.
For the team, it also cements our place in history as the first privately funded mission to enter Deep Space.
On day ~7, if everything is as expected, we’ll perform our burn that will put us on an intercept course with the asteroid. This burn is long; it's an 8‑hour total pulsed burn to make it happen. This is one of the most dangerous parts of the mission.
Due to our rapid development of the spacecraft build, we made an early decision that we knew would pose a challenge. Many Deep Space missions have gimbaled thrusters. This is because if you are firing your thruster off a centerline, you can gimbal the thruster and keep the vehicle stable.
We don't have that; we have five fixed thrusters on a baseplate. So if you fire one, and it's slightly off‑center, it will start to induce forces on the vehicle that cause it to spin.
We’ve solved for this by doing what we call a de‑saturation maneuver. A desaturation maneuver is a controlled adjustment used to manage and reset a spacecraft’s reaction wheels, which are responsible for attitude control (i.e., orienting the spacecraft in space). Over time, these devices build up excess momentum due to external forces like solar radiation pressure, gravitational interactions, or most likely in our case, small thruster asymmetries. The desaturation maneuver offloads this excess angular momentum to maintain stable spacecraft orientation. These many small corrections and resets can take a significant amount of time.
That's it – that's what we know. I'm sure there is more we will learn, but we don't get far without the best group of individuals in the world working together to change it.
