4 ms·
> Fortunately, JPL knows exactly what went wrong. > and while the flight uncovered a timing vulnerability that will now have to be addressed, it also confirmed
by qwertox 5y ago
> Fortunately, JPL knows exactly what went wrong.
> and while the flight uncovered a timing vulnerability that will now have to be addressed, it also confirmed the robustness of the system in multiple ways.
This is so important. Imagine if it would have crashed and damaged communications, that would have been the end of it. This extra step in engineering effort really payed off and gave Ingenuity a second life, and NASA a really good opportunity to learn important lessons and do further debugging.
Also, the article at mars.nasa.gov is a delight to read, with all the information one would like to know being in there. Not to mention that there is even a video for us to see.
- DrAwdeOccarim 5y agoI had the same response while reading it, too. Like, wow, this is telling me all the technical things I wanted to know about the situation. This is one reason I pay for IEEE, they do a great job relaying the facts in summary articles from the main source.
- dna_polymerase 5y agoFor those on mobile: https://mars.nasa.gov/technology/helicopter/status/305/surviving-an-in-flight-anomaly-what-happened-on-ingenuitys-sixth-flight/ https://mars.nasa.gov/technology/helicopter/status/305/survi...
- lucb1e 5y agoNote that this robustness seems to refer to just the physical build, not that the code had a glitch yet somehow saved the day. > Flight Six ended with Ingenuity safely on the ground because a number of subsystems – the rotor system, the actuators, and the power system – responded to increased demands to keep the helicopter flying. In a very real sense, Ingenuity muscled through the situation, and while the flight uncovered a timing vulnerability that will now have to be addressed, it also confirmed the robustness of the system in multiple ways. The code being robust and self-correcting, rather than the increased demands coincidentally being within tolerance levels, would have been more interesting or laudable.
- ethbr0 5y agoAfaict, JPL and NASA (and subcontractors) have a very strong historical knowledge base of building maximally-robust systems with limited redundancy hardware (in the sense of not having an unlimited mass budget for more hardware). But then again, they've been working with semi-autonomous systems about as long as anybody. https://newatlas.com/apollo-11-guidance-computer/59766/ https://newatlas.com/apollo-11-guidance-computer/59766/
- foobarbecue 5y agoThe fact that the code disables optical nav at low altitudes is also one of the reasons it landed safely.
- snewman 5y agoYes, but in this case that was just good luck. As the article mentions, the low-altitude behavior is because of concerns regarding dust. It was not intended to provide robustness in the face of glitches in the optical navigation system.
- shkkmo 5y agoDust concerns were one reason, but avoiding glitches and ensuring the smoothness of position data is another. > Then, once the vehicle estimates that the legs are within 1 meter of the ground, the algorithms stop using the navigation camera and altimeter for estimation, relying on the IMU in the same way as on takeoff. As with takeoff, this avoids dust obscuration, but it also serves another purpose -- by relying only on the IMU, we expect to have a very smooth and continuous estimate of our vertical velocity, which is important in order to avoid detecting touchdown prematurely. https://mars.nasa.gov/technology/helicopter/status/298/what-were-learning-about-ingenuitys-flight-control-and-aerodynamic-performance/ https://mars.nasa.gov/technology/helicopter/status/298/what-...
- qwertox 5y agoI wonder if, had Ingenuity disabled the visual system upon noticing timestamp conflicts, the use of the IMU alone would have made the entire situation a more safe one.