Author Topic: Japan's ispace reveals "HAKUTO-R" Mission 1 Lunar Landing crash results  (Read 2009 times)

0 Members and 1 Guest are viewing this topic.

Offline floobydustTopic starter

  • Super Contributor
  • ***
  • Posts: 6961
  • Country: ca
ispace Announces Results of the "HAKUTO-R" Mission 1 Lunar Landing 26 May, 2023
Landing Anomaly Identified for Future Mission Improvements

TOKYO—May 26, 2023—ispace, inc., (ispace) a global lunar exploration company, announced today that it has reviewed and completed the analysis of the flight data from its HAKUTO-R Mission 1 landing sequence on April 26, 2023. The flight data was obtained by operations specialists at ispace’s Mission Control Center in Nihonbashi, Tokyo.

The analysis reveals that the lander fully completed the entire planned deceleration process, slowing to the target speed of less than 1 m/s in a vertical position at an altitude of approximately 5 kms above the lunar surface. Although the lander did not complete a soft landing, the cause has been identified and improvements are being incorporated into Mission 2 and Mission 3.

On April 26, 2023, at 00:40 Japan Standard Time, the lander began the descent sequence from an altitude of approximately 100 kms above the lunar surface. At the end of the planned landing sequence, it approached the lunar surface at a speed of less than 1 m/s. The operation was confirmed to have been in accordance with expectations until about 1:43 a.m., which was the scheduled landing time.

During the period of descent, an unexpected behavior occurred with the lander’s altitude measurement. While the lander estimated its own altitude to be zero, or on the lunar surface, it was later determined to be at an altitude of approximately 5 kms above the lunar surface. After reaching the scheduled landing time, the lander continued to descend at a low speed until the propulsion system ran out of fuel. At that time, the controlled descent of the lander ceased, and it is believed to have free-fallen to the Moon’s surface.

The most likely reason for the lander’s incorrect altitude estimation was that the software did not perform as expected. Based on the review of the flight data, it was observed that, as the lander was navigating to the planned landing site, the altitude measured by the onboard sensors rose sharply when it passed over a large cliff approximately 3 kms in elevation on the lunar surface, which was determined to be the rim of a crater. According to the analysis of the flight data, a larger-than-expected discrepancy occurred between the measured altitude value and the estimated altitude value set in advance. The onboard software determined in error that the cause of this discrepancy was an abnormal value reported by the sensor, and thereafter the altitude data measured by the sensor was intercepted. This filter function, designed to reject an altitude measurement having a large gap from the lander’s estimation, was included as a robust measure to maintain stable operation of the lander in the event of a hardware issue including an incorrect altitude measurement by the sensor.

One major contributing factor to this design issue was a decision to modify the landing site after critical design review completed in February 2021. This modification influenced the verification and validation plan despite numerous landing simulations carried out before the landing. ispace as the mission operator maintained overall program management responsibility and took into account the modifications in its overall analysis related to completing a successful mission. It was determined that prior simulations of the landing sequence did not adequately incorporate the lunar environment on the navigation route resulting in the software misjudging the lander’s altitude on final approach.

The analysis reveals that the cause of the lander’s failure to make a soft landing was due to the software, especially in the phase just prior to landing. This information will be incorporated into software design, as well as upgrades and expansion of the scope of preparatory simulations of the landing sequence for our future missions, including Mission 2 and Mission 3, to improve the accuracy of landing sequences.

Based on the fact that communications will not be reestablished with the lander, it has been concluded that the completion of the Mission 1 Milestones Success 9 (completion of the lunar landing) and Success 10 (establishment of stable conditions after landing), could not be achieved, and customer payloads could not be operated after the landing.

