robust-rosin
care-o-bot/ac6a181: loss-of-control? Perhaps too much extrapolation?
From:
https://github.com/robust-rosin/robust/blob/66d87e642c69e5f4553337db7c4423b717981d0a/care-o-bot/ac6a181/ac6a181.bug#L3-L12
this appears to be more a BDO and SOFTWARE:CRASHING (both of which are present).
I don't quite understand how this got labelled with LOSS-OF-CONTROL.
Should this be re-evaluated?
Depending on the amount of extrapolation we're comfortable with: perhaps one could argue that at .launch time, cob_script_server/cob_console would crash due to ipython not being present, which would make it impossible for dependents to use the action interface to execute (script) commands.
Technically that could lead to loss-of-control, as if those scripts would be used to control something (which on a robot system is a safe assumption), that could not be possible any more.
According to our definition, loss-of-control is:
Failures that prevent the operator from either providing certain inputs to the robot or accurately observing the state of the robot, such as deadlocks or crashes in core components.
so this would seem to match that.
But none of this is reported for this particular bug (in fact: there is no issue at all).
I would say that LOSS-OF-CONTROL is incorrect.
You do not lose control of the robot, because you never had it in the first place; the crash occurs at launch/initialization.
I lean more towards SYSTEM:NONE, as is the norm for BDO faults.
In any case, as per https://github.com/ChrisTimperley/ese-robust/issues/30, I am changing the failure categories to the new proposal. Perhaps this would fit in the new SYSTEM:CRASHING category there.
Is https://github.com/robust-rosin/robust/issues/414 on similar lines?
@git-afsantos says:
You do not lose control of the robot, because you never had it in the first place; the crash occurs at launch/initialization.
Not a crash, but the driver fails during launch/initialization.
