Particle filter particle types.

[jwidauer]

I believe we have to implement some changes to the FilterBase class, since the particle filter makes no assumptions on the data type of the particles, but the virtual update(...) function requires a Eigen::VectorXd input.

Additionally we would have to change the SystemModelBase and MeasurementModelBase classes, since they also assume Eigen::VectorXd type inputs.

Imo it would be the easiest way to implement it using templates with the *ModelBase classes, which would then take the state type.

This then, of course, brings up the question of having the dimension functions in the *ModelBase classes, since I'm not entirely sure if they make sense in the context of general type states and measurements.

What are your opinions @ds-github, @igilitschenski?

[DominikSchindler]

Why should we not use Eigen::VectorXd? Can you give an example why the particle filter makes no assumptions on the data type of the particles?

I would prefer a solution where the same system/measurement model can be used for as much different filters as possible.

[jwidauer]

Since the pf only uses a system model and likelihood function to advance the state, it is possible to have, for instance, a bool or int in the system state, as well as a ´Eigen::VectorXd`. This is the case for the pf used in challenge one of the mbzirc.

I agree and I believe my suggested solution is the easiest to accomplish this. For the use of the EKF we already assume that a Linearized*Model is being used. Therefore we could template the *ModelBase class and inherit from it in the Linearized*Model class, using Eigen::VectorXd as a state/measurement type. Therefore not changing the EKF, but making the *ModelBase class more general.

[igilitschenski]

My first gut feeling is that the current Models should not be adapted to allow for bool types. This requires generalising to much code for one very specialised solution.

[jwidauer]

My proposal for the SystemModelBase would look something like this:

template<typename StateType>
class SystemModelBase {
  virtual StateType propagate(const StateType& state,
                              const StateType& input) const = 0;
  ...
}

And then for the LinearizedSystemModel:

class LinearizedSystemModel : public SystemModelBase<Eigen::VectorXd> {
  ...
}

So there would be no change for the EKF and the Linear*Model, as well as only small changes for the Linearized*Model. It would also allow the user to define composite state types where the state incorporates different types.

Of course then there is the question of the dimension getters in the *ModelBase classes and whether they are needed there or would be better somewhere else.