Hello @Joe_Dinius,
Next WG session is already packaged 
but I’ll definitely try and make room for Q&A (if there’s lots of interest we may stay for a bit longer, like last time). For the now, let me give you some thoughts, we can iterate here or discuss further during the meeting:
I’m sorry, but I’m not really familiar with the 96Boards mezzanine products. Could you clarify where do you see the problem? Are these boards enabled via PL connected pins? If so, do they require a specific Vitis platform and that’s where you see the conflict with the existing firmware repositories (e.g. given a acceleration_firmware_ultra96v2 with a default empty platform, you wonder how to support the Shiratech Bosch Sensor Mezzanine)?
I need a bit more of context, but if my assumptions above are right, there’re several ways to implement this capability (i.e. extensions with hardware/carriers that require specific configurations of the PL). The proposed architecture was designed with composability in mind, considering the future use of one or multiple carrier boards. In line with the efforts for simplifying hardware aspects to ROSsers, enabling additional hardware is possible by using its ROS 2 adapter (i.e. a ROS 2 package that enables the hardware).
With today’s architecture, there’re three avenues possible:
Option 1: add various platforms to a single (base board specific) firmware repository
The simplest one that comes to mind is to have in the ROS 2 acceleration_firmware_ultra96v2 package more than one platform, and switch between each other at desire. This could be implemented easily with additional verbs/subverbs in colcon-acceleration extensions leading to a flow like:
colcon acceleration select ultra96v2 # pick ultra96v2 firmware
colcon acceleration platform list # show existing platforms
colcon acceleration platform shiratech-bosch # pick one example
These tooling do not exist today, but shouldn’t take long to implement if needed, and add to the existing colcon-acceleration logic.
Option 2: fork the firmware repository and customize the platform for your hardware
Another way is to simply fork the acceleration_firmware_* package and customize it yourself. This can be done today.
Option 3 (preferred): create a ROS 2 package that enables that hardware in an existing firmware (already deployed)
This is probably the best option since it requires no modifications to existing packages and/or forks, however it comes at the cost of a bit of additional CMake complexity. In a nutshell, instead of creating (or enhancing) a complete (base board specific) firmware ROS 2 package, a new (carrier-board specific) specialized package would deploy any new required firmware (e.g. .dtbo files) and Vitis platform files (besides the ROS logic applicable to it) for enabling the mezzanine/carrier board hardware configuration you’re looking for.
One great argument to go this path is that it’s the manufacturer’s responsibility to create/maintain this package. In other words, if they want to sell boards to the ROS community, they should contribute and maintain this. Note this same concept can be used also without the need of additional hardware. Just new capabilities that require new firmware (e.g. a new FPGA IP addition to the Vitis platform).
Let me illustrate it with an example:
Imagine that you have a CAN carrier board which you’d like to plug into the KV260 in one of its expansion ports (e.g. the PMOD ones). Let’s call this carrier board, canboard. By the default, KV260 firmware ROS 2 package will probably not configure those pins appropriately for CAN use with canboard. A (and I’m just coming up with a name) ros_canopen_canboard could extend ros_canopen with additional CMake logic and the KV260 custom platform files. Accordingly, when building the workspace, the CMake logic will ship these new platforms files and any future raw disk image (SD card image) created out of this ROS 2 workspace would use them, empowering the use of canboard. This feature can also be combined with colcon-acceleration extensions to manually select between Vitis platforms and/or hardware configurations.
The idea of the ros_canopen_canboard could be extended further supporting a) multiple boards (not just KV260, but also Utra96v2, etc → more sales for manufacturer) and/or additional use of the FPGA for improved determinism. E.g. a ros_canopen_canboard_offloaded package could leverage additional resources in the FPGA and offload CAN logic to a soft core running there. This could help guarantee determinism at the data link layer (OSI L2) interactions, while interfacing with the usual ros_canopen. There’re lots of possible specializations, but for further variations (in this example, at least), I don’t see them being very useful for the general ROS user.
Yes. To enable new hardware for the first time, you need to have hardware knowhow. I don’t see a way around it for now. Most people nevertheless should be just fine using existing default platforms for reference boards, and these should be already ROS-enabled.
The creation of acceleration_firmware_* does indeed require some hardware and embedded experience, but for the most part I hope this will be a vendor-specific effort. Either the silicon OEM, or the board manufacturer/vendor, should produce this repository and provide support for it (if he/she wants to facilitate a path for the ROS community).
Of course, skilled users are welcome to maintain their own firmware packages and forks. We’ve provided a reference implementation for that purpose.
For the time being, the focus of the WG is on the layers depicted in the architecture diagram. This is what I’m maintaining for now, but it can easily change if people commits to other packages and efforts. It’s a working group after all!
The initial goal was indeed set to start with simple kernels and demonstrate how ROS 2 interactions (inter-, intra-process and intra-network) can be optimized. This should help people jumpstart with hardware acceleration, FPGAs and adaptive computing. That said, by no means we’re leaving communications aside. Besides the flexibility for I/O that an FPGA provides, the only way to achieve real hard real-time in ROS 2 is to have every single (OSI) layer and software abstraction time-bounded, and FPGAs excel also at that.
