Something that’s been bugging me lately is robustness.
There are a few components that can fail catastrophically.
As this acquires all sensor data, so if it fails, we’re flying blind. In order to remedy this, some manner of redundant Arduino could be used. The Pi has at least 2 native serial ports, so that would be achievable.
If the Pi fails, we’re pretty dead. It drives the screen. One solution would be to have two running and try to combine the signals from both Pis to the board. HDMI isn’t the best protocol for it, being encrypted and stuff like that.
This is a cheap board, it’s likely to fail in some way. Failure would be very bad, it would kill any output. I’d wager this fails before the Pi or Arduino. Is dual board an option? It could be. The output is a simple ribbon.
The screen could fail too. In my lifetime of many monitors I’ve not seen one fail after successful running for a while. There’s nothing much that can be done about the failure. Having dual screens wouldn’t do much.
Connections can come loose. After speaking to a friend who’s also doing things with Arduinos, perhaps I should use automotive grade locking headers.
A likely source of trouble would be the vibrations. Designing the frame so that the electronics live suspended from some rubber mounts would possible extend the lifetime.
This is a tricky category. What’s even worse than total failure? Getting a wrong result and not knowing about it.
The most likely problems here would be incorrect calibration, some kind of wiring harness problems. As we’re doing ADC, it’s possible that we get some outside interference. Not unhead of to have some random errors. This can be generally filtered out in the Pi.
If there is a more serious failure, like a non response, the Arduino can be soft reset by the Pi through GPIO. Perhaps cutting the Vin through GPIO would be an option too.
The Pi would be best served by general defensive programming and thorough error checking. As we were merely monitoring, a hard fail is an option. Providing we can restart quickly, running the executable in a loop could be acceptable. There isn’t a great deal of variance, so once we’re up an running there really shouldn’t be any reason for failure.
A reset would be possible here. There is a simple control board with buttons. Problem being is that we wouldn’t know when to do it.
If this fails, we can’t detect it, so that’ll be up to the driver.
Had better solder well..
Whenever something fails in any of the Star Trek series fails, there always seems to be an explosion. Yet I don’t think that other than fuel related problems, any space craft so far has had any problems with exploding consoles. Why would you even put something that could explode so close to the interface? Wouldn’t you keep that in a Faraday cage some distance then operate it with servos?
This especially bugs with be Star Trek: Enterprise. The NX01 is your first prototype. Before you send something so precious out, wouldn’t you sort something like that out. In fact, once you have discovered it, why wouldn’t you solve in within several hundred years?