Feedback on REP-2008 - ROS2 acceleration kernels with build integration

Yes, it proposes a reference architecture for the building and linking. It proposes conventions for using acceleration kernels from the build output in ROS2.

The proposal itself is not a guideline for hardware acceleration, however, as this would be guidance on what to implement in a hardware accelerator versus a CPU. Writing such a guide is quite difficult, as best practices are specific in nature to the type of accelerator and its implementation, be it fixed function, FPGA, or high performance compute. This is why standards like OpenCV, Vulkan, et. exist to abstract this problem away from developers, which is not what this REP provides.

REP-2008 is not needed where standards exist. The maintained package Image pipeline in ROS2 Humble uses OpenCV which can be accelerated by hardware, and REP-2008 was unnecessary to do this. What REP-2008 focuses on is to enable FPGA tools to compile ROS nodes, packages or ROS itself into firmware, and link that into the system.

REP-2008 contributions are to the build system, using the specified vendor specific build tools, firmware linking, and tracing / benchmarking (now part of REP-2014).

Hence the recommendation to make the name aligned to the problem the REP tries to solve, which is REP-2008 - Accelerated kernels with build integration.

It’s great HAWG is discussing this with Intel. It would be good to see Intel implement this REP for their Altera FPGAs so it’s not Xilinx specific.

Successful standards for accelerating functions, like OpenCV, Vulkan, et. have broad developer and vendor support. It’s not the quantity of people on a call, but active-participation and contribution from developers and vendors with implementations for success.

It would be good to see evidence of this active participation and adoption.

Seems you’ve missed the problem REP-2007 solves.

This step is a duplication of REP-2007.

An accelerated ROS2 node needs to work with other non-accelerated nodes, on topics using standard types defined in ROS2. This structure provides the interoperability for developers to leverage nodes to create graphs performing functions for robotics.

REP-2008 claims to optimize dataflow across nodes, with no structure on how to do this. The vagueness in REP-2008 will create fragmentation and difficulty for developers in adoption.

REP-2007 provides an approved, and implemented function to optimize topic communication between nodes abstracting the platform and hardware specifics. Nodes by default are compatible using standard topics with standard types. Adapting the type enables optimization. Type adaptation does not specify how to optimize the adapted type as that is platform and hardware specific, while providing the structure for those optimizations to be compatible on topics.

For example, on a FPGA, one can use type adaptation (REP-2007) to communicate topics between accelerated firmwares on AXI by having the nodes on the CPU perform the negotiation. This structure allows for hardware optimized nodes that support AXI communication to subscribe to a topic, and maintain compatibility with nodes that do not support AXI communication.

REP-2007 is proven in use, as we have delivered great hardware acceleration performance in ROS2 Humble, with low latency in 16 nodes for developers.

Acceleration of inter-node communication is provided in REP-2007. REP-2008 can refer to REP-2007.

Thanks.