機器翻譯：discourse.ros.org/t/robotic-processing-unit-and-robotcore/27562
機器人處理單元和機器人核心
Robotic Processing Unit and ROBOTCORE 從硬體加速ROS 2管道到機器人處理單元(RPU) 9線程，我很高興地分享我們已經公開釋出并開源了ROS 2硬體加速工作組機器人處理單元21子項目的設計檔案。
機器人處理單元(RPU)是一種機器人專用的處理單元，它使用硬體加速，并将機器人計算有效地映射到其CPU、FPGAs和GPU，以獲得最佳性能。特别是，它專門在底層計算資源上改進機器人作業系統(ROS 2)相關的機器人計算圖。
這個子項目的目标是為工作組和其他機器人架構師提供一個參考硬體藍圖，用于建構硬體加速的ROS 2圖，為每項任務使用最佳的加速器。為此，該項目利用現有的現成硬體加速開發平台。特别是AMD和NVIDIA的流行産品，将16個CPU、一個GPU和一個FPGA打包在一起。由此産生的元件用于原型化機器人專用處理單元，旨在在ROS 2和機器人計算圖方面表現最佳。
組裝不同開發闆的零件可以3D列印。設計檔案在存儲庫中公開，組裝說明非常簡單:
步驟圖像描述
這是機器人處理單元的分解圖。這應該有助于指導您自己的建構過程。首先将電源線分别焊接到KR260和AGX Orin闆上。您需要在每個機器人開發套件的電源插孔引腳上這樣做。
1
用4個M3螺栓(ISO7046)和4個M3螺母(DIN934)将KR260闆擰到KR260擴充卡上。
2
使用開發套件中包含的相同原裝螺栓将AGX Orin闆擰到AGX Orin擴充卡上。
3
連接配接兩個dev上先前焊接的電線。PYBE30-Q24-S12-T DC-DC轉換器的電路闆。功率輸入應該來自AGX Orin，調節輸出到KR260。
4
将PYBE30-Q24-S12-T DC-DC轉換器、AGX orin和KR260擰緊至底座。使用10x M3螺栓(ISO7046)和10x M3螺母(DIN934)。
5
最後，固定蓋子的4個孔，并用4個M5螺栓(ISO7046)連接配接底座和蓋子。
機器人處理單元将用于在社群工作組内基準測試和進一步開發ROS 2 API相容的硬體加速工具和機器人知識産權(IP)核心。最後，我們加速機器人1将提供機器人處理單元的商業支援1和加強版本(機器人核心)10，以進一步激勵其使用。
大概值得一提的是，除非你的機器人應用需要機器學習或者計算機視覺，否則這個硬體很可能是大材小用。ROS 2節點和底層通信非常輕量級，幾乎可以在任何可以運作Ubuntu的嵌入式SBC上正常工作(例如，最新的Raspberry Pi)。
Raspberry Pi SBCs很棒，我用它們造了很多機器人。它們是簡單機器人原型和開始接觸機器人的人的一個很好的起點，但是它們很快就不能滿足許多機器人應用。我鼓勵你去ROS 2硬體加速工作組，試着了解一下我們在那裡做的工作以及加速器背後的價值。這包括為建構計算圖建立定制計算架構的可能性。有大量的項目和文獻可以閱讀，我們一直在制作的基準可能有助于您的了解。
而且，你似乎強烈地忽略了機器人是決定性的機器。在計算中滿足時間期限(實時)是最重要的特性，但是在設計機器人計算時，其他特性也是相關的，包括任務開始和完成之間的時間(延遲)，在給定時間内完成的工作總量(帶寬或吞吐量)，或者任務每次都在完全相同的時間架構内發生(确定性)。由于CPU的可用性，它們被廣泛用于機器人，但是它們很難在提供高吞吐量的同時提供實時和安全保證。行業中滿足時間期限的實際政策是對系統進行費力的、經驗性的和逐個案例的調整。機器人技術中的這種“*CPU打地鼠”方法是不可持續的，并且難以擴充，因為在CPU中缺乏硬體支援的時序安全事件驅動程式設計接口。硬體加速(使用FPGAs、GPU或其他加速器)為這個問題提供了答案。它允許機器人架構師為機器人建立符合實時和帶寬要求的定制計算架構，同時降低功耗。
當然，你可能不想使用這種類型的硬體來“學習機器人學”:wink:，但在自主移動(AMRs、自動駕駛X、建築、采礦等)、工業操縱和醫療保健機器人(例如手術機器人)中有大量的用例，你會驚訝地發現這有多符合需求。
大概值得一提的是，除非你的機器人應用需要機器學習或者計算機視覺，否則這個硬體很可能是大材小用。
以我的經驗來看并非如此。加速器在涉及整個機器人堆棧的機器人應用中非常有用，從傳感到感覺、地圖、定位、運動控制、低級控制，一直到驅動。它們可以幫助你更快地計劃抓握或更快地避開障礙。它們甚至可以幫助你加速ROS 2坐标系的轉換(tf2 3的基準)。
你可能會這樣想的原因是因為沒有足夠多的公開可用的加速核心用于(除了ML和CV)機器人任務，但會有。
由于CPU的可用性，它們被廣泛用于機器人，但是它們很難在提供高吞吐量的同時提供實時和安全保證。行業中滿足時間期限的實際政策是對系統進行費力的、經驗性的和逐個案例的調整。機器人技術中的這種“*CPU打地鼠”方法是不可持續的，并且難以擴充，因為在CPU中缺乏硬體支援的時序安全事件驅動程式設計接口。硬體加速(使用FPGAs、GPU或其他加速器)為這個問題提供了答案。它允許機器人架構師為機器人建立符合實時和帶寬要求的定制計算架構，同時降低功耗。
我對硬體工作組不是很了解，但是我可以問一下您計劃如何在這個架構中實作實時保證嗎？FPGA在實時确定性方面很棒，但GPU在确定性方面通常比CPU差，因為它們沒有內建到RTOS中，并且您隻能使用NVIDIA的預設排程程式。
另外，你在CPU上運作RTOS了嗎？據我所知，Jetson平台不支援任何RTOS，隻有英偉達汽車版的Orin支援基于QNX的作業系統。
我對硬體工作組不是很了解，但是我可以問一下您計劃如何在這個架構中實作實時保證嗎？FPGA在實時确定性方面很棒，但GPU在确定性方面通常比CPU差，因為它們沒有內建到RTOS中，并且您隻能使用NVIDIA的預設排程程式。
我同意并分享你對GPU的擔憂。與CPU類似，它們擁有以記憶體為中心的馮諾依曼架構，這使得确定性和實時性比其他計算基闆更具挑戰性。FPGAs和MCU通常對此響應更好，并且在針對(硬)實時時，相對來說是更容易使用的解決方案。機器人處理單元注意到了這一點，并将大量計算打包在一起，包括16個CPU、一個GPU和一個FPGA，混合了AMD和NVIDIA的技術。下圖從較高的層面說明了這一點:
除了這些用于計算的大型構件，這兩組中的每一組都包含專門用于實時的額外計算單元。在AMD的Kria KR260的情況下，除了FPGA(和軟核的可能性)，你有2核32位Arm Cortex-R5F實時處理器(CPU最大頻率600MHz)，其中你可以運作裸機或RTOS(例如，FreeRTOS或NuttX是很好的選擇)。同樣，Jetson AGX Orin具有Jetson傳感器處理引擎(SPE)，這是一種Arm Cortex-R5 MCU，也可以像FreeRTOS一樣運作RTOS。總的來說，在機器人處理單元中，你有很多硬實時的選擇，隻要你适當地設計事情。這些SOC(以及它們互相連接配接的組)的挑戰就在架構中，這就是我們在ROS 2硬體加速工作組中要解決的問題，也是REP-2008如此重要的原因(在單一、一緻、以ROS為中心的流程中簡化對各種加速器的支援)。
如果你想知道機器人處理單元中各組之間的互連，它是在一個公共以太網資料總線中互連的，這允許将機器人中使用的傳統控制驅動方法與資料驅動相結合。它也非常符合DDS和大多數DDS供應商的基本假設。我們主要用PCIe和以太網做了大量測試，确定以太網是滿足時間期限的最佳選擇。PCIe很有前途，在吞吐量方面也很棒，但在嘗試實時功能時，它的行為真的很奇怪。
另外，你在CPU上運作RTOS了嗎？據我所知，Jetson平台不支援任何RTOS，隻有英偉達汽車版的Orin支援基于QNX的作業系統。
AMD的Kria KR260為開源Xen虛拟機管理程式提供支援，并為各種CPU提供RTOSs組合。我對此進行了廣泛的測試，盡管內建起來很複雜，但我還是推薦它。它提供了非常好的結果。在Jetson AGX Orin的情況下，您有RedHawk Linux開源RTOS支援，但您在某種意義上是正确的，更通用的RTOS，如QNX，似乎隻适用于驅動(進階)解決方案。
不過，這應該不會讓你太驚訝。NVIDIA的開源方法一直備受争議，被一些人稱為破壞開源。引用萊納斯·托沃茲(2012)的話:
我也很高興地公開指出，Nvidia是我們與硬體制造商之間最糟糕的麻煩之一，這真的很可悲，因為Nvidia試圖向Android市場出售晶片——大量晶片。英偉達是我們接觸過的最差的公司。
即使在今天，在他們的ROS包中，你也會發現大量二進制格式的靜态庫，你無法适應你的需要。NVIDIA繼續(在我看來)在許可方面玩着有趣的遊戲，分叉ROS Apache 2.0(或類似的，商業上友好的)代碼，并根據他們的需要重新許可。這是我這些天對他們的主要批評。我過去抱怨過這一點，這導緻了許可證的變更，然而這一趨勢仍在繼續。
現在，英偉達仍然很難合作。他們花了幾年時間才認識到，如果沒有ROS，他們的GEMs方法一文不值。幸運的是，他們做到了，現在他們的話題都是關于ROS:伸出舌頭！