Integration of HA-Nav from STRANDS

[marc-hanheide]

initially, only showing the constraints

[marc-hanheide]

this is based on the original work by @cdondrup

https://github.com/strands-project/strands_hri

https://github.com/strands-project/strands_hri/blob/kinetic-devel/hrsi_launch/launch/hrsi.launch

we want to be able to run the hrsi_state_prediction based on the Spencer Tracker. That's out first step.

[cdondrup]

Let me know if you need help or an explanation of how stuff works. If I still remember ;)

[MFernandezCarmona]

Thanks, greatly appreciated! I will do so

[marc-hanheide]

Using our branch of move_base: https://github.com/strands-project/navigation

And then use the https://github.com/strands-project/strands_hri/blob/kinetic-devel/hrsi_launch/launch/hrsi.launch but based it on input from SPENCER.

[marc-hanheide]

Steps:

• Use the STRANDS move_base fork
• fork the https://github.com/strands-project/strands_hri
• adapt for SPENCER people tracking
• integrate with ILIAD dwa-based navigation

[MFernandezCarmona]

Hi @cdondrup , Question about STRANDS navigation stack. I've been checking the changes, and essentially you add a new class to the base_local_planner and use it in your modified dwa local planner. So, why don't just create a repo with the modified dwa local planner that can be loaded as a plugin?

This would increase greatly its usability.

[cdondrup]

Because it worked and was the quickest solution ;)

Yes, you can just create a copy of the DWA planner and use it as a separate plugin but that means modifying all the config files to use it. If you use the current version, it works exactly like the vanilla DWA if you do not publish any velocity costmaps and you don't need to modify any config files. If you do publish costmaps, it does take them into account. Hence, I opted for the easy way of just publishing or not publishing them to switch behaviours. This does not require you to change config files and restart the whole system to change planners. If you just create a new plugin and change all the config files to always use the new DWA, then there is no difference... Therefore, I don't believe that it would increase its usability to make it a separate plugin but that's up to you if you can see a use case where that would be beneficial, you have my blessing.

[MFernandezCarmona]

Nice! I'll give it a try.

[MFernandezCarmona]

QTC states up and running. Constraints applied. See QSR2constraints_node.py