6 ms·
The article links to NASA but here it is anyways. Let me skim it and I might add some additional information here but go and check out the first picture there y
by _Microft 5y ago
The article links to NASA but here it is anyways. Let me skim it and I might add some additional information here but go and check out the first picture there yourself - it is amazing. It could as well be an aerial photograph of a desert area on Earth by the looks of it.
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...
OK, so from the NASA article, it seems that they use an inertial measurement unit [0] (think an accelerometer/rotational sensor similiar to what your smartphone uses) that reads out heading and acceleration 500 times per second and sums it up to get the the helicopter's position. This is "dead reckoning" [1]) which unfortunately suffers from accumulating errors. To work around these accumulating errors, they sync their prediction to camera data thirty times per second by predicting how features visible on the surface should have moved in this time. So, sensor fusion [2], in a sense. The images are delivered with timestamps (I would have been surprised if they were not, to be honest) but one of the images went missing and for some reason, its timestamp was not. (Variable not cleared? Are they maybe using parallel queues to match images to timestamps (would be very weird, imo but I am no helicopter scientist?)). Either way, the following timestamps were now attributed to wrong images. I really wonder how that happened and hope they expand on that later. As the system predicts how far a feature in an image should have moved between frames, things were now considerably off (example: from the IMU prediction, a feature should have moved 1 unit per second but with a missing frame and the previous timestamp, it now looks as if it moved 2 units in a second) and the state gets updated with this wrong information.
Here is an interesting bit about safety margins from this article by the way:
Despite encountering this anomaly, Ingenuity was able to maintain flight and land safely [...]. One reason it was able to do so is the considerable effort that has gone into ensuring that the helicopter’s flight control system has ample “stability margin”: We designed Ingenuity to tolerate significant errors without becoming unstable, including errors in timing. This built-in margin was not fully needed in Ingenuity’s previous flights, because the vehicle’s behavior was in-family with our expectations, but this margin came to the rescue in Flight Six.
[0] https://en.wikipedia.org/wiki/Inertial_measurement_unit https://en.wikipedia.org/wiki/Inertial_measurement_unit
[1] https://en.wikipedia.org/wiki/Dead_reckoning https://en.wikipedia.org/wiki/Dead_reckoning
[2] https://en.wikipedia.org/wiki/Sensor_fusion https://en.wikipedia.org/wiki/Sensor_fusion
- isatty 5y agoI used to do GNC: it’s interesting that the slower sensor (the camera) affected the orientation that much (instead of just pos).
- jcims 5y agoIt sounds like the alignment error persisted for the remainder of the flight. Depending on the direction of the slip, the visual system would either record motion that wasn’t yet sensed by the IMU or it would record no motion when there was some recorded by the IMU. In both cases the control loops would likely try to correct for the discrepancy. The large control inputs sound a bit like ’integral windup’ in a PID loop where persistent error between desired and observed states are essentially summed over time resulting in larger control input (in the case of a drone this would be helpful for overcoming wind). Unless they box that in with limits you could easily get to a point where it starts flying like there’s a chimp on the yoke and either crash or saturate the navigation system and have it fall back/fail entirely.
- isatty 5y agoThe control systems behavior is less interesting to me (yes it could be windup or many other reasons for oscillation) than why the (u?)kf behaved this way. The single frame could have caused a time slip for the rest of the flight but usually there’s something that syncs timestamps before the filter acts on it. I hope we can get a technical postmortem.
- jcims 5y agoMe too, would be interesting (possibly by virtue of being boring). Hopefully one of these days we'll have a vehicle on Mars taking PRs on github.
- wongarsu 5y agoAn small error in position would lead to a larger error in speed estimate. To correct speed, you have to pitch the helicopter. But the speed keeps being wrong, leading to oscillation.