Tools: Install uxrceddsgen in Ubuntu

[Ryanf55]

Purpose

Allow users to more easily install MicroXRCEDDSGen without having to compile it using gradle, for users who use ROS 2 with Ubuntu. This is optional during setup. It is used as a compile-time dependency in ArduPilot. It's not used at runtime, thus is only useful for people who compile ArduPilot from source.

Sizes of downloads:

• 406B for the script
• 19M for the jar

[Ryanf55]

Unrelated failure: https://github.com/Ryanf55/ardupilot/actions/runs/9230437664/job/25398673460#step:6:116

[Ryanf55]

0001-Github-Enable-DDS-in-environment-setup-testing.patch

Also, this patch could be helpful to ensure DDS is actually going to work.

[Georacer]

Hi!
Apart from the two comments, a couple more questions:

First, the flags DO_UXRCGEN_INSTALL and UXRCE_GEN_TOOL_NAME are not visible anywhere. Where do you propose that they will be documented?

If I understand this correctly, you download microxrceddsgen and microxrceddsgen.jar, but you don't actually use them to produce the DDS libraries. Is this really that useful? The user has to run the generation command anyways.

Also, in your PR descriptions you mention "for users who use ROS2". I don't see a mechanism where these will not be installed with -y if a user doesn't plan to user ROS.

[Georacer]

Shouldn't you return to the previous directory after this install step is done?

[Ryanf55]

No need. The others don't, they use absolute paths for directory changes.

[Georacer]

Do you indeed want to skip adding to path if the -y parameter was passed?

[Ryanf55]

Yep, that's what the others do.

[peterbarker]

I wonder if these artifacts should be committed to the tree, and/or whether we should be cloning the entire repo rather than grabbing artifacts.

[Ryanf55]

Hi! Apart from the two comments, a couple more questions:

First, the flags DO_UXRCGEN_INSTALL and UXRCE_GEN_TOOL_NAME are not visible anywhere. Where do you propose that they will be documented?

If I understand this correctly, you download microxrceddsgen and microxrceddsgen.jar, but you don't actually use them to produce the DDS libraries. Is this really that useful? The user has to run the generation command anyways.

Also, in your PR descriptions you mention "for users who use ROS2". I don't see a mechanism where these will not be installed with -y if a user doesn't plan to user ROS.

As best I could, I followed existing patterns. That includes the use of undocumented flags, which are only changed in CI. Thus, I propose doing what's already done and adding more flags, that only CI touches.

No, that is not correct. We download those, which are used to produce the ardupilot binaries. Once the binaries are created, microxrceddsgen is not needed at runtime.

If a user says "n" to the question, it won't be installed, just like the other optional features in setup. If it doesn't do that, it's a bug.

[peterbarker]

[8:25 AM]Peter Barker: How often does it change?  How co-dependent is the ArduPilot build on it?  i.e. the install script is run once, so gets the jar once.  If it is out of date/non-functional in 2 months then that's a problem as everyone's DDS setup breaks.
[8:59 AM]RyanF: I hasn't changed since 4.5, but we expect one major version bump before 4.6.
[9:25 AM]Peter Barker: .... breaking everyone's DDS setups.  Thus my question about adding it as an artifact to the ArduPilot repo.  How big is it?
[9:28 AM]RyanF: 406B for the script and 19M for the jar.

[Ryanf55]

Can we try this workflow out first? We have the 4.5.1 version that fixed some extranneous stderr behavior, but otherwise expect no changes. This PR makes a good improvement significant improvement in user setup time lowering the barrier to entry in using ROS 2.