Right now FusionCore uses a constant velocity + acceleration motion model and it works well for most ground robots. But for platforms with different dynamics like skid steer, tracked vehicles, boats, or aerial vehicles, a custom motion model would reduce filter divergence and improve how covariance propagates through the predict step.
The idea is a simple plugin interface where you provide your own predict function and process noise matrix. Bundled plugins would cover the common cases (differential drive with a known wheelbase, Ackermann) and the current CVA model stays as the default so nothing breaks.
Something like:
class MotionModel {
public:
virtual Eigen::VectorXd predict(const Eigen::VectorXd& x, double dt) = 0;
virtual Eigen::MatrixXd processNoise(const Eigen::VectorXd& x, double dt) = 0;
};
And in YAML:
fusioncore:
ros__parameters:
motion_model: "fusioncore_models::DifferentialDrive"
motion_model_params:
wheelbase: 0.55
This has been an open request in robot_localization since 2019 and was never implemented there. FusionCore's architecture makes it a lot more tractable since the state vector is fixed and there's no per-sensor config matrix to deal with.
Not urgent, but would be a meaningful differentiator for non-standard platforms.
Right now FusionCore uses a constant velocity + acceleration motion model and it works well for most ground robots. But for platforms with different dynamics like skid steer, tracked vehicles, boats, or aerial vehicles, a custom motion model would reduce filter divergence and improve how covariance propagates through the predict step.
The idea is a simple plugin interface where you provide your own predict function and process noise matrix. Bundled plugins would cover the common cases (differential drive with a known wheelbase, Ackermann) and the current CVA model stays as the default so nothing breaks.
Something like:
And in YAML:
This has been an open request in robot_localization since 2019 and was never implemented there. FusionCore's architecture makes it a lot more tractable since the state vector is fixed and there's no per-sensor config matrix to deal with.
Not urgent, but would be a meaningful differentiator for non-standard platforms.