That can't still be the case these days, can it? Extremely tight mechanical and engineering tolerances are very expensive compared with merely 'very very' tight tolerances, and I'd imagine the difference between the two can be bridged with more intelligent software in place of "gyroscope + clock + maybe PID loop"?
Yeah, this reads like two people defining happy path subtly differently: one is saying the happy path is anything within acceptable strictly defined mission parameters and tolerances, the other thinks it is the sequence of steps that is expected to successfully execute the mission without ever encountering an exceptional situation (which is the conventional software view of the term), but there are exceptional situations which may be covered in the specification of the mission and so “on the happy path”.
In the case the system strays outside mission success parameters then aborting could make sense. The question there looks to be if the success parameters were defined too narrowly - it sounds like an error in specification that prioritizes landing in the required area over the possibility of landing at all.
The classic hardware engineering response of "we'll just fix it in software". Turns out fixing things in software is even more expensive because it's just so easy to make changes that a combinatoric number of changes sneak in.
Ohhhh yes. I've been on the receiving end of this one. Designing a system which can accommodate higher tolerances on some hardware components through software controls is one thing. Being handed a poorly performing piece of hardware and told to "just fix it in software" is quite another.