“Mission 1 demonstrated a great deal of technical reliability, as our lander reached the lunar surface just prior to landing. Now, we have been able to identify the issue during the landing and have a very clear picture of how to improve our future missions. While it is unfortunate that we were not able to fully meet the expectations of all our stakeholders, including our customers, all of us at ispace are proud of what we accomplished in Mission 1 and are very positive about what we can accomplish,” said Takeshi Hakamada, Founder and CEO of ispace. “We have already begun work on Mission 2 and Mission 3. We are prepared to face the challenges and make every effort to improve. We will ensure that the valuable knowledge gained from Mission 1 will lead us to the next stage of evolution. We believe that this is our commitment and our duty to all our stakeholders. ‘Never Quit the Lunar Quest’ In this spirit, we will continue to move forward.”

During Mission 1 the HAKUTO-R lunar lander completed Success 1 through Success 8 of the Mission 1 milestones. The lander was able to withstand the harsh mechanical environment of both the launch and deployment phases without sustaining damage to any of its elements. It then withstood a lengthy deep space cruise demonstrating its flight readiness. In addition, the lander performed well through multiple orbit control maneuvers, indicating that it can be operated in Mission 2 using the same Series 1 model as in Mission 1, without the need for any major modifications. The thermal design, communications, and electric power demonstrated functionality as planned, and based on analysis of the flight data, a more efficient operation can be achieved in Mission 2. At this time, there are no changes to the launch schedule for Mission 2 (scheduled for 2024) and Mission 3 (scheduled for 2025)."
------------------------------------

It appears to be a S/W algorithm mistake for coping with altitude sensor errors, got confused seeing a crater rim and re-zeroed by 3km.
 

Offline Ed.Kloonk

  • Super Contributor
  • ***
  • Posts: 4000
  • Country: au
  • Cat video aficionado
Yeah. Saw that.

Seems the software gave up on the 'bogus' sensor readings too easily.
iratus parum formica
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 6697
  • Country: gb
  • Electronics Hobbyist & FPGA/Embedded Systems EE
Harsh when the very software you put in to avoid a bogus sensor reading, causes the vehicle to crash. 

It seems like redundancy didn't help them either, they indicate having multiple sensors, but if passing over the cliff area triggered the software to apply the filtering algorithm, it seems to have done it on all channels.
 

Offline Ed.Kloonk

  • Super Contributor
  • ***
  • Posts: 4000
  • Country: au
  • Cat video aficionado
I know they are gearing toward the full-automate Mars missions. But the modern moon missions have had an advantage that the Apollo missions didn't have. The technical possibility to put into the code the ability to ask those on earth for help.

"I am running out of juice and the Lunar surface is not forthcoming"

I mean, don't get me wrong. But this is the third thing to plunge into the dirt. FFS. Phone home.

Even Tom Hanks asked for those on the ground to check the sums.
« Last Edit: May 28, 2023, 12:41:56 am by Ed.Kloonk »
iratus parum formica
 

Offline floobydustTopic starter

  • Super Contributor
  • ***
  • Posts: 6961
  • Country: ca
You have a critical sensor reading... and it suddenly jumps in value. What does your software do?
1. Ignore it, keep on rollin'
2. Red Alert, stop everything
3. Revert to the model's value
4. Use a safe default value

It also would (premature or late) start the S/W state machine for the descent. Parachute deploy (if Mars) or starting thrusters etc.
I think here the second problem was moving the landing site to a crater and the model seems to have not been updated for things above/below surface.

Schiaparelli Mars lander went splat from a saturated IMU giving bad attitude angle "cosinus of angles > 90 degrees are negative", which the radar altitude calc uses, came up with a negative altitude with no check for plausibility of that and 37 seconds late (splat) before thrusters would be turned on.

I find it strange we have some supposedly very smart people, yet they are bungling a single sensor reading.
 

Offline coppercone2

  • Super Contributor
  • ***
  • Posts: 9421
  • Country: us
  • $
can you shoot a smoke rocket or something that leaves a trail that is obvious where the ground is for a sensor? then its following a shaft almost.

but I think the moon needs beacons so they stop doing everything from above.
« Last Edit: May 28, 2023, 03:18:43 am by coppercone2 »
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7369
  • Country: nl
  • Current job: ATEX product design
Yeah. Saw that.

Seems the software gave up on the 'bogus' sensor readings too easily.
Unreliable software thinks that hardware doesn't work properly. Hardware works properly.
Also, let's change last minute where we land.
So management and software engineers. Every time.
 

