[ncmncm]

The control system is clearly designed wrong. Navigation input should not be able to affect the closed-loop control system directly. It should affect only the calibration, incrementally. If that had been done, there would have been no flight instability, just disagreement between the IMU and navigation about how far they had flown.

There are certainly people involved in the project who could have explained this to them. I hope they are learning fast.

[baybal2]

> There are certainly people involved in the project who could have explained this to them. I hope they are learning fast.

This is how nearly all modern high-end quadcopter drones fly - navigation using optical flow camera sensors short circuited directly into attitude/motor control loops.

I guess there is not a small chance they entrusted helicopter autonomous operations programming to people with quadcopter background.

[ncmncm]

It is one thing to feed averaged relative motion into the control system, entirely another to feed in absolute position. The flight instability in response to navigational position error is incontrovertible proof of a mistaken design. Fixing the off-by-one coding error just papers over the design error. Testing clearly failed to detect the mistake.

I would not be at all surprised to learn that commercial quads share the design mistake. I was surprised to learn that NASA professionals copied it into a Mars probe. But, notably, not into the vehicle that delivered the lander.

[londons_explore]

Put tape over the downward facing camera on almost any quadcopter and you'll soon find out why...

It turns out sideways drift accumulates very quickly - and so quickly that unless you are a very practiced drone operator its very hard to compensate for by hand.

GPS compensates somewhat, but obviously that isn't available on mars (or indoors).