Earth Notes: Radbot Origin Myth 6 - Setbacks (2016)

Updated 2022-10-10.

"Setbacks" - Is it a bird, is it a plane? No, it is a radiator robot with AI! #webcomic

panel 1: should we stick with tried and true?

panel 7: we've run into another setback, amigos!

Setbacks? We've heard of those! Maybe not getting stuck in the astral plane... Instead, horribly high failure hardware rates and serious software bugs. And physical and UI design faults, oh yes!

(We had well over 90% good boards with an earlier 'REV2' design. That flipped to over 90% bad boards with the 'REV7' inside our TRV1 prototype. It turned out that the "do not fit" load capacitors on the watch crystal got fitted. We've had that happen again! Now we mark the caps as 0pf.)

Oh, and the fact that people are weird and don't do what you expect them to do. I mean obviously the overhead camshaft should tuck under tab "B", right?

Those require replacements in the field, or loss of trial data. Or other bad things. One just has to grin and bear IoT...

Confused? You will be!

Tune in next time to find out more about Radbot's launch!

Back Story

The pain of safe code development for embedded systems, ie 'smart' hardware (Testing times: Between some IoT code and a hard place) is very real:

In smaller companies and startups the pain can be intense. I remember a job before going to university where I sweated for a week over hardware that stopped working just before a critical demo in the US. It was for a robot toy for a couple of the world's largest purveyors, and no one would have died... except for my employer. We slept under the desks (my landlady thought I must be out doing drugs and summoned scary relatives to hound me) and we tore out our hair, some of which may even have turned grey.
It all turned out to be down to one tiny misplaced wire on our development electronics board, discovered at the 11th hour when rechecking "everything".
We did the demo, the project continued, and my employer lived.

Radbot has suffered similar hardware and software bugs. One case involved a stack overflow. (If only someone could create a Web site for solving problems something similar ... oh wait ...) It lost us a lot of data but had a trivial software fix. Then a very long drawn out code rewrite that took months to nail. That is why I am strongly in favour of extensive (unit and other) tests and CI (Continuous Integration), just as I am for 'bigger' software. Never mind the techie grumbling; the pain can otherwise prove fatal. The increased confidence those tests can provide when refactoring allow much bolder code and functionality improvement. Also fab.

Actively assess risks coming down the pipe. Decide which are to be avoided and which just have to be rolled with. Avoid the pointless ones. It's all part of the fun. Setbacks happen despite the best-laid plans of mice and men. How you then deal with them is key.