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