這篇不從新聞角度討論事件只從開發(fā)視角聊一件事機器人運動會背后到底考的是什么技術(shù)。媒體鏡頭里是一臺臺跑動、抓取、避障的機器人但落到開發(fā)者面前核心是一條完整的鏈路機器人怎么選型導(dǎo)航怎么跑通視覺怎么識別多機怎么通信現(xiàn)場怎么調(diào)試數(shù)據(jù)怎么回放。如果你準(zhǔn)備參加機器人運動會、機器人競賽或者只是想借這類賽事驗證自己的算法那最先要看的是幾個硬指標(biāo)機器人支持 ROS2 還是廠家自研 SDK能不能先跑仿真驗證有沒有視覺和點云接口主控算力是什么級別現(xiàn)場是否允許無線調(diào)試有沒有可靠的急停和安全機制。這些問題比“誰的機器人跑得快”更影響備賽進度。下面這套技術(shù)路徑比較通用覆蓋項目分類、環(huán)境準(zhǔn)備、導(dǎo)航避障、視覺識別、日志記錄和性能觀察。北京這次機器人運動會只是引子實際各類機器人賽事和運動會的做法高度相似。具體比賽項目清單、規(guī)則和硬件限制以主辦方現(xiàn)場公布為準(zhǔn)。1. 核心能力速覽先給一張速覽表方便快速判斷自己手上的團隊和機器人能不能參賽以及需要補哪塊。能力項說明項目類型人形機器人、四足機器人、輪式機器人、工業(yè)機器人、仿真機器人等多類競賽常見技術(shù)棧ROS2、Python、C、Gazebo 仿真、SLAM 導(dǎo)航、OpenCV / YOLO 視覺識別主要驗證能力運動控制、導(dǎo)航避障、視覺識別、多機通信、遙操作、自動任務(wù)執(zhí)行推薦硬件具備 4 核以上 CPU 的筆記本即可做仿真實機按機器人主控算力評估顯存依賴純導(dǎo)航和運動控制不需要獨立顯卡視覺識別可優(yōu)先用 CPU 模型若有 GPU 則更穩(wěn)支持平臺Ubuntu 22.04、Windows 部分仿真可通過 WSL 使用實機一般用 Linux啟動方式Docker、命令行、launch 文件、仿真環(huán)境一鍵啟動是否支持 APIROS2 話題 / 服務(wù)接口天然支持進程間調(diào)用可用于自動化測試是否支持批量任務(wù)可通過 ros2 bag 批量記錄、Python 腳本批量跑場景適合場景備賽訓(xùn)練、機器人選型、算法驗證、多機器人調(diào)度測試、教學(xué)實驗從這張表能看出機器人運動會的門檻不只是“買一臺機器人”而是“能不能把機器人在真實場地里穩(wěn)定跑完一個任務(wù)”。仿真環(huán)境可以大幅降低前期試錯成本。2. 適用場景與使用邊界機器人運動會適合這幾類人備賽學(xué)生團隊想在賽前快速驗證導(dǎo)航和視覺方案的開發(fā)者企業(yè)工程師想通過賽事項目評估機器人平臺的穩(wěn)定性教學(xué)場景用運動會項目驅(qū)動學(xué)生完成從建圖到自動導(dǎo)航的完整項目。它能解決的問題也很明確把零散的機器人技術(shù)點串成完整任務(wù)。比如一個“自動搬運”項目就同時涉及建圖、定位、路徑規(guī)劃、避障、機械臂抓取和任務(wù)調(diào)度。這個過程能逼你把 ROS2 通信、運動控制、視覺識別和異常處理全部走一遍。但也有不適合的場景沒有安全圍欄和急停機制就直接做高速人機交互實驗。對機器人底層機制還不熟悉就直接上強化學(xué)習(xí)或大模型控制。用未授權(quán)的數(shù)據(jù)集訓(xùn)練識別模型或者把現(xiàn)場觀眾人臉數(shù)據(jù)隨意上傳。比賽規(guī)則都沒確認就按自己的理解先把機器人改裝到“高性能”狀態(tài)結(jié)果不符合賽項限制。使用邊界要提前劃定。涉及人臉、車輛、隱私數(shù)據(jù)的識別類項目必須確認數(shù)據(jù)來源合法并且只在本機測試。涉及工業(yè)機器人或人形機器人測試必須在明確的安全防護措施下進行。涉及到四足機器人和人形機器人的遙控要注意電機負載和關(guān)節(jié)限位避免因失控導(dǎo)致設(shè)備損壞或人員受傷。3. 機器人運動會項目分類與技術(shù)棧拆解機器人運動會的項目通常能分成幾大類每類的技術(shù)側(cè)重點完全不同。3.1 人形機器人項目常見形式是競速、體操、越障或者完成指定動作。技術(shù)點集中在步態(tài)控制、姿態(tài)平衡、關(guān)節(jié)運動規(guī)劃和視覺定位。硬件上需要高扭矩關(guān)節(jié)電機、IMU 慣性測量單元和足夠算力的主控。技術(shù)棧上運動控制可能用廠家 SDK也可能用 ROS2 控制關(guān)節(jié)視覺規(guī)劃階段常用 OpenCV 做標(biāo)記識別再配合深度相機測距。如果項目允許遙操作還需要考慮手柄或 VR 頭顯接入降低算法開發(fā)復(fù)雜度。3.2 四足機器人項目常見形式是越障、爬坡、跟隨、定點巡邏。四足機器人的核心是步態(tài)規(guī)劃和機身姿態(tài)控制。較成熟的方案是宇樹、小米等廠家的 SDK配合 ROS2 接口做上層應(yīng)用。運動會場景里四足機器人通常要跑“視覺跟隨”“自主導(dǎo)航”“摔倒恢復(fù)”這類任務(wù)。你需要重點測試的不是單步動作而是連續(xù)任務(wù)下的穩(wěn)定性。比如機器人在不平整路面上走 10 米能否保持位姿規(guī)劃不漂移。3.3 輪式機器人導(dǎo)航項目這是門檻最低、參與度最高的類別。常見任務(wù)是在場地內(nèi)從 A 點走到 B 點或者巡檢多個目標(biāo)點并避讓障礙物。技術(shù)棧相對固定激光雷達或深度相機建圖使用 Cartographer 或 SLAM Toolbox定位用 AMCL規(guī)劃用 Nav2。如果你第一次參加運動會建議從這類項目開始因為輪式機器人硬件成本低、調(diào)試鏈路短出成績概率高。3.4 工業(yè)機器人項目常見形式是碼垛、裝配、分揀。這種項目通常使用 ABB、發(fā)那科、庫卡或國產(chǎn)協(xié)作機器人。技術(shù)點不再是運動控制本身而是軌跡規(guī)劃、抓取位姿標(biāo)定、視覺引導(dǎo)和 PLC 聯(lián)動。工業(yè)機器人項目對安全和流程要求最高。賽前必須完成碰撞檢測測試、工作空間限制設(shè)置和急停驗證。視覺引導(dǎo)環(huán)節(jié)要先做相機與機器人坐標(biāo)系的手眼標(biāo)定標(biāo)定誤差會直接決定抓取成功率。3.5 仿真實戰(zhàn)項目現(xiàn)在越來越多賽事包含仿真環(huán)節(jié)或者在仿真環(huán)境里先跑初賽。常見仿真平臺有 Gazebo、Webots、Isaac Sim以及一些賽事官方指定的仿真器。仿真項目看起來“只要動代碼”實際難點是仿真和真機不一致性。Gazebo 里能跑通的導(dǎo)航真機上可能因為輪子打滑、里程計噪聲而失敗。建議仿真用于驗證流程和算法邏輯真機用于驗證機械和傳感器性能兩者不能互相替代。4. 環(huán)境準(zhǔn)備與前置條件不管參加哪個項目環(huán)境準(zhǔn)備是第一道坎。建議團隊統(tǒng)一使用一個版本組合避免“一個人能跑另一個人跑不了”的問題。4.1 操作系統(tǒng)與軟件版本最穩(wěn)妥的組合是 Ubuntu 22.04 搭配 ROS2 Humble這也是當(dāng)前絕大多數(shù)機器人開發(fā)教程的默認環(huán)境。Windows 系統(tǒng)可以用 WSL 或者 Docker但涉及 USB 攝像頭、串口和雷達接入時還是原生 Linux 更省心。以下命令用于檢查基礎(chǔ)環(huán)境實際版本號以你安裝的發(fā)行版為準(zhǔn)# 檢查系統(tǒng)版本 lsb_release -a # 檢查 ROS2 是否安裝 ros2 --version # 檢查仿真器 gazebo --version # 檢查 Python python3 --version # 檢查顯卡驅(qū)動可選 nvidia-smi如果命令提示找不到說明對應(yīng)的依賴還沒有安裝。不要跳過這個檢查步驟后面很多問題都是環(huán)境不一致導(dǎo)致的。4.2 機器人選型建議選型直接決定備賽效率。如果團隊沒有指定硬件按這個優(yōu)先級判斷先選有 ROS2 官方支持或穩(wěn)定 SDK 的機器人不要選資料很少的半開源平臺。導(dǎo)航類比賽優(yōu)先選輪式差速底盤帶激光雷達價格適中且調(diào)試容易。四足和人形機器人先確認是否支持仿真器和真機同一套代碼否則開發(fā)成本會翻倍。如果要跑視覺識別確定主控能跑 YOLO 或者輕量級分類模型。算力不夠時優(yōu)先使用 CPU 版 ONNX 模型或者把識別任務(wù)放到上位機。4.3 網(wǎng)絡(luò)與通信環(huán)境運動會現(xiàn)場通常人多、Wi-Fi 復(fù)雜。多機通信和遠程調(diào)試容易受影響。建議準(zhǔn)備一個獨立的 5G 頻段路由器或者直接用網(wǎng)線連接機器人和調(diào)試電腦。現(xiàn)場無線調(diào)試前先用有線方式把基本功能都驗證一遍最后再測試無線環(huán)境的延遲和丟包。5. 從零搭建一個最小可跑通的機器人任務(wù)用一個“導(dǎo)航避障 視覺識別”的最小任務(wù)作為示例這套流程適用于大多數(shù)輪式機器人運動會項目。5.1 創(chuàng)建 ROS2 工作空間mkdir -p ~/robot_ws/src cd ~/robot_ws/src # 創(chuàng)建功能包依賴 rclpy 和 geometry_msgs ros2 pkg create robot_demo --build-type ament_python --dependencies rclpy geometry_msgs sensor_msgs cv_bridge創(chuàng)建完成后后續(xù)代碼都放在robot_demo/robot_demo/目錄下啟動文件放在launch/目錄下。5.2 編寫鍵盤遙控節(jié)點鍵盤遙控是調(diào)試機器人的基礎(chǔ)功能。先寫一個簡單的速度發(fā)布節(jié)點通過鍵盤的 WASD 控制機器人前后左右按 Q 退出。import rclpy from rclpy.node import Node from geometry_msgs.msg import Twist import sys import termios import tty class TeleopNode(Node): def __init__(self): super().__init__(teleop_node) self.publisher self.create_publisher(Twist, /cmd_vel, 10) self.speed 0.2 self.turn 0.4 def publish_vel(self, linear, angular): msg Twist() msg.linear.x linear msg.angular.z angular self.publisher.publish(msg) def run(self): print(WASD 控制移動Q 退出) fd sys.stdin.fileno() old_settings termios.tcgetattr(fd) try: tty.setraw(fd) while True: ch sys.stdin.read(1) if ch q: self.publish_vel(0.0, 0.0) break elif ch w: self.publish_vel(self.speed, 0.0) elif ch s: self.publish_vel(-self.speed, 0.0) elif ch a: self.publish_vel(0.0, self.turn) elif ch d: self.publish_vel(0.0, -self.turn) else: self.publish_vel(0.0, 0.0) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old_settings) def main(argsNone): rclpy.init(argsargs) node TeleopNode() try: node.run() except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown()這個節(jié)點只做一件事把鍵盤輸入轉(zhuǎn)成/cmd_vel話題上的速度指令。如果機器人沒反應(yīng)先檢查rostopic echo /cmd_vel是否有數(shù)據(jù)再檢查底盤驅(qū)動是否訂閱了同一個話題名。5.3 啟動導(dǎo)航與仿真如果使用 Nav2啟動流程通常是先啟動機器人模型和傳感器驅(qū)動再啟動定位和規(guī)劃模塊。下面是一份 launch 文件模板實際包名和路徑需要替換成你自己的配置# launch/demo_launch.py from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( packagerobot_demo, executableteleop_node, nameteleop_node, outputscreen ), Node( packagenav2_bringup, executablebringup_launch.py, namenav2_bringup, parameters[params/nav2_params.yaml] ) ])在真機場景下還需要啟動激光雷達驅(qū)動和底盤驅(qū)動。運動會現(xiàn)場最容易犯的錯誤是“只啟動了導(dǎo)航模塊忘了啟動底盤驅(qū)動”導(dǎo)致/cmd_vel話題沒有訂閱者。建議每次啟動前運行ros2 topic list檢查關(guān)鍵話題是否存在。5.4 視覺識別節(jié)點示例以 YOLO 為例可以直接用 ONNX 模型配合 OpenCV 做推理。下面的代碼是一個通用模板輸入為圖像話題輸出為檢測到目標(biāo)后的坐標(biāo)信息。import cv2 import numpy as np import rclpy from rclpy.node import Node from sensor_msgs.msg import Image from cv_bridge import CvBridge class VisionNode(Node): def __init__(self): super().__init__(vision_node) self.subscription self.create_subscription( Image, /camera/image_raw, self.image_callback, 10 ) self.bridge CvBridge() self.net cv2.dnn.readNetFromONNX(model/yolov8n.onnx) def image_callback(self, msg): frame self.bridge.imgmsg_to_cv2(msg, desired_encodingbgr8) blob cv2.dnn.blobFromImage(frame, 1/255.0, (640, 640), swapRBTrue) self.net.setInput(blob) outputs self.net.forward() self.get_logger().info(f推理輸出 shape: {outputs.shape}) def main(argsNone): rclpy.init(argsargs) node VisionNode() rclpy.spin(node) node.destroy_node() rclpy.shutdown()這個節(jié)點的重點不是識別精度而是驗證“攝像頭圖像 - 推理 - 輸出結(jié)果”這個鏈路是否穩(wěn)定。視覺識別在運動會現(xiàn)場最大的坑是光照變化仿真環(huán)境調(diào)好的閾值到了真實場地很可能失效所以現(xiàn)場必須重新標(biāo)定。6. 功能測試與效果驗證完成基礎(chǔ)開發(fā)后按功能逐項測試。建議用表格記錄每一輪測試結(jié)果不要憑感覺判斷。6.1 鍵盤遙控測試測試目的確認底盤驅(qū)動、電機、話題通信正常。操作步驟啟動底盤驅(qū)動再啟動遙控節(jié)點按 WASD 控制機器人移動。預(yù)期結(jié)果機器人前進、后退、左右轉(zhuǎn)方向正確松開按鍵后停止。判斷標(biāo)準(zhǔn)剎車沒有明顯慣性滑行遙控延遲在可接受范圍內(nèi)。常見失敗電機方向接反、話題名不匹配、遙控節(jié)點沒有發(fā)布數(shù)據(jù)。6.2 導(dǎo)航目標(biāo)點測試測試目的驗證建圖、定位、路徑規(guī)劃和避障。操作步驟先手動遙控建圖保存地圖再啟動 AMCL 和 Nav2使用 RViz2 的 2D Goal Pose 發(fā)布目標(biāo)點。預(yù)期結(jié)果機器人規(guī)劃出可行路徑并抵達目標(biāo)點遇到障礙物時重新規(guī)劃。判斷標(biāo)準(zhǔn)無劇烈抖動無反復(fù)橫擺能繞開靜態(tài)障礙物。常見失敗地圖質(zhì)量差、里程計漂移、代價地圖參數(shù)不合理。6.3 視覺識別測試測試目的驗證目標(biāo)識別和本地圖像處理鏈路。操作步驟使用一張本地圖片測試模型確認可以輸出類別和坐標(biāo)再接入攝像頭實時測試。預(yù)期結(jié)果目標(biāo)框穩(wěn)定顯示推理幀率滿足任務(wù)需要。判斷標(biāo)準(zhǔn)漏檢率低誤檢率可接受推理延遲不影響任務(wù)執(zhí)行。常見失敗模型格式不兼容、圖像尺寸不匹配、曝光過強導(dǎo)致檢測不到目標(biāo)。6.4 多機通信測試如果運動會項目涉及多臺機器人協(xié)作多機通信是必測項。# 在機器人 1 上發(fā)布消息 ros2 topic pub /robot1/status std_msgs/msg/String data: ready --once # 在機器人 2 上訂閱消息 ros2 topic echo /robot1/status兩臺設(shè)備要保證處于同一局域網(wǎng)并且ROS_DOMAIN_ID一致?，F(xiàn)場如果出現(xiàn)“話題能看到但收不到數(shù)據(jù)”先檢查防火墻和網(wǎng)段再檢查 DDS 發(fā)現(xiàn)協(xié)議是否被隔離。6.5 仿真與真機一致性測試賽前至少做一次“同一套代碼仿真和真機各跑一遍”的對比測試。重點觀察機器人到位后是否存在明顯偏差。里程計漂移程度。視覺識別的顏色和亮度差異。通信延遲差異。如果仿真里任務(wù)完成率 90%真機只有 40%說明 Sim2Real 的 gap 太大需要先調(diào)傳感器模型和底盤參數(shù)不要直接改任務(wù)邏輯。7. 日志記錄與批量調(diào)試運動會備賽過程中最容易被忽視的就是日志。沒有日志現(xiàn)場出了問題只能靠肉眼觀察效率極低。7.1 使用 ros2 bag 記錄話題數(shù)據(jù)# 記錄所有話題數(shù)據(jù)到當(dāng)前目錄 ros2 bag record -a -o bag_20260826_1000 # 記錄指定話題 ros2 bag record -o nav_data \ /cmd_vel /odom /scan /map記錄完成后可以用離線回放的方式復(fù)現(xiàn)問題ros2 bag play bag_20260826_1000回放時可以用 RViz2 訂閱原始話題觀察機器人當(dāng)時的傳感器數(shù)據(jù)和規(guī)劃結(jié)果。這個能力在處理“偶發(fā)避障失敗”問題時特別有用。7.2 批量跑測試場景如果項目要求機器人多次執(zhí)行同一個任務(wù)建議寫一個自動化腳本記錄每次測試的參數(shù)和結(jié)果。import subprocess import time import json from pathlib import Path results [] for i in range(5): start time.time() result subprocess.run( [ros2, launch, robot_demo, task.launch.py], capture_outputTrue, textTrue, timeout120 ) elapsed time.time() - start results.append({ round: i 1, success: result.returncode 0, elapsed: round(elapsed, 2) }) Path(test_results.json).write_text( json.dumps(results, indent2, ensure_asciiFalse) )批量測試時輸出目錄要按日期和場景分層。建議目錄結(jié)構(gòu)如下robot_ws/ ├── bags/ │ └── 20260826/ │ ├── task1_round1/ │ └── task1_round2/ ├── test_results/ │ └── 20260826_task1.json ├── maps/ └── logs/8. 資源占用與性能觀察機器人運動會現(xiàn)場性能和穩(wěn)定性比功能齊全更重要。核心觀察點有三個主控 CPU 占用、內(nèi)存占用、傳感器和規(guī)劃節(jié)點的實時性。常用命令# 查看所有 ROS2 節(jié)點的執(zhí)行頻率 ros2 topic hz /odom ros2 topic hz /scan ros2 topic hz /cmd_vel # 查看系統(tǒng)資源占用 htop # 查看 GPU 占用如果視覺識別用 GPU nvidia-smi -l 1重點關(guān)注幾個指標(biāo)/odom頻率是否穩(wěn)定。差速底盤通常 30Hz 到 50Hz頻率突然下降說明里程計計算阻塞。/scan頻率是否穩(wěn)定。激光雷達頻率通常是 10Hz如果降頻可能是 CPU 負載過高。/cmd_vel是否持續(xù)輸出。導(dǎo)航過程中如果長時間沒有新的速度指令說明規(guī)劃器可能死鎖或者路徑丟失。運動控制本身不占 GPU但視覺識別會。如果主控算力緊張優(yōu)先做三件事降低輸入圖像分辨率從 1280 降到 640推理延遲通常能下降一半。降低推理頻率從每幀推理改為每 3 幀推理一次。關(guān)閉不必要的可視化界面RViz2 的 3D 渲染在低算力平臺上非常耗 CPU。仿真環(huán)境的資源占用通常比真機高因為還要渲染 3D 場景。如果本機無法流暢跑仿真可以考慮降低仿真器畫質(zhì)或者換用輕量級仿真平臺。9. 常見問題與排查方法下表匯總了機器人運動會備賽中最高頻的幾類問題排查順序先行后難。問題現(xiàn)象可能原因排查方式解決方案機器人無響應(yīng)底盤驅(qū)動未啟動運行ros2 topic list檢查是否有速度話題啟動底盤驅(qū)動檢查電源和串口遙控方向相反電機接線或驅(qū)動參數(shù)錯誤給正向速度指令觀察運動方向在驅(qū)動配置中反轉(zhuǎn)電機方向?qū)Ш揭?guī)劃失敗地圖不完整或里程計漂移回放 bag 看/map和/odom重新建圖檢查輪距和編碼器參數(shù)導(dǎo)航反復(fù)橫擺代價地圖參數(shù)不合理調(diào)整膨脹半徑觀察/local_costmap增大膨脹半徑降低最大速度視覺識別漏檢嚴(yán)重光照變化或模型過擬合現(xiàn)場采集圖片離線測試采集更多現(xiàn)場樣本調(diào)整曝光仿真和真機表現(xiàn)不一致傳感器噪聲模型差異大對比兩個環(huán)境的里程計數(shù)據(jù)在仿真中加入噪聲模型調(diào)整標(biāo)定多機通信不穩(wěn)定網(wǎng)絡(luò)隔離或 DDS 配置不一致檢查兩端ROS_DOMAIN_ID和網(wǎng)段統(tǒng)一配置關(guān)閉防火墻或添加白名單主控 CPU 占用過高可視化或推理耗資源運行htop查看進程關(guān)閉 RViz 渲染降低圖像分辨率機器人突然停止急停觸發(fā)或看門狗超時查看底盤驅(qū)動日志和急停狀態(tài)確認急停復(fù)位調(diào)整看門狗參數(shù)bag 記錄數(shù)據(jù)過大話題數(shù)據(jù)量太大檢查磁盤剩余空間指定關(guān)鍵話題記錄設(shè)置壓縮排查問題時要遵循一個原則先確認硬件狀態(tài)再查話題數(shù)據(jù)最后才懷疑算法問題。很多時候?qū)Ш揭?guī)劃失敗是因為雷達沒轉(zhuǎn)或者地圖文件路徑錯誤而不是算法 bug。10. 最佳實踐與下一步結(jié)合運動會備賽的常見節(jié)奏這里給幾條工程化建議。第一第一次跑通任務(wù)時不要追求高指標(biāo)。先用最低速度、最小地圖、最簡單場景把全鏈路跑通再逐步增加難度。這樣能快速定位是哪一環(huán)不穩(wěn)定而不是所有環(huán)節(jié)一起出問題。第二鎖定版本。團隊內(nèi)部統(tǒng)一 ROS2 版本、仿真器版本、機器人 SDK 版本和模型版本。備賽后期最怕有人偷偷升級依賴導(dǎo)致其他人代碼報錯。建議在項目目錄里放一份requirements.txt或者environment.yaml記錄所有關(guān)鍵依賴。第三所有關(guān)鍵話題和數(shù)據(jù)都要有日志。部署現(xiàn)場問題復(fù)現(xiàn)的成本很高ros2 bag 是最好的“行車記錄儀”。至少把/cmd_vel、/odom、/scan、/map和視覺圖像話題記錄到本地。第四安全問題不能讓步。四足機器人、人形機器人和工業(yè)機器人的關(guān)節(jié)力量足夠造成傷害調(diào)試前必須有急停裝置和物理隔離?，F(xiàn)場測試要劃定安全區(qū)域禁止人員在機器人路徑上停留。第五識別到目標(biāo)后不要只做“顯示框”要落到底層邏輯。視覺節(jié)點輸出的坐標(biāo)應(yīng)該直接轉(zhuǎn)換為機器人坐標(biāo)系下的目標(biāo)點并發(fā)布給導(dǎo)航模塊形成“識別 - 定位 - 導(dǎo)航 - 執(zhí)行”的閉環(huán)。這比單獨調(diào)高識別精度更有比賽價值。下一步可以做三件事一是把仿真環(huán)境里的路徑規(guī)劃參數(shù)與真機統(tǒng)一盡量縮小 Sim2Real 差異二是如果賽項允許多機協(xié)作提前測試多臺機器人之間的通信和任務(wù)分配三是如果機器人支持遙操作可以考慮 VR 或手柄接入作為復(fù)雜任務(wù)的保底方案。機器人運動會考的不是單點技術(shù)而是把工程鏈路串起來的能力。從建圖到導(dǎo)航從視覺到控制從日志到現(xiàn)場排錯每一步都需要提前演練。建議把這篇里面的檢查清單保存下來備賽時逐項對照。