[pose_initialiser] Moved to strands_morse

[cdondrup]

The pose_initialiser is used in some of the simulation environments to set the initial robot pose for the navigation. Accroding to @Jailander it could be used on the real robot as well but is not atm. My question is, should we move it to strands_morse (which needs some proper clean-up then) or strands_apps?

Maybe @hawesie @marc-hanheide @nilsbore @bfalacerda have an opinion on that?

Edit: Maybe putting it into strands_navigation makes most sense.

[Jailander]

No I don't think strands_navigation is the place for it, I just mentioned that when I created the script @marc-hanheide suggested putting it in strands_utils as it was useful anywhere, how ever I think that for something like this to be useful in the robot it would need to be reimplemented as a service/action_server so it can be called by an outside source of localization (e.g. Topological localization system).

[Jailander]

@gestom (yes I am his github interface) just mentioned that he was using something like this for recovery actions when the bash script was being used in Linda for patrolling so he used it as a recovery action when he saved the robot pose rebooted the robot and the initialised the pose with saved file. I think we can put it in strands_navigation and implement the service and/or action service.

[cdondrup]

As I said, I think strands_navigation is the best call but then I don't really know what this does exactly and if there are any alternatives.
strands_morse would have the disadvantage of needing to restructure the whole repository first because it is atm just one single package.

In the end I think it's your call.

[Jailander]

when you say your you mean me? in that case yes I will move it to strands_navigation

[bfalacerda]

This package is not catkinized and it seems to be pretty useless to me. Do we really need to run an initializer that just creates a pose message and publishes it once? If strands_morse depends on this, then we should just add a method there that does the pose initialization, and remove this package altogether.

I like the post-reboot reinitialization of amcl btw, but what we have in the pose_initializer package isn't really useful for that either, the main part of such a behaviour would be reading poses and saving them to a file and that's not there.

[Jailander]

well we were using it for starting simulations too as @cdondrup mentioned, It is not that the package was not catkinized it is that it was just a script thrown at an empty package I will fix the package.xml and CMakeLists.txt but this brings me to another issue maybe it would be useful to have a dump of useful scripts here instead of this package, for example the scripts here https://github.com/strands-project/strands_utils/tree/hydro-devel/strands_utils/scripts especially crop_map

[Jailander]

Any thoughts on this @hawesie @marc-hanheide @bfalacerda?

[Jailander]

Ok this PR (strands-project/strands_navigation#135) handles some of this issues however the question if whether this package belongs there or if a navigation scripts package should be created remains open

[bfalacerda]

I still don't see why we need a stand-alone script to do what it does, but it looks like you want to add functionalities in the future, so I'll leave it be.

Regarding the navigation scripts package, I do feel that we're starting to throw too many packages into strands_navigation already, so it is worth to stop and think how we want to organise it. Should some of these lower level packages be in strands_navigation? I don't really have an insightful suggestion about this issue though...

[Jailander]

yes I suggest two things first, move this issue to strands navigation and then we can reorganise a little I think for example that I can merge joy_map_saver, topological_utils and pose_initialiser in two packages like strands_mapping and topological_utils (or strands_nav_utils) also we could see about the nav_goal generator

[bfalacerda]

👍

I would keep the topological_utils as a package as everyone's used to it and the naming is intuitive. The other stuff could be merged into a single package I guess