基礎服務(BASE SERVICES)
前言大綱
本文檔假定您了解 SDK 文檔中有關網絡(NETWORKING)的涵蓋的材料。基礎服務提供 Spot API 其餘部分使用的架構粘合劑。這些服務包括身份驗證、服務發現和時間同步。許多應用程序將在啟動時使用基礎服務,然後再使用堆棧中更高的服務,例如機器人狀態、機器人命令和自主性。
robot-id
robots-id 服務提供有關 Spot 機器人的元數據(metadata)。它通常是再啟動引導 連接 Spot 時訪問的第一個服務。
/// Robot identity information, which should be static while robot is powered-on.
message RobotId {
/// A unique string identifier for the particular robot.
string serial_number = 1;
/// Type of robot. E.g., 'spot'.
string species = 2;
/// Robot version/platform.
string version = 3;
/// Version information about software running on the robot.
RobotSoftwareRelease software_release = 4;
/// Optional, customer-supplied nickname.
string nickname = 5;
/// Computer Serial Number. Unlike serial_number, which identifies a complete robot,
/// the computer_serial_number identifies the computer hardware used in the robot.
string computer_serial_number = 6;
}
應用程序可以使用 robot-id 的方式,示例包括:
- 在要連接的可能 Spot 機器人列表中顯示機器人暱稱(nickname)。請注意,同一個 Spot 可以隨著時間的推移更改暱稱(nickname)。多個 Spot 可以共享相同的暱稱(nickname)。
- 使用 serial_number 作為緩存的用戶名/密碼或有關機器人的其他數據的密鑰。 Serial_number 永遠不會隨時間改變,並且保證是唯一的。
- 檢查 software_release 版本以確定應用程序是否與 Spot 兼容,或根據 Spot 軟件版本更改行為。
- 與幾乎所有其他服務不同,robot-id 服務不需要經過身份驗證的用戶來訪問它。
授權auth
auth 服務用於向 Spot 驗證用戶。成功的身份驗證嘗試會返回一個用戶令牌(token),該令牌(token)必須包含在 RPC 中,以便除 robots-id 和 auth 之外的所有服務都可以訪問。用戶令牌是一個 JWT 令牌,有效期為 12 小時,只能用於訪問發布它的機器人上的服務。令牌不可轉讓給其他機器人。
有兩種方法可以對用戶進行身份驗證:
- 使用用戶名和密碼組合。用戶名和密碼與使用機器人管理控制台網頁管理的用戶名和密碼相同。
- 通過刷新現有的有效用戶令牌。此方法可用於支持長期存在的客戶端應用程序,以最大限度地減少重複提示輸入用戶名/密碼的情況。
目錄directory
Spot 的 API 由多種服務組成。其中一些服務隨 Spot 一起提供。某些服務由在 Spot CORE 上運行的外掛負載或應用程序提供。目錄(directory)服務用於發現當前在 Spot 上運行的服務。
請注意,如果使用 Python 客戶端函式庫構建的應用程序僅使用內置服務,則它可能永遠不需要訪問目錄(directory)服務。但是,Python 客戶端函式庫使用目錄(directory)服務來建立與內置服務的連接。
服務由 ServiceEntry 消息描述,可以使用 ListServiceEntries RPC 列出。Python 函式庫中包含的命令行實用程序是列出這些選項的快捷方式,如下所示。
$ py.exe -3 -m bosdyn.client my-spot dir list
name type authority tokens
----------------------------------------------------------------------------------------------------
auth bosdyn.api.AuthService auth.spot.robot
directory bosdyn.api.DirectoryService api.spot.robot user
directory-registration bosdyn.api.DirectoryRegistrationService api.spot.robot user
estop bosdyn.api.EstopService estop.spot.robot user
graph-nav-service bosdyn.api.graph_nav.GraphNavService graph-nav.spot.robot user
服務的 名稱(name) 是一個用戶友善使用的名稱,它提供了有關服務可以做什麼的一些語義信息。該名稱(name) 在所有服務中必須是唯一的。例如,auth 是提供身份驗證的服務的名稱。
服務的 類型(type) 是服務實現的gRPC服務介面。例如,bosdyn.api.AuthService 是身份驗證(auth)服務的類型(type) 。同一類型可以存在多個服務(儘管名稱和權限不同)。例如,相機外掛負載可以託管 bosdyn.api.ImageService,它與 Spot 內置的介面共享相同的介面。
該權限(authority) 用於將 RPC 請求定向到正確的服務。權限(authority)和服務類型(type)的組合創建一個 URL。例如,權限(authority) 服務的 URL:https://auth.spot.robot/bosdyn.api.AuthService 。該命名方案由 gRPC 本身定義。所有權限(authority)的格式必須為 <authority-name>.spot.robot。不同類型的多個服務可以共享相同的權限。
服務指定是否需要用戶令牌(token)來訪問服務。這在上面示例中的令牌(token)列中進行了演示。大多數服務需要登錄用戶,但少數不需要。
請注意,並非所有服務都在 Spot 啟動時向目錄服務註冊。應用程序可能需要定期輪詢目錄(directory)服務以捕獲已進行的更改。內置服務可能需要幾秒鐘才能在系統啟動時註冊。外掛負載提供的服務可能會在以後註冊。
時間同步time-sync
時間對於解釋何時記錄傳感器數據以及控制 Spot 都至關重要。 Spot API 使用稱為“機器人時間(Robot Time)”的單個時鐘作為時間命令的基礎。
Spot 的時鐘可能與應用程序的時鐘不同。例如,在單個時間點 Spot 可能認為是 16:01,而應用程序的時鐘可能會在 15:01 晚一個小時。如果應用程序將 Spot 的時鐘視為與它自己的時鐘在同一時間,則可能會出現問題。來自 Spot 的新傳感器數據將被解釋為在未來生成。發出以在 10 秒內過期的命令將被 Spot 拒絕,因為它們看起來已經過期。
時間同步(time-sync)服務用於估計應用程序時鐘和 Spot 時鐘之間的偏移。每個 TimeSyncUpdate RPC 提供形成單個測量的發送和接收時間戳。最初偏移量是未知的。在觀察到幾次連續且一致的測量後,它會被初始化。計算出偏移量後,應用程序可以將 Spot 時鐘中記錄的時間轉換為應用程序時鐘,反之亦然。偏移會緩慢更新以解決時鐘漂移。
使用 Python 函式庫構建的應用程序可以使用 TimeSyncThread 來簡化與時間同步(time-sync) 服務的交互。TimeSyncThread 產生一個後台程序(thread),該程序(thread)建立初始偏移估計,並定期更新估計以避免漂移問題。它還公開了許多轉換時間或確定當前估計值的方法。有關如何使用 TimeSyncThread 的示例,請參閱 : time_sync example。
這個估計純粹是在應用層。這很重要,原因有二:
- Spot 的時鐘和應用程序的時鐘都沒有調整,不需要管理員/root 權限。
- 一個客戶端可能會連接到多個彼此不同步的 Spot 機器人。
需要高精度計時的客戶端,例如在機器人移動時收集數據的外掛載荷傳感器,應改為使用 NTP 與機器人同步。
留言
張貼留言
Aron阿龍,謝謝您的留言互動!