嵌入式控制系統設計/RoboCup
|
華夏公益教科書的
嵌入式控制系統設計
|
為了說明嵌入式控制系統的上述術語、特性和設計標準，以一個 RoboCup 機器人團隊為例。這個例子涵蓋了設計嵌入式控制系統時遇到的所有方面。
RoboCup 是一個來自世界各地的 200 支機器人足球隊的比賽，參加六個不同的聯賽。每個機器人足球隊由六個自主機器人組成（所以不允許人工干預）。一個機器人系統需要緊密整合規劃、感測、控制和建模。機器人還必須考慮自身、任務和環境之間的相互作用。關於 RoboCup 比賽的更多資訊，請訪問以下連結：RoboCup
每個參加 RoboCup 比賽的隊伍都必須設計一個足球機器人隊伍。每個足球機器人都是一個嵌入式控制系統，因此每個隊伍都可以看作是一個系統群。本章的目的是概述每個隊伍必須掌握的設計工作。
這個例子與航空等其他例子不同，因為
• 專案開始時，需求沒有明確規定，而是像下一章所示（移動目標）那樣不斷調整。這意味著設計階段沒有明確規定，可以隨著目標而改變。
• 存在一個不斷變化和改進的、主要的敵對環境。在航空領域，環境，如空中交通管制或其他飛機（非戰鬥機），是盟友，與飛機的行動相配合。
• 存在不同的設計目標：“盡力在規定的時間內，利用現有的資源做到最好”。這意味著可以假設資源是固定的。
總的來說，這個例子可以看作是一個系統群的原型，在每一個設計層級上都是如此。
一般來說，機器人可以分為兩個領域：（按複雜性遞增的順序）系統級設計（1 個機器人）或“系統群”級設計（機器人團隊）。選擇其中一種設計流程，取決於（團隊）工程師的優先順序。然而，這兩個領域都必須進行設計，因此，例如，從“系統群”級別開始，向下工作並最佳化單個機器人（從獲得的結果中學習）是必要的。
RoboCup 團隊維基有一個年限來設計一個自主足球機器人隊伍。該團隊組織了一個頭腦風暴會議，所有成員參與，並列出了每個場地足球機器人必須具備的技能和/或規格，以便發揮其作用，並遵循規則。這些技能和規格是設計師的挑戰，用通俗易懂的語言寫成，還沒有（技術上）具體規定。
嵌入式控制系統設計主章節中解釋的“四個 C”，現在被用於對機器人進行徹底的分析。以下主題將這些四個概念重新應用到本主題中。
1.計算
計算可以描述為對每個可能輸入的反應速度。“系統群”級別的計算依賴於系統級別的計算，因此區分是多餘的。在兩個級別上，硬體都是分散的。軟體在系統級別是集中的，但在“系統群”級別是分散的。這種方法導致更快的系統，而且故障機率更小。
2.配置
這是機器人的程式設計。獨立程式碼以及協作程式碼都在每個機器人中實現。
3.協調
可以將協調劃分為功能協調和系統協調。功能協調定義戰術情報，例如攻擊所需的行動。另一方面，系統協調涵蓋不同子系統之間的連線。
4.通訊
通訊建立了使所有協調方面成為可能的必要連結。機器人不同子系統之間的連結對於系統協調是必要的。
有關魯棒性的更多一般資訊，請參閱 設計標準。
魯棒性是一個非常廣泛的概念，在 RoboCup 例子的許多領域都有很多應用。它可以描述為軟體級別（處理通訊錯誤等）或硬體級別（相當於碰撞等）對故障的免疫水平。
在魯棒性和效率和效能之間取得良好的平衡非常重要。
• 系統必須足夠魯棒，能夠處理移動目標。例如，始終預見一種透過使用外部連結透過線路上傳新驅動程式或軟體來將新規則實現到配置中的方法。能夠在多個管理程式或戰術之間切換是一件明智的事情。
• 從硬體的角度來看，客戶端-伺服器通訊會建立一個單點故障，這會嚴重降低與點對點通訊相比的魯棒性。
• 在點對點通訊的情況下，可以考慮在軟體級別實現一個“伺服器”。一個隨機選擇的機器人收集整個團隊戰術決策所需的所有輸入，並進行傳輸。在這種情況下，魯棒性沒有直接損失，效率更高。然而，在一個敵對環境中獲取所有機器人的場地資訊並非易事。因此，在每個級別上進行點對點通訊，這意味著每個機器人根據其獲得的資訊確定戰術決策（與其他機器人並行），並將資訊進行傳輸，這可能是最初的更好解決方案。
• 最小的通訊將導致最大的魯棒性。但是，效率的顯著下降是不可忽視的。在 RoboCup 的世界中（例如與航空相比），由於複雜性的增加、成本的提高等等，冗餘大多數情況下沒有被實現。在這種“約束”下，你失去了對網路故障的魯棒性。然而，仍然可以透過將通訊最小化到必要的最小程度，並建立一種不同型別的魯棒性來利用可用資源。畢竟，機器人越自主，只進行必要的通訊，魯棒性就越高。
• 通常優先考慮效能，而不是機器人的物理狀態。物理損壞（例如碰撞）幾乎是不可避免的，針對它們的許多可能的加固措施會導致效能完全下降。這個缺點表明，物理魯棒性必須達到一定程度，因為不要忘記這是一場需要你的團隊表現的比賽！
這些考慮不能侷限於一個 C，而更有可能是跨部門的設計標準。很明顯，沒有一定程度的魯棒性，就很難實現效能和效率。
自主性與魯棒性一樣，是一個超越所有其他設計方面的設計方面。由於通訊仍然對故障非常敏感，因此每個機器人能夠自主執行至關重要。每個機器人一定程度的自主性將自動導致對團隊故障的魯棒性。
設計挑戰：踢足球、戰術、通訊、能量管理
設計約束：自主性、安全、尺寸、重量
設計挑戰與設計約束（由組織規定）共同塑造了設計需求。儘管這些約束大多是非定量的，但其中一些設計需求是明確規定的。主要是客戶的這些要求：根據 RoboCup 規則踢足球。就像在每個設計環境中一樣，規則是保持設計儘可能簡單，主要關注兩個最重要的設計標準。
有關這些機器人設計的更多技術資訊，請參閱 附錄。
要做的事情
• 預計在任何型別的通訊錯誤的情況下發生的另一種情況。當必須做出戰術決策時，不要讓機器人等到它擁有所有可能的資訊，而是要預見到一定的自主性，這樣機器人即使沒有所有資訊，也可以快速做出決策。
• 注意在選擇魯棒性而不是效率和效能，或者反之亦然時所做出的權衡。不可能同時獲得這兩個標準的最大值，所以在開始之前要明智地選擇哪個標準優先順序最高。
• 考慮到有限的設計時間，建議將重點放在團隊上，而不是將所有精力都投入到一個機器人上。因此，請使用“高階設計”中描述的方法，並使用標準組件，儘量避免調整和重新程式設計。這樣，可以將更多寶貴的時間和精力花在團隊合作方面。透過在現場的經驗，可以在系統級別進行調整。
• 預見一種透過使用外部連結來上傳新的驅動程式或軟體（透過電線）來將新規則實現到配置中的方法。在多個管理程式或戰術之間進行切換是一種明智的做法。
不要
• 透過客戶端-伺服器配置進行通訊，這會建立一個單點故障（如前所述）。
• 嘗試實現一個機器人能夠檢測另一個機器人是否發生嚴重故障。透過通訊來實現這一點非常困難：需要傳送什麼訊號，如果其通訊系統出現故障怎麼辦？只有透過對其他機器人的運動進行持續的解釋或逆向處理，才能實現某種故障檢測。