gazebo restart and load urdf

 sudo lsof -i :11345 正是要找出誰佔住 Gazebo Master 的 11345 連接埠。

接下來的動作分兩步：

---

1. 看輸出結果

通常會出現類似：

COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
gzserver 1234 ubuntu  ...  TCP  *:11345 (LISTEN)

或

gzclient 5678 ubuntu  ...  TCP  *:11345 (LISTEN)

重點是 COMMAND 與 PID。

---

2. 終止佔用者

假設輸出顯示：

• gzserver 1234 → 就是之前殘留的模擬伺服器。

• gzclient 5678 → GUI 端也可能卡住。

終止方法：

# 溫和 kill
kill 1234
kill 5678

# 如果還不死，再強制 kill -9
sudo kill -9 1234

確認是否釋放：

sudo lsof -i :11345

沒有任何輸出就表示 11345 已經空出來。

---

3. 重新啟 Gazebo

export ALSOFT_DRIVERS=null
export LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe LIBGL_DRI3_DISABLE=1
gzserver --verbose empty.world \
  -s libgazebo_ros_init.so \
  -s libgazebo_ros_factory.so \
  -s libgazebo_ros_force_system.so

4 另開終端再跑 spawn：

load urdf to gzserver 

ros2 run gazebo_ros spawn_entity.py -entity twowheel_amr -file /path/to/twowheel.urdf


ros2 run gazebo_ros spawn_entity.py 執行詳細說明
spawn_entity.py 腳本是 ROS2 與 Gazebo 交互的核心工具之一，它的主要作用是將機器人模型（URDF 或 SDF 格式）動態地載入到正在運行的 Gazebo 模擬環境中。
指令分解：
ros2 run：這是 ROS2 的標準指令，用於運行一個套件中的可執行腳本。
gazebo_ros：指定要運行腳本的套件名稱。
spawn_entity.py：要運行的 Python 腳本。
腳本參數：
-entity twowheel_amr：
-entity：指定要在 Gazebo 中生成的實體名稱。
twowheel_amr：這是你給機器人實體起的名字。這個名字在 Gazebo 模擬世界中是唯一的。
-file twowheel.urdf：
-file：指定要載入的機器人描述檔案的完整路徑。
twowheel.urdf：這通常是你的 URDF 或 XACRO 檔案經過處理後生成的 URDF 格式。
執行過程：
客戶端節點啟動：ros2 run 指令啟動 spawn_entity.py 腳本，它會作為一個 ROS2 節點。
讀取模型檔案：腳本讀取 -file 參數指定的 twowheel.urdf 檔案內容。
尋找服務：腳本嘗試連接到 gzserver 提供的 ROS 服務 /spawn_entity。
發送服務請求：如果成功連接到服務，腳本會將機器人實體的名稱（twowheel_amr）和 URDF 檔案的內容作為數據包，通過服務請求發送給 gzserver。
Gazebo 載入模型：gzserver 接收到請求後，會解析 URDF 檔案，在模擬世界中創建機器人的所有連結、關節、視覺、碰撞模型，並初始化所有 Gazebo 插件。
結果回饋：gzserver 返回一個服務響應，告訴 spawn_entity.py 腳本模型是否成功生成。
為何使用 spawn_entity.py？
動態載入：它允許你在 Gazebo 運行時動態地添加或移除機器人模型，而不需要每次都重新啟動整個 Gazebo 伺服器。
與 ROS2 整合：它是一個標準的 ROS2 節點，可以直接在 launch 檔案中使用，方便自動化啟動整個模擬環境。