Clarifying StateStructure
We have a non-trivial design regarding the StateStructure
in wolf.
In one hand, Problem
has an state_structure_
not sure if built from the motion providers or user defined via YAML.
In the other hand, MotionProvider
has one as well but also ProcessorTracker
(not sure why and if it is used..).
Now, the frames are not required to be of the same structure, so maybe Problem::state_structure_
is not needed.
I imagine two meanings of "state structure" from the processor point of view:
- Required structure of the frames to be able to work. This may apply to all the processors.
- Structure of the state that is able to compute. This applies to motion provider processors (inheriting from
MotionProvider
).
I'm not sure if there is a case for 1 (apart from PO that is the minimum structure). Also, I don't know how to manage this since the Problem::state_structure_
does not guarantee that a frame contains this structure. So, in my opinion, the case of a processor that requires a key 'X' and is not capable of filling it, cannot be addressed in a generic way and should be solved in the derived class (either raising errors or filling with a prior..).
Summarizing, my proposal is to remove state_structure_
from Problem
, YAML and ProcessorTracker
. This implies that the the functionality of Problem::getState()
may change a little bit (for instance, requiring explicit structure or changing the default to "PO").