Due to bugs #423 and #424,[1,2] I've been playing with an extended state
model for RTT components. The bugs note that no 'error' state is available
and that the current model is not ideal for event-driven components.
I have a proposal for RTT 1.4 which offers a first, but partial, solution to
these two bugs. A new state diagram is shown in attachment.
First, there is the addition of a 'Fatal' error state, which is entered by
calling 'fatal()' which leads to stopping the component immediately (calling
stopHook() ). A 'user' intervention is required which calls 'reset()'. If
that succeeds, the component becomes stopped again, otherwise, it becomes
pre-operational and a full configuration is required.
Next, there is an added 'active' state which is for event and command
processing only. No updateHook is called. It is identical to the 'active'
state of an Orocos state machine.
Finally, there are two additional 'run-time' error states: RunTimeWarning and
RunTimeError, which are shown in the second attachment. The idea is here that
there can be intermittent errors as well, which can be solved by the
component itself and eventually disappear. In these cases updateHook() (in
case of warnings) or errorHook() (in case of errors) are called upon each
trigger (period, event,...) and the component just keeps running.
I'm tempted to apply this on the rtt-1.4 branch, allthough this would delay
this release with another month (in theory that is). The changes are
backwards compatible with any RTT 1.x release, but some new functions have
been added, which might name-clash with existing user code.
These states have also been inspired with the OMG Robotics Technology
Component (RTC) and bring the RTT component model closer to that spec.
Another thing this spec proposes is to allow rate changes (going from non
periodic to periodic threads or changing the execution period at run-time),
which is not such an unsane feature, but currently (almost) impossible in the
RTT. The division between SingleThread and PeriodicThread was probably a
choice limiting flexibility, heck, even exposing this distinction to the user
is confusing, but that's for a future bug report.