extended mdp executor depends on door_pass

[hawesie]

Which adds a whole chain of unwanted dependencies for this package. This should be fixed someone.

[bfalacerda]

The dependency comes from the door prediction service. The modelling of door states in the MDP is quite specific, and done so that it is transparent to the user. While we could abstract it a bit, that would require a lot of effort and refactoring...

Also, why is door_pass on strands_apps? This problem would be solved if it went to strands_navigation, or if we created a new repo with specialised nav actions.

[hawesie]

It’s not just the repo location. door_pass requires things like speech and the webserver, which are essential for physically passing the door, but are unrelated to the prediction task. If we’re wanting people to use the mdp planning framework in other applications, I think this could be a bit of an issue (although perhaps this is no different from a dependency on topological navigation).

[bfalacerda]

well, topo nav makes more sense at least. We could have general door models, and just ask for an action server with a specific goal message type to be available at /door_pass or whatever.

The prediction part would have to be independent from the door passing action server though, also assuming that the door stats have a particular type

[Jailander]

Hi a question on a very related topic. I am working on a general tool for creating temporal models from any mongo query (or frongo), maybe we can generalise a way to define all the predictions you will need for navigation actions and a standard prediction service you can use?
Would this make sense and make all the navigation planning framework more usable for other people?

Now my problem I'm developing this tool (frongo) in strands_apps so we keep fremen independent from mongodb_store and viceversa, however, I was thinking that maybe it makes sense to create a new repo called Fremen tools (or more generical strands_spatio_temporal, or more generical and cool strands_space_time), and put all the prediction things in there. I think @marc-hanheide and @gestom might have a saying on this.

[marc-hanheide]

Why not making it part of fremen repo? The released packages will remain independent. And for the repo, it doesn't hurt, does it?

[Jailander]

yes I guess that would be alright since we have no metapackages in Fremen right now.