Interface with POMDPs belief updaters

Question

Interface with POMDPs belief updaters

Opened this issue 3 years ago · 4 comments

The ParticleFilters.jl package is excellent because it can also interface with the POMDPs belief updaters—I'm wondering if this is something you've intended for this package too.

Answer 1 · 2021-09-05T19:20:08.000Z

I think this is en excellent idea and I believe it has been discussed before but nobody has found time to do it so far. If you have some spare cycles I'd be glad to review a PR on this.

Answer 2 · 2021-09-05T19:21:02.000Z

For reference: https://juliapomdp.github.io/POMDPs.jl/latest/def_updater/#Defining-a-Belief-Updater

Answer 3 · 2021-09-05T19:43:06.000Z

I just did some superficial browsing of the source code and it seems that would have to make a semi-breaking change to move from GaussianFilters.update to POMDPs.update. This would only be semi breaking because the signature is exactly the same.

I'm wondering whether we should use the opportunity (before POMDPs 1.0) to factor out the belief updater abstraction into its own package. This at least would make it easier to also convince other belief updater packages to implement that interface without having to pull in a dependency on the full POMDPs.jl package; e.g. LowLevelParticleFilters.jl (cc @zsunberg)

Answer 4 · 2021-09-08T01:32:25.000Z

Hmmm... why would switching to POMDPs.update be breaking? If the signatures are really the same, then you can just make GaussianFilters.update the same as POMDPs.update. If they are not the same, it totally makes sense to have both - POMDPs.update can just be an "under the hood" connection to POMDPs.jl that allows Kalman Filters to work with POMDPs, but it does not need to be exposed as a primary part of GaussianFilters.jl for those who want to use it separately from POMDPs.jl.

I don't think POMDPs.jl is too heavy of a dependency. Its dependencies are pretty light https://github.com/JuliaPOMDP/POMDPs.jl/blob/master/Project.toml, and if someone wants to make a belief updater that works for a POMDP, they will need to import transition and observation anyways, so I don't think it is that helpful to break it up.

I think it is better to keep POMDPs.update as it is. It is certainly still possible for packages like LowLevelParticleFilters to have compatibility with POMDPs.jl in addition to their own interface that makes sense for them. If we did make another package like FiltersBase.jl, then we could put glue somewhere to make any FiltersBase updater work with POMDPs.jl