發表文章

Jetson Orin Nano 開發環境:用 VS Code Remote-SSH 從 Windows 遠端寫程式

拿到 Jetson Orin Nano 之後,第一個問題通常不是 AI 模型,而是「程式要在哪裡寫?」直接在 Jetson 上接螢幕、鍵盤,桌面環境會吃掉不少記憶體,操作也不順;在 Windows 寫好再複製過去,來回傳檔又很麻煩,長程式碼貼進終端機還常被截斷。 比較好的做法是 VS Code Remote-SSH :程式碼和執行環境都留在 Jetson 上,你在 Windows 的 VS Code 裡編輯、開終端機、跑程式,用起來跟開本機資料夾幾乎一樣。Jetson 本身不用接螢幕,只要接上網路就好。 這篇從頭到尾走一次,做到 用 VS Code 透過 SSH 連上 Jetson、打開專案資料夾 為止。 本文環境 項目 內容 開發板 Jetson Orin Nano 8GB(官方 devkit 載板) Jetson 系統 JetPack 6.2(Ubuntu 22.04) 主控端 Windows 10/11,Visual Studio Code 網路 Jetson 與 Windows 電腦在同一個區域網路 文中的 IP、使用者名稱都是範例,請換成你自己的: 範例 代表 192.168.1.50 Jetson 的 IP 位址 jetson-user Jetson 的登入帳號 my_project 你的專案資料夾 運作方式 [ Windows 電腦 ] └── VS Code + Remote-SSH 擴充功能 │ 畫面、按鍵在本機 │ │ 區域網路(SSH,22 埠) ▼ [ Jetson Orin Nano ] └── VS Code Server(第一次連線時自動安裝) ├── 讀寫檔案 ├── 終端機 └── 執行、除錯程式 VS Code 第一次連線時,會自動在 Jetson 的家目錄裝一個小型伺服器( ~/.vscode-server )。之後你在 VS Code 開的檔案、終端機、執行的 Python, 全部都在 Jetson 上 ,所以會直接用到 Jetson 的 GPU、相機與系統套件。 步驟 1:Jetson 端準備 這一步...

Jetson Orin Nano 實戰(一):CSI 相機+YOLOv8 即時物件偵測串流,一次就做對

圖片
把一台 Jetson Orin Nano 接上 CSI 相機,跑 YOLOv8 物件偵測,再用瀏覽器即時看畫面。聽起來很單純,實際動手時卻很容易卡關:相機抓不到、YOLO 慢得像幻燈片、套件裝完 OpenCV 就壞掉…… 這篇是我實際做完一輪後,整理出的 正確順序版 。照著做,可以避開常見的坑。完成後,在區域網路上任何一台電腦的瀏覽器,都能看到帶有偵測框的即時畫面: 推論約 17 ms、畫面約 30 FPS 。 下一篇〈實戰(二)〉會再用 TensorRT,把推論時間從 17 ms 降到 3.6 ms。 本文環境 項目 內容 開發板 Jetson Orin Nano 8GB(Super),官方 devkit 載板 系統 JetPack 6.2(L4T R36.4.x,CUDA 12.6,TensorRT 10.3),Python 3.10 相機 IMX219 CSI 相機(樹莓派 Camera V2 同款感光元件) 操作方式 從 Windows 透過 SSH/VS Code Remote-SSH 遠端操作(Jetson 不必接螢幕) 以下指令若沒有特別說明,都是在 Jetson 的終端機 執行。 先看重點:四個最容易走錯的地方 相機設定完沒有生效 :jetson-io 會新增一個開機項目,但 預設開機項目可能沒有跟著切換 。→ 步驟 1 不要用 pip 直接安裝 PyPI 上的 torch :通用版的 torch 跟 Jetson 的 CUDA 不相容,YOLO 會 默默改用 CPU ,速度慢 5 倍以上。→ 步驟 2 numpy 要維持 1.x、不要裝 opencv-python :Jetson 內建的 OpenCV 支援 GStreamer,CSI 相機全靠它;pip 版的 OpenCV 不支援 GStreamer,numpy 2 則會讓內建的 OpenCV 無法匯入。→ 步驟 3 程式碼不要直接貼進終端機 :長字串容易被截斷。請用 VS Code Remote-SSH 編輯,或用 scp 傳檔。→ 步驟 4 步驟 1:啟用 CSI 相機,並確認設定真的生效 1-1 用 jetson-io 設定相機 sudo /opt/nvidia/jetson-io/jetson-io....

大家都用 AI 寫 Code 了,還需要學 LabVIEW 嗎?一個資深工程師的真心話

圖片
  這幾年不論是參加技術論壇,還是帶新進工程師,我最常被問到的一個問題就是: 「學長,現在 ChatGPT、GitHub Copilot 寫 Python、C++ 那麼厲害,動口不動手就能生出幾百行代碼。在這種 AI 時代,我花時間去學一個要用滑鼠連連看的 LabVIEW,真的還有必要嗎?」 這是一個非常尖銳、也極具現實意義的好問題。身為一個在產線、實驗室和儀控領域摸爬滾打多年的資深 LabVIEW 工程師,我不想盲目地告訴你「LabVIEW 天下第一」,但也不認為它會在短期內被 AI 的浪潮輕易吞噬。 今天這篇文章,我不偏袒任何一方,純粹從 產業現實、技術本質以及職涯發展 的角度,來聊聊學習 LabVIEW 在如今究竟還有沒有必要性。 💻 認清現實:AI 衝擊了什麼?又留下了什麼? 首先我們必須承認,生成式 AI 對傳統「文字型程式語言(如 Python)」的初階代碼撰寫,帶來了毀滅性的效率提升。以前要寫一個網頁爬蟲、一個資料庫連線,可能需要查半天技術文件;現在對 AI 下一句話,10 秒鐘就搞定了。 但是,當戰場轉移到 「自動化測試、工業儀控、軟硬體整合」 時,AI 就會面臨以下幾個巨大的坎: 1. 「文字模型」與「圖形化語言」的天然隔閡 目前的 AI 大模型本質上是處理「文字(Token)」的。Python 的代碼是文字,AI 很好理解;但 LabVIEW 的底層是圖形化的資料流(G 語言)。雖然現在有官方的 NI Nigel AI 或第三方的腳本工具,可以透過文字指令來自動拉線,但只要程式結構一複雜,AI 在視覺化邏輯的布局、記憶體優化上,錯誤率依然偏高。 2. AI 無法通靈「實體硬體的物理特性」 在軟硬體整合的世界裡,寫完程式通常只完成了 30%,剩下的 70% 都在 「Debug(除錯)」 。 為什麼這個 DAQ 卡讀出來的電壓有漣波(Ripple)? 為什麼儀器用 VISA 通訊時,每跑三小時就會因為時基(Timing)卡死一次? 產線上的實體接線有沒有雜訊干擾? 這些牽涉到電路、物理訊號、機械結構的現場問題,AI 看不到、摸不到,也無法通靈。此時,工程師在現場的「硬體調校經驗」,才是決定專案能不能結案的關鍵。 ⚖️ 兩面刃:學與不學的理性得失 要不要學 LabVIEW,取決於你想走什麼樣的職涯路徑。我們不妨把正反兩面的利弊攤開來看: 🛑...