Clarifying package purpose about acceleration_firmware HOT 6 CLOSED

Thanks for looking into this @methylDragon!

Going forward with 1️⃣ sounds good to me, but let's discuss with a bigger group in the next meeting. I would like to give it an additional thought and consider if we can somehow produce meaningful templating mechanisms/binaries that help pave the way down the road (for future acceleration_firmware_* extensions) while fullfilling requirements to be shipped into the build farm.

If not, given the limitations, I personally would approach this with your suggestion (1️⃣) by 🅰️ removal of all dependencies from dependent packages (in their package.xml files) and then 🅱️ re-consideration if this package should be released in rosdistro or dissapear completely.

from acceleration_firmware.

I understand it's meant to be an abstract package for providing firmware artifacts, but how exactly that happens I am a little unclear about.

That's right. It happens by simply establishing a chain of dependency through package.xml files. E.g, vendor-specific acceleration firmware would happen as:

<?xml version="1.0"?>
<?xml-model href="http://download.ros.org/schema/package_format2.xsd" schematypens="http://www.w3.org/2001/XMLSchema"?>
<package format="2">
  <name>acceleration_firmware_jetson_agx</name>
  <version>0.7.0</version>
  <description>
    Firmware enablement for ROS 2 hardware acceleration capabilities in 
    NVIDIA Jetson AGX Xavier boards.
  </description>
  <maintainer email="[email protected]">Víctor Mayoral Vilches</maintainer>
  <author email="[email protected]">Víctor Mayoral Vilches</author>
  <license>Apache License 2.0</license>

  <buildtool_depend>ament_cmake</buildtool_depend>
  <build_depend>acceleration_firmware</build_depend>

  <export>
    <build_type>ament_cmake</build_type>
  </export>
</package>

<?xml version="1.0"?>
<?xml-model href="http://download.ros.org/schema/package_format2.xsd" schematypens="http://www.w3.org/2001/XMLSchema"?>
<package format="2">
  <name>acceleration_firmware_kv260</name>
  <version>0.9.0</version>
  <description>
    Xilinx's vendor-specific pre-generated firmware to accelerate ROS 2 robotic applications.
    The package contains firmware artifacts for selected boards in different branches.
  </description>
  <maintainer email="[email protected]">Víctor Mayoral Vilches</maintainer>
  <author email="[email protected]">Víctor Mayoral Vilches</author>
  <license>Apache License 2.0</license>

  <buildtool_depend>ament_cmake</buildtool_depend>
  <build_depend>acceleration_firmware</build_depend>

  <export>
    <build_type>ament_cmake</build_type>
  </export>
</package>

Then, subsequently, a package that's using hardware acceleration may want to define this dependency on its package.xml (to specify that the package should be built only if hardware acceleration packages are installed). E.g. https://github.com/ros-acceleration/acceleration_examples/blob/main/graphs/perception/perception_3nodes/package.xml#L27

Having acceleration_firmware instead of having to specify acceleration_firmware_* for each supported board simplifies the job for package maintainers, and for users.

from acceleration_firmware.

[A]: An abstract package, abstract in the sense of abstract base classes, where the package has to be built off of?
In that case, is there anything unique about this package that makes it differ from the standard package format?

I'd say A, with the rationale explained above, for development/organizational purposes. There's indeed no implementation at the moment and after having ported the architecture to about 7 different embedded, I don't think there will be.

Though if the package is meant to be a template or abstract, it might be difficult getting it released, since there's no implementation..

Understood, but can you then elaborate on what's your proposal for marking such hardware acceleration dependency in a package (that's using hardware acceleration) in a vendor-agnostic manner (i.e. without doing <build_depend>acceleration_firmware_kv260</build_depend>). Or maybe this is not desired?

from acceleration_firmware.

I went back to double-check some things about whether a package like this can be sent to the buildfarm, and I think it unfortunately can't, since there will be no binaries to release.

I think there are two main approaches we can take with this package, depending on the downstream packages' use scenarios:

1. Release this package on rosdistro, but as a source and doc release only. (Source release doc)

• Note that this means that the package will not be apt installable
• Users will likely have to obtain this package by cloning its source (e.g. using vcstool)
• Source releases will be obtainable by package name using rosinstall_generator, since it will look-up the distribution listing on rosdistro, but it'll require a manual invocation of rosinstall_generator, since the package won't be available as a debian.
  • e.g. rosinstall_generator acceleration_firmware --rosdistro foxy --deps | vcs import src

2. If all downstream packages that depend on this package will not be released on the buildfarm, and every source build case uses colcon, you can make use of groups, like in this example here

• HUGE CAVEAT: The reason why you cannot have any packages that depend on groups sent to the buildfarm, is because this only works with colcon builds. The buildfarm does NOT build with colcon, so consequently, any packages that depend on this package if we go with this option, will require colcon to build, and hence can't be released on the buildfarm.

I think the recommended approach would be the first, because groups don't tend to work as expected in ROS 2...

from acceleration_firmware.

Additional note since we're on the topic of dependencies for packages released on the buildfarm, do be aware that any non-apt installable system dependencies will disqualify a package from being released on the buildfarm (in most cases), since the buildfarm won't be able to resolve them.

This includes pip installed dependencies. I don't think this will be an issue (yet) for any of the packages we're targeting for release, but it might affect any downstream packages (e.g. the acceleration_firmware_* packages.) Just take note for the future, in case any vendors especially intend on releasing their own firmware packages on the buildfarm.

from acceleration_firmware.

Closing this issue since we've decided to not release this package as per ros2-gbp/ros2-gbp-github-org#22 (comment)

Cheers!

from acceleration_firmware.