Offline iMo

  • Super Contributor
  • ***
  • Posts: 4766
  • Country: nr
  • It's important to try new things..
The solution is to have enough fuel in order to be able to decent with that 1m/s speed from any altitude less or equal than the deepest crater on the Moon's surface :)
 

Offline Tomorokoshi

  • Super Contributor
  • ***
  • Posts: 1212
  • Country: us
Interesting to compare and contrast with the problems encountered during the landing sequence of Apollo 11.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14447
  • Country: fr
Well, from what I can tell, this is not a software bug, but an overlook while specifying - and testing - it.
One of the most common causes of malfunctions with software-based systems. Assuming the conditions they will run under are limited to the very few that have been thought about in some office, for probably not long enough.

 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7369
  • Country: nl
  • Current job: ATEX product design
Well, from what I can tell, this is not a software bug, but an overlook while specifying - and testing - it.
One of the most common causes of malfunctions with software-based systems. Assuming the conditions they will run under are limited to the very few that have been thought about in some office, for probably not long enough.
Yeah, they should have specified:
Make it not crash. :-//
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6186
  • Country: ro
The most likely reason for the lander’s incorrect altitude estimation was that the software did not perform as expected. Based on the review of the flight data, it was observed that, as the lander was navigating to the planned landing site, the altitude measured by the onboard sensors rose sharply when it passed over a large cliff approximately 3 kms in elevation on the lunar surface, which was determined to be the rim of a crater. According to the analysis of the flight data, a larger-than-expected discrepancy occurred between the measured altitude value and the estimated altitude value set in advance. The onboard software determined in error that the cause of this discrepancy was an abnormal value reported by the sensor, and thereafter the altitude data measured by the sensor was intercepted. This filter function, designed to reject an altitude measurement having a large gap from the lander’s estimation, was included as a robust measure to maintain stable operation of the lander in the event of a hardware issue including an incorrect altitude measurement by the sensor.

 :-\

Offline coppercone2

  • Super Contributor
  • ***
  • Posts: 9421
  • Country: us
  • $
Well until they get air traffic control up there on the ground like at an air port you won't have spectacular landing success %

you need beacons, redundant systems, local ground control, etc.

IMO the whole situation is totally ass backwards until they get a lunar port up and running. I bet a lit landing zone would do real nice too, with flashing lights. I don't think we will ever have "good" expectations for remote probes.
« Last Edit: May 29, 2023, 08:48:22 am by coppercone2 »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6186
  • Country: ro
you need beacons

That's  a good idea.  Beacons would be easy to set, IMO, certainly easier than landing a big vessel.  Beacons with unique ID can be dropped at random on the Moon surface, so the beacons can be read/update their location from the Moon orbit, or they can determine their position relative to each other.

The beacons doesn't have to work 24/7, can be activated remotely only when needed.  There are nuclear batteries that can last for hundreds to thousands of years.

Might be also useful to set a few GPS satellites orbiting the Moon.
« Last Edit: May 29, 2023, 09:06:26 am by RoGeorge »
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7369
  • Country: nl
  • Current job: ATEX product design
I think Lockheed Martin wants to make a lunar GPS with a few satellites. Something like 6. Plus they would be communication relays.
Plus ESA wants to make one as well.
 

Offline coppercone2

  • Super Contributor
  • ***
  • Posts: 9421
  • Country: us
  • $
I still think they would benefit from a ground beacon that has cameras and radar and some LORAN like thing going on as a backup. Ground reference is always gonna do something IMO. And you can armor them a little bit too compared to a sat.

And the other thing too is you can start putting functions in em to do stuff like clean solar panels (car wash thingy), recharge cells, replace modules.. I guess thats outside the scope of a beacon though.
« Last Edit: May 29, 2023, 06:13:04 pm by coppercone2 »
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6821
  • Country: va
Well, from what I can tell, this is not a software bug, but an overlook while specifying - and testing - it.
One of the most common causes of malfunctions with software-based systems. Assuming the conditions they will run under are limited to the very few that have been thought about in some office, for probably not long enough.
Yeah, they should have specified:
Make it not crash. :-//

