The android camera API for example will tag every frame with the timestamps and exposure settings it was captured with. Unit and integration tests can simulate dropped frames and verify the algorithm still runs as it should.
I would guess they tried to go for direct camera hardware access and ended up writing their own logic to schedule frames, and it contained a bug.
I'm also reasonably certain that the drone isn't running Android, and that not doing so is the correct design choice.
I don't think anyone is seriously suggesting the thing should run android.
But if you are writing something yourself then looking at what existing libraries already (and more importantly their test suites!) do is a good idea.
Maybe they did and maybe they didn't in this case, hard to know with the data available.
We have plenty of faux-mars environments to practice these techniques on. NASA even has their own.
many of the toy indoor-use drones use such techniques for attitude/altitude-hold features when under a roof.
this isn't magic. Image processing isn't a wholly unknown field when under the influence of Martian gravity.
It's a staggering achievement, and a testament to humankind's ability to wrangle technology, but -- to be frank here -- visual odometry is technology from 1960s era spy planes, not beyond-human voodoo.
Sometimes errors are stupid ones, even if the stupidity is causing problems a zillion miles away on distant unknown frontiers being first-explored by human kind.
tl;dr : This visual odometry problem isn't a space problem, it's a computer science problem -- one that has been encountered by numerous people even here on earth.
The repercussions of such a simple non-space-problem might very well turn into space problems when the craft crashes, however -- and that's a damn shame given that this particular set of problems has been encountered-and-fixed by numerous earthlings over and over again.
super tl;dr : as an only half-informed-participant in this discussion I bet this problem is NIH-syndrome-related, a problem NASA has encountered a lot in the past, a problem that's entirely managerial and very hard to eradicate.
Considering Qualcomm never releases their kernel sources, I am really worried that NASA might have been forced to use a modified Android system.
Most likely they just used the specific kernel version with closed binary blobs from Qualcomm for a typical embedded Linux, not the full Android system.
In the context of a space helicopter, I’d guess that deep understanding and ownership of each software component is super important when you’re likely to have to support a debug it from millions of miles away. At this scale, and in this context, doesn’t “rolling your own” critical components, in some cases, make sense?