前言
本文記錄我第一次參加 IEYI 世界青少年發明展的經過，也就是 2025 年的臺灣選拔賽。我和兩位夥伴製作一台可自行判斷擁擠程度的智能電梯，英文名稱為 Intelligent Elevator Traffic Management System，最後獲得金牌並取得代表臺灣前往大阪參加世界賽的資格。
這台作品由三人長時間共同製作。同組的張靖杭學長另有一篇初賽紀錄，整理了較完整的硬體技術細節。本文從我的角度說明題目的形成、模型縮小與影像辨識的選擇，也記錄比賽現場的調整。
專題的起點
我們選擇電梯作為題目，起點來自日常通勤中常見的擁擠情況。臺灣夏季氣溫高，乘客在狹小空間內久候會加重不適，因此我們開始思考如何讓電梯在人潮較多時更有效率地運行。
進一步討論後，我們發現重量並不等同於可用空間。現行電梯多以重量感測器判斷是否滿載，但乘客與行李可能已佔滿車廂，總重卻尚未達上限，系統仍會回應各樓層呼叫。開門後，等待的乘客無法進入，停靠也失去意義。
後來我們又聊到一個更嚴重的狀況。萬一高樓層有人出意外要緊急送醫，或是救護人員要趕上去，只要中間有人按電梯，電梯就會被攔下來。這中間被浪費掉的，很可能就是救命的黃金時間。這個念頭讓我們決定，除了讓電梯會判斷擁擠，還要多加一顆能搶回控制權的緊急按鈕。
空間辨識與緊急模式
整理需求後，我們將作品設計為兩項相互配合的功能。
第一個是電梯空間辨識模組。我們用一顆朝下的鏡頭盯著電梯地板，靠背景相減去算地板被佔掉多少。一旦判斷裡面已經很擠了，電梯就先不理外面的呼叫，只回應裡面乘客按的樓層，不再一直停下來讓月台的人失望。
第二項功能是緊急按鈕。住戶或救護人員遇到緊急狀況時啟動後，電梯會取消外部呼叫並前往指定樓層，同時啟動警報器，告知建築內使用者系統正在處理緊急情況。
我們也考量按鈕可能被誤觸。討論後決定不增加過多操作步驟，以免真正緊急時降低可用性，改以啟動後的明顯警報聲作為嚇阻與提醒。
電梯模型的製作
比賽要把作品扛到現場，所以我們得想辦法把一台電梯縮成搬得動的模型。這段是我這次做起來最有感覺的地方。
分工上，我主要顧影像辨識跟作品的外型模型，哪裡缺人就去補。學長負責電路設計跟焊接，另一位夥伴顧電梯的運行邏輯還有作品說明書。
硬體上，我們這次不再用馬達把電梯艙吊著跑，而是改成步進馬達搭配線性直線滑軌，讓電梯艙沿著軌道上下，穩很多。樓層也從五層減到三層，比較好設計。整台的大腦是一台樹莓派 4。
過程當然沒這麼順。一開始就卡在電源。樹莓派的 5V 根本推不動馬達滑軌，只好外接電源。後來我們找了一顆 PD 誘騙器，把 5V 的充電頭騙出 12V，才把電壓問題解掉。
外觀部分，我先以厚紙板製作初版，並和負責外觀的夥伴討論模型尺寸與內部空間配置，最後決定採用電腦主機造型，再以雷射切割完成結構。
影像辨識方法的調整
影像辨識是我花最多心力的部分，也是我覺得最值得講的一段。
起初我以 YOLOv5 nano 計算車廂內的人數，但實作後發現它無法衡量空間本身。行李與紙箱等非人物體同樣佔據位置，卻不會被計入，容易使系統誤判車廂仍有空間，與專題目標不符。
因此我回到以空間為核心的設計，改用 OpenCV 比對即時畫面與空車廂地板。遮蔽面積越大，代表可用空間越少。處理版本相依問題後，辨識模組才逐步穩定。
這段經驗讓我理解，技術選擇應回到問題本身。YOLO 能力完整，但不適合此處的空間判斷需求；較簡單的 OpenCV 方法反而更符合專題目標。
電梯控制邏輯的限制
電梯運行邏輯是製作期間最難處理的問題之一。這項問題持續近兩個月，到比賽前一週仍未完全解決。
後來我們去研究真實電梯是怎麼跑的，才知道一般電梯裡通常有兩到三片晶片在分工，一片管馬達，一片記錄各樓層的請求，一片跟其他電梯溝通。可是我們整台電梯只有一台樹莓派，要它一邊跑馬達一邊隨時接收樓層請求，實在很難兼顧。
我們曾考慮加入 ESP32 分擔工作，但供電與整合成本使此方案未能採用。與老師討論後，我們採取折衷方式，讓程式在運行過程中定期檢查是否有新的樓層請求，流程如下。
有人按三樓，電梯開始跑，過一秒，確認外面有沒有請求，馬達繼續跑，再確認外面有沒有請求，就這樣一直循環。
此流程在邏輯上可行，但步進馬達每移動一小段就必須暫停一秒判斷，實際運行呈現明顯停頓，而當時已接近比賽前一週。
重新閱讀簡章後，我們確認 IEYI 重視創意與設計思考，不只評估硬體是否完全運作。因此我以 Python 製作智能電梯模擬系統，呈現電梯控制邏輯與外觀。純軟體模擬不受馬達停頓影響，讓我們能在現場清楚展示設計概念，同時如實說明硬體仍待完善的部分。
臺灣選拔賽現場
比賽前一天，馬達滑軌尚未固定完成，我以熱熔膠暫時固定，卻忽略步進馬達待機時會發熱。完成基本動作測試後，熱熔膠受熱軟化，滑軌隨即鬆脫。我們檢查線路與馬達後確認沒有損壞，最後改以電火布固定結構。
到了現場，我們拿平板當電梯艙的地板，鏡頭朝下對著它，再接上我寫的模擬系統來展示。
因為是第一次比 IEYI，我們其實搞不太懂評審的問答方式。後來才知道總共有四位評審，分別看創意性，市場效益性還有操作作動性，最後一位是隨機的，每位大概兩分鐘的報告加問答。第一位評審來的時候我們還不知道他是創意評審，就照標準流程從頭講一遍，講完還剩半分鐘，結果他什麼都沒問。
從第二位開始我們就學乖了，會針對他負責的類別加重介紹的比例。遇到看市場效益的評審，我們就強調緊急按鈕平常真的用不到，可是萬一用到你會很慶幸有它。遇到看操作作動的評審，就多講電梯怎麼自動判斷擁擠。
講解的過程其實有點煎熬，因為評審幾乎都沒提問，讓我們一度很緊張，以為他們對我們的題目沒興趣。
臺灣選拔賽金牌
結果我們這台智能電梯拿到了金牌。要用一句話形容這次比賽，大概就是過程刺激，結果意外。
會說意外，是因為我們的電梯邏輯根本沒設計好，成品沒辦法真的跑，只能靠模擬系統加一台會上下移動卻沒有任何邏輯的馬達來撐場面。在一個這麼看重設計跟創客精神的比賽裡，這個狀態其實很不利。
回學校之後我們開了一次復盤，主要在想兩件事，一是我們哪裡做得好，二是評審為什麼有時間卻不太提問。指導老師點醒了我們，發明展的評審很多來自藝術或設計背景，不見得每個都懂技術。他們更想聽的是你的思考邏輯，你的設計方針，你怎麼發現問題又怎麼解決，有沒有想過每個做法的利弊。而我們在後面幾輪剛好很著重講這些，評審可能已經聽到他想聽的了，也就沒什麼好追問。
我報告的時候有偷偷觀察每位評審的表情，發現只要一講到緊急按鈕跟我們的設計思考，評審的神情就會變認真。所以後面幾位我都刻意加重緊急按鈕的比例，也許這真的幫我們多撈了一點分。
這面金牌還帶來一個很大的意外收穫。我們被邀請代表臺灣，去日本參加 IEYI 的世界賽。
寫在最後
第一次完整走完 IEYI，我最大的體會是，技術只是其中一塊，怎麼想，怎麼解釋，怎麼面對意外，一樣重要。我們的作品在技術上有很明顯的缺口，但因為我們很清楚自己為什麼做這個題目，每個設計背後在解什麼問題，反而在一個重視設計思考的比賽裡站穩了。
從辨識那段的 YOLO 掉頭回 OpenCV，到電梯邏輯卡兩個月最後只能改用模擬系統，這些不完美現在回頭看，反而是我學最多的地方。
既然要去世界賽，我們勢必要重新設計。外型我打算改成可以拆開帶出國的版本，邏輯也要好好想辦法，讓它在只有一台樹莓派的情況下真的跑順。這些我會再寫一篇大阪決賽的紀錄接著講完。謝謝一路上幫過我們的老師跟夥伴，也謝謝看到這裡的你。我們大阪見。