OSIRIS-REx/OSIRIS-APEX Mission Updates

[edzieba]

He also showed an interesting 3D model of the surface before and after the sampling, revealing the crater that they left. Some really sophisticated stuff.

There are some visualisations from that model available. I don't think the textured model itself is available, but the laser altimeter dataset is available in the OLA bundle.

[Blackstar]

(More about the presentation that I mentioned up-thread.)

I will see if I can post the slides from the presentation here, although if the video gets posted, you should watch that because it includes his (the PI's) explanations. He discussed the popcorning effect with particles popping off the surface. He said that there are three different explanations for what is happening. I don't remember what they are (they have probably been discussed in the open literature before, so if you are curious you can look). He said that there is no consensus on the cause, and it is possible that it happens because of a combination of all three.

He also said that this posed no risk to the spacecraft unless it hit an optical sensor. I think he said that they have had some degradation of the optics--maybe 10%?--due to dust from the encounter touching Bennu.

[Blackstar]

[Blackstar]

[Targeteer]

https://blogs.nasa.gov/osiris-apex/2023/12/01/nasas-osiris-apex-to-fly-closer-to-sun-to-reach-asteroid-apophis/

NASA’s OSIRIS-APEX to Fly Closer to Sun to Reach Asteroid Apophis

Reinvented as NASA’s OSIRIS-APEX, the spacecraft formerly known as OSIRIS-REx is about to face the first major test of its mission to asteroid Apophis: it will fly closer to the Sun than ever before, exposing its components to higher temperatures than they were designed to endure.

At its closest approach (known as its perihelion) on Jan. 2, 2024, OSIRIS-APEX will be about 46.5 million miles away from the Sun – roughly half the distance between Earth and the Sun, and well inside the orbit of Venus. However, this is 25 million miles closer to the Sun than the spacecraft was designed to operate, as the Apophis rendezvous wasn’t part of the original mission plan to fly to asteroid Bennu to collect a sample.

When OSIRIS-REx (Origins, Spectral Interpretation, Resource Identification, and Security – Regolith Explorer) left Bennu in May 2021 with a sample aboard, it had a quarter of its fuel left and its instruments were in great condition. So instead of shutting down the spacecraft after it delivered its Bennu sample to Earth on Sept. 24, 2023, and sending it into a forever orbit around the Sun, the team proposed to dispatch it on a bonus mission to Apophis. NASA agreed and OSIRIS-APEX (Origins, Spectral Interpretation, Resource Identification, and Security – Apophis Explorer) was born.

The upcoming perihelion is the first of six close Sun passes – along with three Earth gravity assists – OSIRIS-APEX will undertake to reach Apophis in April 2029. To keep its critical components safe during these passes, engineers at mission partner Lockheed Martin Space developed a creative spacecraft configuration.

Graphic of a gray spacecraft with its two black-appearing solar panels in a protective position
OSIRIS-APEX in its new configuration, viewed from the direction of the Sun. The solar array in the foreground is facing away from the Sun, so the back of the panel is visible. This shades the critical areas of the spacecraft. The solar array in the background is facing the Sun (although not directly) and is being used to generate power. Credit: NASA/Goddard/University of Arizona

“We are most creative when the spacecraft is in flight and we’re pushing boundaries to meet mission needs,” said Sandy Freund, OSIRIS-APEX program manager at Lockheed Martin Space in Littleton, Colorado, who had the same role on OSIRIS-REx.

To prevent overheating, the spacecraft will maintain a fixed orientation with respect to the Sun and reposition one of its solar arrays to shade its most sensitive components. Thermal models indicate this configuration will keep the spacecraft safe.

“We’ve done a lot of modeling to ensure the spacecraft will be safe,” said Dani Mendoza DellaGiustina, principal investigator for OSIRIS-APEX at University of Arizona, Tucson. “But any time you take a piece of space flight hardware beyond the design criteria you incur risk,” said DellaGiustina, who is also the deputy principal investigator of OSIRIS-REx.

The spacecraft is executing commands this week to tuck in one of its two solar arrays; the second will remain extended to produce power.

During this time, the spacecraft will be inactive, with only critical systems, such as telemetry, turned on. It will communicate with Earth at low data rates, so the mission team will receive only limited information about spacecraft status. Once OSIRIS-APEX is farther from the Sun in March and April, engineers will turn the instruments on to test them.

By Lonnie Shekhtman
NASA’s Goddard Space Flight Center, Greenbelt, Md.

[redliox]

Watching the visual, is it correct that OSIRIS-APEX flybys Apophis around March of '24 and then begins orbiting it in '28 after the asteroid/Earth encounter?

[Hungry4info3]

I was curious about that apparent flyby as well but I'm told that NASA's Eyes on the Solar System shows a closest approach of ~10 Mkm. So effectively no flyby in early 2024.

[Yellowstone10]

So turns out, the drogue did not deploy:

https://blogs.nasa.gov/osiris-rex/2023/12/05/nasa-finds-likely-cause-of-osiris-rex-parachute-deployment-sequence/

After a thorough review of the descent video and the capsule’s extensive documentation, NASA found that inconsistent wiring label definitions in the design plans likely caused engineers to wire the parachutes’ release triggers such that signals meant to deploy the drogue chute fired out of order.

The drogue was expected to deploy at an altitude of about 100,000 feet. It was designed to slow and stabilize the capsule during a roughly five-minute descent prior to main parachute deployment at an altitude of about 10,000 feet. Instead, at 100,000 feet, the signal triggered the system to cut the drogue free while it was still packed in the capsule. When the capsule reached 9,000 feet, the drogue deployed. With its retention cord already cut, the drogue was immediately released from the capsule. The main parachute deployed as expected, and its design was robust enough to stabilize and slow the capsule, resulting in a safe landing more than a minute earlier than expected. There was no negative impact to OSIRIS-REx’s Bennu sample as a result of the unexpected drogue deployment.

[woods170]

Jeff Foust's write-up of the drogue failure:

https://spacenews.com/osiris-rex-parachute-deployment-affected-by-wiring-error/

The drogue was designed to deploy at an altitude of about 30.5 kilometers, helping to slow and stabilize the capsule before the larger main parachute was deployed. A signal intended to deploy the drogue, though, instead caused the capsule’s systems to cut the drogue free while it was still packed inside.

NASA got bloody lucky that the capsule didn't start tumbling upon entering the denser regions of the atmosphere. Otherwise this would have been a repeat of the Genesis crash, given the fact that deploying the main parachutes from a tumbling vehicle usually does not result in proper main parachute deployment.

[litton4]

Yes, does not look good, after Genesis....*cough* MSR anyone.....*cough*
 

[Robotbeat]

Yes, does not look good, after Genesis....*cough* MSR anyone.....*cough*

MSR avoids chutes altogether for exactly this reason: there’s no way to make them as reliable as they need to be to guarantee (to like 6 nines) that the chutes won’t fail and the capsule won’t crash and spread pristine Martian regolith all over the desert.

Just design the capsule to not use parachutes in the first place, just big enough for terminal velocity to do its job and for crush core to do the rest.

[Nomadd]

Yes, does not look good, after Genesis....*cough* MSR anyone.....*cough*

MSR avoids chutes altogether for exactly this reason: there’s no way to make them as reliable as they need to be to guarantee (to like 6 nines) that the chutes won’t fail and the capsule won’t crash and spread pristine Martian regolith all over the desert.

Just design the capsule to not use parachutes in the first place, just big enough for terminal velocity to do its job and for crush core to do the rest.

If you can't keep your wiring straight, nothing is going to be reliable. This was one of the more boneheaded mistakes in aerospace history.

[Robotbeat]

Exactly, “NOTHING” is going to be reliable.

“Best part is no part.” Don’t put parachutes on it at all.

That’s the strategy of MSR. No active systems or moving parts once ejected from the transfer craft.

No wiring to screw up if there isn’t any wiring on the capsule.

[whitelancer64]

Osiris-Rex's sample return capsule is almost entirely Stardust heritage design, with some updates due to reanalysis and testing.

Document: https://ntrs.nasa.gov/api/citations/20170002015/downloads/20170002015.pdf

Mentions a parachute drop test performed for Osiris-Rex (the last paragraph on page 12), unfortunately I cannot find any information on when that happened or what the test (s?) involved. Anyone else able to find anything more?

[meekGee]

Jeff Foust's write-up of the drogue failure:

https://spacenews.com/osiris-rex-parachute-deployment-affected-by-wiring-error/

The drogue was designed to deploy at an altitude of about 30.5 kilometers, helping to slow and stabilize the capsule before the larger main parachute was deployed. A signal intended to deploy the drogue, though, instead caused the capsule’s systems to cut the drogue free while it was still packed inside.

NASA got bloody lucky that the capsule didn't start tumbling upon entering the denser regions of the atmosphere. Otherwise this would have been a repeat of the Genesis crash, given the fact that deploying the main parachutes from a tumbling vehicle usually does not result in proper main parachute deployment.

NASA got lucky that the misrouted wire was connected to something more important, like the main chute cutaway mechanism, or some other form of self-destruct.

This is not about parachute reliability, it's about how this mistake didn't get caught during testing.

[whitelancer64]

Side note: The drogue and main parachutes for Osiris-Rex were made by Pioneer Aerospace, which was recently purchased by SpaceX.

Pioneer Aerospace also made the parachutes for Stardust, Pathfinder, and the Mars Exploration Rovers and several other NASA missions.

[LouScheffer]

Jeff Foust's write-up of the drogue failure:

The drogue was designed to deploy at an altitude of about 30.5 kilometers, helping to slow and stabilize the capsule before the larger main parachute was deployed. A signal intended to deploy the drogue, though, instead caused the capsule’s systems to cut the drogue free while it was still packed inside.

NASA got bloody lucky that the capsule didn't start tumbling upon entering the denser regions of the atmosphere. Otherwise this would have been a repeat of the Genesis crash, given the fact that deploying the main parachutes from a tumbling vehicle usually does not result in proper main parachute deployment.

I suspect (but don't know) that this was not entirely luck.  It's possible to design aeroshells that are stable all the way until impact.  In particular, the Osiris-Rex design was based on Stardust, and the analysis Aerodynamics of Stardust Sample Return Capsule shows where to put the center of gravity such that the capsule is stable at both supersonic and subsonic speeds.   And in particular, for Osiris, you'd want the capsule to be as natively stable as possible, since it will be perturbed by the unknown mass and location of the sample(s).

So overall, I suspect the capsule was designed to be natively stable at transonic and sub-sonic speeds, even though this is not required if the drogue works as expected.  Probably it was not as stable as they would like for main parachute deployment, but at least not tumbling.

[AS-503]

The second flight of the Saturn V in April 1968 had the J-2 engines on the 2nd stage mis-wired.
The guidance computer sent a shutdown command to an engine that was having spark igniter problems but the mis-wire shut down a healthy engine.
Two engines out on that vehicle could have been LoM.

[woods170]

Jeff Foust's write-up of the drogue failure:

https://spacenews.com/osiris-rex-parachute-deployment-affected-by-wiring-error/

The drogue was designed to deploy at an altitude of about 30.5 kilometers, helping to slow and stabilize the capsule before the larger main parachute was deployed. A signal intended to deploy the drogue, though, instead caused the capsule’s systems to cut the drogue free while it was still packed inside.

NASA got bloody lucky that the capsule didn't start tumbling upon entering the denser regions of the atmosphere. Otherwise this would have been a repeat of the Genesis crash, given the fact that deploying the main parachutes from a tumbling vehicle usually does not result in proper main parachute deployment.

This is not about parachute reliability, it's about how this mistake didn't get caught during testing.

Exactly!

Even after 6+ decades of worldwide spaceflight experience, wiring mistakes keep being made and keep being NOT caught during testing.

AS-503 gives a beautiful early example in reply #417. A more recent example is the loss of Vega mission VV17 in november 2020: two cables used in the AVUM stage TVC system were inverted. Yet testing didn't catch this error. Testing also didn't catch the error that came close to dooming the Osiris-Rex return capsule landing.

A little known story about the European Robotic Arm (ERA) is this: one of the end-effectors of the flight model had a cross-wiring mistake. This was NOT detected during any of the original acceptance testing performed on the flight hardware.
Only the lengthy delay of the MLM Nauka launch eventually exposed the wiring mistake, when the need came to open up the flight hardware for re-lubing of certain components. A visual inspection then, by mere accident, exposed the cross-wiring mistake.
Had this mistake not been caught, there would now have been an ERA up there on the ISS, with one End-Effector suffering from a non-functioning heating system. Which would rapidly lead to that End-Effector seizing up, effectively reducing the robotic arm to a pile of useless hardware.
So, why did the acceptance testing not catch the cross-wiring mistake. Well, to catch it, the heaters would have to be turned on. But since acceptance testing took place at room temperature, instead of the cold of space, there was the risk of causing damage to the flight hardware by the heaters. Therefor, it was decided to not test the heaters as part of the acceptance testing. So, this thing slipped through, as a result of inadequate testing.

Another example of how testing did not catch a wiring mistake: in 2018 a report was released into the ungoing delays with JWST. This report noted how a bunch of JWST transducers had to be replaced, after they had been exposed to excessive voltage during testing. It turned out that a wiring mistake had been made in the test hardware. An inspector was supposed to test the testing hardware before use on JWST. But instead of actually performing the test, the inspector merely relied on the wiring technician's word that he had the done the wiring correctly. NOT testing while testing is required, is also a form of inadequate testing.

Wiring mistakes can be quite dangerous, particularly on crewed vehicles. Here's a fine example from STS-51:
A payload separation system used on that mission was the "Super Zip" system. This is basically a metal band, holding the payload in place, surrounded by a pyrotechnic cord. Or well, two of these cords actually: a primary and a backup. The firing of one of those cords will cleanly split the metal band, thus freeing the payload.
However, on STS-51 a miswiring in the pyro circuits caused BOTH the primary and backup pyrotechnic cords to be fired simultaneously. That had the effect of producing a lot of high-velocity metallic debris.
The result was this:

...the rupture of the containment tube, doubler plates, lead sheathing, silicone rubber extrusion and in the emission of carbon particles (smoke). One affected plate penetrated through the shuttle orbiter aft bulkhead insulation blanket and punctured a 1/8 x 1/2 inch hole in the aft bulkhead. Flight/crew critical equipment exists immediately behind the bulkhead. Other debris caused at least nine small tears in cargo bay insulation blankets, three gouges in wire tray covers and possibly a gouge in a thermal protection system tile.

To wrap up my post, I'll give one more example:
There was a wiring error in one of the APU's of space shuttle Atlantis, that went unnoticed for years. That is, until the launch of STS-79.
The rotation velocity of the APU shaft was determined via the use of three magnetic sensors. The OBC logic, which controlled the APU, used a voting scheme to eliminate readings from bad sensors: the read-out of two out of the three sensors had to concur to allow the APU to run. However, the wiring error caused one of the sensors to output a zero value for shaft rotation velocity at all times. However, this did not show up in telemetry.
During the launch of STS-79 one of the two remaining "good" sensors failed and started outputting an incorrect shaft rotation velocity of zero. The result was that the OBC voting scheme chose the mis wired sensor and the failed sensor as matches. Since both these sensors provided a shaft rotation velocity of zero, the APU was prematurely shut down by the OBC.
So, why wasn't this caught in testing? Well, first of all, the raw output of the sensors was not part of the telemetry sent from the vehicle. Also, the APU unit for ground testing didn't have the wiring mistake. That made it impossible to replicate the STS-79 APU problem on the ground. The APU was eventually partially disassembled in-situ before the wiring mistake was discovered.

[mn]

Since we're listing all wiring mistakes. There was also one of the Astra missions where the fairing failed to separate due to a wiring error.

https://spacenews.com/astra-blames-launch-failure-on-wiring-error-and-software-flaw/