cmake helper function and tool to auto generate TreeNodeModel xml files for groot

[ewak]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	(add tickets here #1)
Primary OS tested on	Ubuntu
Robotic platform tested on	laptop
Does this PR contain AI generated software?	No

---

Description of contribution in a few bullet points

• I added a generic tool and a cmake funciton to easily use it to auto generate TreeNodeModel xml files for groot.
• I applied it to nav_behaviour_tree and opennav_docker_bt.

Description of documentation updates required from your changes

Description of how this change was tested

---

Future work that may be required in bullet points

For Maintainers:

• Check that any new parameters added are updated in docs.nav2.org
• Check that any significant change is added to the migration guide
• Check that any new features OR changes to existing behaviors are reflected in the tuning guide
• Check that any new functions have Doxygen added
• Check that any new features have test coverage
• Check that any new plugins is added to the plugins page
• If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

[mergify]

@ewak, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

Some other thoughts:

I remember chatting about this back when the plugins list for BT Navigator had the libraries stored in a similar way (as you've found here) that we weren't sure how to automatically update the groot XML in source as might be necessary for use. That way, we don't need to manually manage it ever again, it automatically updates on commit / merge.

Or, a GitHub Action job runs to run this over and if it detects a problem it fails the job to make a human make the update for their violating PR. Verification is less ideal than automation, but verification is still very useful.

[SteveMacenski]

Should we though? If we removed this, what would be the workflow for using groot?

[SteveMacenski]

Is the other Groot XML in the nav2_behavior_tree package not also needing an update?

[ewak]

Yes. I did not touch the manually managed file yet. I will go all in.

[ewak]

Some other thoughts:

I remember chatting about this back when the plugins list for BT Navigator had the libraries stored in a similar way (as you've found here) that we weren't sure how to automatically update the groot XML in source as might be necessary for use. That way, we don't need to manually manage it ever again, it automatically updates on commit / merge.

I could can target the source directory location for the output of the generation. And then install it from there.

My gut feeling is that the generated file should be the one that is installed and packaged and there should be a ctest to do a comparison between the generated file and one cached in the source directory. It can use cmake -E compare_files --ignore-eol https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdoption-cmake-E-arg-compare_files

I will play around with an option, something like, UPDATE_SRC_CACHE_PATH, to have the generation step go ahead and update the source file if its different. That way the developer gets a changed source file that they can choose when to commit. If they don't the ctest will catch them in CI.

Or, a GitHub Action job runs to run this over and if it detects a problem it fails the job to make a human make the update for their violating PR. Verification is less ideal than automation, but verification is still very useful.

Github Actions are a whole other thing to learn. I'll try out the ctest route.