Add a debian install of the ROS2 tools

Question

Add a debian install of the ROS2 tools

Ryanf55 opened this issue 2 years ago · 15 comments

On Ubuntu, add a launchpad.net account for ArduPilot.
Add versioned debs for Ardupilot and its tools.

This will allow users to easily install debians of ArduPilot. Can click to add that project to your deb sources, and then you can update+install.

ardupilot_sitl
ardupilot_gz
ardupilot_dds

The prebuilt binaries are avilable for stable, 4.4, latest, etc.

Can look into having OSRF have the ardupilot repo on the build farm. We would want to make available ARdupilot4.4, ArdupilotRolling, etc.

Answer 1 · 2024-02-09T20:06:13.000Z

Hi, can you assign me this issue? I believe I have requisite skills, and have experience doing a similar thing.
Thank you

Answer 2 · 2024-02-09T21:16:32.000Z

That would be great! Let me know if you have questions.

Answer 3 · 2024-02-27T16:40:37.000Z

Hi, ardupilot_gz_bringup seems to depend on ardupilot_sitl and ardupilot_msgs. These are located under ardupilot/Tools/ros2. Do they have their own git remote like ardupilot_gazebo?
Thanks

Answer 4 · 2024-02-27T17:33:45.000Z

Hi, ardupilot_gz_bringup seems to depend on ardupilot_sitl and ardupilot_msgs. These are located under ardupilot/Tools/ros2. Do they have their own git remote like ardupilot_gazebo? Thanks

Nope, they are local builds.

Answer 5 · 2024-03-05T02:16:54.000Z

Hi, so I did manage to get the debs built however since ardupilot_sitl has dependency on micro_ros_agent, this breaks installation on any system without the custom rosdistro index (i.e. without micro_ros_agent added in there) see 1.
Is micro_ros_agent a hard dependency of ardupilot_sitl? Is there a way for me to circumvent around it?
Thanks

Answer 6 · 2024-03-05T02:23:52.000Z

Hi, so I did manage to get the debs built however since ardupilot_sitl has dependency on micro_ros_agent, this breaks installation on any system without the custom rosdistro index (i.e. without micro_ros_agent added in there) see 1. Is micro_ros_agent a hard dependency of ardupilot_sitl? Is there a way for me to circumvent around it? Thanks

It is a hard dependency. I would ask around on the microROS slack channel to see if it's in the roadmap to get debians built.

Answer 7 · 2024-03-05T08:08:04.000Z

@Ryanf55 I believe I got a reply from a dev regarding this.

micro_ros_agent is released as a Debian package in Vulcanexus: https://docs.vulcanexus.org/en/latest/rst/installation/linux_binary_installation.html

I would check this out, and see what I can do; and will let you know if it works out.
Thanks

Answer 8 · 2024-03-05T08:18:03.000Z

Yea, check it out: https://docs.vulcanexus.org/en/humble/rst/introduction/metapackages.html

vulcanexus-humble-micro

Make sure to use humble

Answer 9 · 2024-03-06T07:14:46.000Z

Hi @Ryanf55 , it works and I am done with generating debs for all the packages that you have listed on the ticket (will make a PR after testing it out on a docker container).
I had just one doubt regarding ros_gz packages. Currently, I believe we are building ros_gz_bridge and ros_gz_sim from source. However, I believe there are binary install available for humble and its gz-garden bindings (see here)

Gazebo Garden can be used with ROS 2 Humble and non ROS official binary packages hosted in packages.osrfoundation.org. These packages conflict with ros-humble-ros-gz* packages (Humble officially supports Gazebo Fortress).
To install the binary Gazebo Garden/ROS 2 Humble packages:
Folow these instruction to install gz-garden from packages.osrfoundation.org repository.
Install ros_gz from the non official binary packages from apt:
apt-get install ros-humble-ros-gzgarden

I have used these^ for now. They seemed to work atleast on my local.
Is there a reason why we are adamant about the source install of ros-gz? (if that is the case, then we would have to host our binaries of ros-gz, or I need to find some other workaround).

Answer 10 · 2024-03-06T16:47:21.000Z

Hi @Ryanf55 , it works and I am done with generating debs for all the packages that you have listed on the ticket (will make a PR after testing it out on a docker container). I had just one doubt regarding ros_gz packages. Currently, I believe we are building ros_gz_bridge and ros_gz_sim from source. However, I believe there are binary install available for humble and its gz-garden bindings (see here)

Gazebo Garden can be used with ROS 2 Humble and non ROS official binary packages hosted in packages.osrfoundation.org. These packages conflict with ros-humble-ros-gz* packages (Humble officially supports Gazebo Fortress).
To install the binary Gazebo Garden/ROS 2 Humble packages:
Folow these instruction to install gz-garden from packages.osrfoundation.org repository.
Install ros_gz from the non official binary packages from apt:
apt-get install ros-humble-ros-gzgarden

I have used these^ for now. They seemed to work atleast on my local. Is there a reason why we are adamant about the source install of ros-gz? (if that is the case, then we would have to host our binaries of ros-gz, or I need to find some other workaround).

If you can get a way to work with either garden or harmonic without compiling those packages from source, please contribute a PR. That sounds nice.

Answer 11 · 2024-03-06T20:31:46.000Z

Hi @Ryanf55, I have tested all the debian installs on a docker container, they seem to work with the ros_gz binaries from apt-get install ros-humble-ros-gzgarden.

I am not sure how I should be going about making a PR with the debian binaries as listed, for this ticket. I have added them as a release on my fork here.
Could you let me know how should I be going about it?

Answer 12 · 2024-03-13T16:37:15.000Z

Hi, I have made a shell script here, for the generation debian installs to be added to the CI. Please let me know how should I be proceeding further? Should I make github-action pipeline for this and put up a PR?
Thanks

Answer 13 · 2024-03-14T02:49:00.000Z

Awesome, that's perfect. I'll run this on my system, and once that's good to go, I think the next step is to follow the bloom tutorial (creating a release organization, and then running bloom to generate the binaries.)

One thing that's not clear to me is how we can tie these binaries to 4.5 ardupilot vs 4.6. If you have any ideas on versioning, let me know.

Excellent work so far. The script is very helpful.

Answer 14 · 2024-03-14T03:30:10.000Z

The versions in generated binaries are linked to the version tag in the package.xml. Perhaps, we can suitably change those.
For tieing it to Ardupilot 4.5 vs 4.6, or in similar cases. I believe instead of cloning the rolling release I could download the corresponding release source code, and use that.

If you run into any trouble while running the script, please do let me know, I will try to make the necessary changes. (I did make sure to test it in a docker container).
Thanks

Answer 15 · 2024-03-14T05:02:57.000Z

The versions in generated binaries are linked to the version tag in the package.xml. Perhaps, we can suitably change those. For tieing it to Ardupilot 4.5 vs 4.6, or in similar cases. I believe instead of cloning the rolling release I could download the corresponding release source code, and use that.

If you run into any trouble while running the script, please do let me know, I will try to make the necessary changes. (I did make sure to test it in a docker container). Thanks

Yep, makes sense. The thing is that ArduPilot has its own release cadence that is not tied at all to the release of ROS versions, and I haven't yet found a good recommendation on how to do that. The only other well-known tool that releases multiple versions in the ROS ecosystem at a separate cadence is gazebo (you can run ignition, garden and harmonic all in Ubuntu 22). Perhaps there's a process we could use to do that sort of thing.

The other (simpler) option is to not worry about ABI stability for now, and just target ardupilot master.