How would you design the code to cope with detecting a sensor failing, yet not failing the sensor when the data is suspect?
 

Offline floobydustTopic starter

  • Super Contributor
  • ***
  • Posts: 6961
  • Country: ca
1878 "It was the foolish fashion for the fine gentlemen of Horace Walpole’s time to carry two watches—a fashion which that wit explained thus:— “One of them is to show what o’clock it is, and the other what o’clock it isn’t.”

Judging when a sensor has failed due to a jump in readings, compared to flying over a cliff... it seems pointless because even then you have no alternate sensor or worse yet it also reads a jump and gets disqualified. SPLAT.
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6821
  • Country: va
Quote
Judging when a sensor has failed due to a jump in readings, compared to flying over a cliff... it seems pointless because even then you have no alternate sensor or worse yet it also reads a jump and gets disqualified. SPLAT.

Well, presactly. Yet the software peeps are being made out to be rubbish:

Quote
Unreliable software thinks that hardware doesn't work properly. Hardware works properly.
Also, let's change last minute where we land.
So management and software engineers. Every time.

Given the hardware, let's hear how tszaboo would solve everything.
 

Offline coppercone2

  • Super Contributor
  • ***
  • Posts: 9421
  • Country: us
  • $
Do modern planes have the ability to use data from the tower to land? Like a computer link between the radar of the air port and the runway?

I am not sure actually, I don't know that much about aviation. But I would assume that if a plane has a malfunctioning altimeter or whatever, they could ask the tower to use their data which would be pretty good and at least offer a better landing outcome then eyeballing it? And that if GPS went out for whatever reason, they can find the air port based on radio transmissions. Theoretically someone could give them data using a broom stick and a walki talkie too.
« Last Edit: May 29, 2023, 08:29:13 pm by coppercone2 »
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6821
  • Country: va
Quote
at least offer a better landing outcome then eyeballing it?

I am not a pilot, but I think you can manually land a decent sized plane via eyeballing. Justification for this stance is the FAA Airworthiness Directive which was rushed in when 5G looked like it would be turned on before the radio altimeter manufacturers got their act together. There were 80 airports where this directive took effect, and the one linked to here covers Boeing 737 aircraft. The impact (sorry!) wasn't that they couldn't land without the altimeter but that they would take longer to come to a halt when doing so - there are several systems (like auto-brakes) which depend on the altimeter, so not having it would affect those systems.

Maybe an actual pilot can comment on this. I had previously assumed you could land via eyeball (but wouldn't if you didn't have to). Might be a bumpy landing since you're a long way up, but the landing gear has shocks :)
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7369
  • Country: nl
  • Current job: ATEX product design
Quote
Judging when a sensor has failed due to a jump in readings, compared to flying over a cliff... it seems pointless because even then you have no alternate sensor or worse yet it also reads a jump and gets disqualified. SPLAT.

Well, presactly. Yet the software peeps are being made out to be rubbish:

Quote
Unreliable software thinks that hardware doesn't work properly. Hardware works properly.
Also, let's change last minute where we land.
So management and software engineers. Every time.

Given the hardware, let's hear how tszaboo would solve everything.
First of all, this comes out on top of a series of failed space missions that were wrecked by software. While for example Opportunity was operational for way longer than the hardware was designed for. In fact they almost lost it several times due to software issues. So you just have to trust the hardware better than firmware. Instead of discarding the reading and landing half a kilometer high, maybe just use the reading.
But if you are actually interested, they would need to tweak some parameters in their Kalman filter.
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6821
  • Country: va
Quote
maybe just use the reading

And maybe nosedive into the crust. I don't think there's a programming language that uses hindsight.
 
The following users thanked this post: tom66

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7369
  • Country: nl
  • Current job: ATEX product design
Quote
maybe just use the reading

And maybe nosedive into the crust. I don't think there's a programming language that uses hindsight.
As I read, that's exactly what it did, due to software.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf