Low-level API

[jacobnzw]

Sometimes the use-cases are complicated and require access to lower-level routines. Even though the toybox has been written primarily to run relatively simple experiments, having lower-level API would definitely help out, because higher-level API can be built using the lower-level one. The higher-level APIs are syntactically parsimonious and user-friendly, whereas the lower-level ones allow for finer control.

The lower-level API is already in place (at least partially), because the moment transforms being the building blocks of filters are contained in mtran package.

Constraints of the SSMToybox are mainly tied with the StateSpaceInference class, where the whole update/smoothing machinery is contained. The measurement and smoothing updates should be disentangled.

Low-level API might enable:

• several prediction steps between updates
• online processing of measurements (one at a time)
• update of discretization period in asynchronous data processing, which affects state covariance and the state transition function
• interacting multiple models (IMM)
• sensor fusion
• if the sensor is moving (radar on a ship), the measurement model has time-varying parameters
• when some state component is an angle, it needs to be kept normalized after subtraction/addition takes place (like in sigma-point transforms or when innovation is computed during measurement update, see Udacity's EKF/UKF coverage).

[jacobnzw]

I'm starting to think this should be the last thing to worry about, because the primary goal of the SSMToybox is to support my research - nothing else. Although case could be made that the moment transforms in mtran are well-suited building blocks for applications like SLAM, IMM and multi-sensor filtering, that is not the aim of the SSMToybox. The issue requires detailed knowledge of each potential application. It may turn out, I suspect, that it's counter-productive and perhaps even impossible to design an all-purpose building blocks that will suit most applications.