add human_aware_navigation launch to this

[marc-hanheide]

to be switched on with an argument...

maybe needs a launch file for people stuff?

[cdondrup]

I will add one. In general, the people perception can just run all the time. If no one is subscribed to it, it just sits in the memory and does not do anything. As soon as you start logging or using it, it uses CPU. It might be nice to dynamically turn the logging on or off via dynamic reconfigure. I'll open a ticket for that in people_perception. Regarding the human aware navigation it's the same, if no people perception is running, it behaves like normal move_base, so no harm done. If people perception is running, it does reconfigure stuff. I have to add that it unsubscribes from people perception when it's not used. Regarding the on switch, human aware_navigation is used depending on how the edges are defined in the topological map. If they are defined to use human_aware they will, if not they use move_base. If this is enough as an on/off switch I don't have to change much ;)

[marc-hanheide]

that actually might be enough... only question: is there an easy search and replace to switch those edges, @Jailander ?

[Jailander]

not right now, the easiest thing is to do mp_export change it in the text file and reimport the map, if you want the same name you can delete the previous one, but I'll create a tool for that

[cdondrup]

I could just have a dynamic reconfigure parameter that turns it on or off and if off, ignore people. But I think handling this via edges is the more consistent solution. I could create a small wrapper around move_base goals that uses the same head movement behaviour (looking at the closest navigation goal) even when there is no human_aware navigation running. Not sure if that's worth it and adds to the legibility, though.

[marc-hanheide]

i'd say, no....

[cdondrup]

That's what I thought. But then handling it via edges is I think the best solution. @Jailander wasn't there talk about having several possible transition methods and then dynamically choosing between them?

[Jailander]

yes and no, there is going to be several transitions between nodes (that is already done, but in testing should be released next week) but we haven't agreed a way of choosing between them for now it is going to be the MDP depending on the robot experience, but we did want to be able to tell topological navigation/MDP to choose one transition for some specific tasks like bellbot, still thinking about it

[cdondrup]

Regarding the launch file for people stuff, I just tested the newest version on the robot

roslaunch perception_people_launch people_tracker_robot.launch machine:=machine_name user:=user_name

Works fine now. No need for any ssh shenanigans any more. I could write a wrapper around that to have it in here but find that highly redundant. Opinions?

[marc-hanheide]

It is redundant, but as you rightly say, it won't need any additional resources if not being used, why not add it to strands_navigation.launch together with human-aware navigation and make it another argument to disable if (enabled by default)?

[cdondrup]

I think, the people perception should be launched separately. I'm not a big friend of merging too much stuff into one launch file; makes it easier to restart components on the fly. The people perception is not as essential to the basic functionalities of the robot as the navigation and human aware navigation still works without it and just behaves like move base. Looking at the dependencies, it would make sense to put it in the navigation file, but as I said, I would like to have it optional and keep a cleaner launch file structure. I'm open to discuss this, though.

[marc-hanheide]

OK, let's keep it separate.

[cdondrup]

This should be done.