End-to-end planner updates

[halil93ibrahim]

I am creating this PR instead of #286, since it includes updates in the end-to-end planner tool to include the recent work. I have also implemented the ROS1 node here, which publishes the output of the planner as a target waypoint.

[tsampazk]

Thanks @halil93ibrahim for the new node and the updates! As this tool seems more involved and different in nature, i don't think we need to force the ROS node format that is followed in other packages, what do you think @ad-daniel?

Changes are good from my perspective, most comments are about minor stuff; some broken links in the docs and leftover comments.

[ad-daniel]

Yes, I think this tool is a bit of an exception and it doesn't make much sense to enforce the same constraints as the others

[halil93ibrahim]

Hello, I have implemented your comments. Please let me know If there is further.
For tests to run successfully, preferably roscore and the Webots world provided are expected to run. What should I do to perform those?

[tsampazk]

Thanks @halil93ibrahim! Two very minor comments and it's good to go from my perspective.

For tests to run successfully, preferably roscore and the Webots world provided are expected to run. What should I do to perform those?

I'm not exactly sure how to handle this.

[tsampazk]

Thank you!

[ad-daniel]

Thank you

For tests to run successfully, preferably roscore and the Webots world provided are expected to run. What should I do to perform those?

You mean for the integrated tests (CI) ? The CI machines don't have GPU and running simulations CPU-only will likely result in very long tests, and the simulation also relied on a older version of webots (~1.5GB at the time) and required Ardupilot. As such we decided not to go that route and instead have a test that just ensures the tool is functional (i.e. can be installed without dependency conflicts and tests some functionality). An easier approach could be to record locally the simulation data (sensor data) and use that in the test without needing to install webots itself. At the time we opted for the current test, do you think a different approach would be better now?

[halil93ibrahim]

You mean for the integrated tests (CI) ? The CI machines don't have GPU and running simulations CPU-only will likely result in very long tests, and the simulation also relied on a older version of webots (~1.5GB at the time) and required Ardupilot. As such we decided not to go that route and instead have a test that just ensures the tool is functional (i.e. can be installed without dependency conflicts and tests some functionality). An easier approach could be to record locally the simulation data (sensor data) and use that in the test without needing to install webots itself. At the time we opted for the current test, do you think a different approach would be better now?

I meant the CI tests. Now, the tests are passing similar to the one we did before. The tool does not require Ardupilot in this version, but still needs the old version of Webots. So, I could think of a different approach when I complete the implementations in Webots 2022b.
I believe the PR is now ready to merge. Please let me know if a change is needed.

[tsampazk]

Thanks @halil93ibrahim, new changes LGTM!

[ad-daniel]

Ah I see, having webots on the loop would be ideal, but like I mentioned it will depend on the performance. If the tests take too long is not great and without GPU that might be the case. We can explore the option again when the version for R2022b is ready.
Looks good to me as well, thank you!