Version 1.1 適用場域：長照 C 據點、日間照顧中心、社區關懷據點、醫院復健中心及企業健康促進空間 —

一、專案目標

建置一套可支援 4～5 台健身車同時使用的團體互動運動系統。

系統透過健身車上的 BLE 感測器蒐集踏頻等運動數據，將多位使用者的運動表現整合成「團隊努力程度」，搭配大螢幕騎乘影片、即時資訊介面、語音鼓勵及活動紀錄，打造適合銀髮族、亞健康族群及復健使用者的團體騎乘體驗。

系統核心功能包括：

踏頻感測器（Cadence Sensor）
Bluetooth Low Energy（BLE）
多人即時數據整合
沉浸式騎乘影片
大型顯示器或投影設備
即時資訊介面（Overlay HUD）
團隊目標與個人成就
規則式及 AI 輔助語音互動
運動活動紀錄與統計分析

本系統定位為運動促進與活動管理工具，不作為疾病診斷、治療建議或緊急醫療監測設備。

二、設計原則

2.1 以團隊合作為主

銀髮及復健場域不宜只以排名或競速作為主要互動方式。

系統以以下機制為主：

團隊累積里程
團隊完成率
個人相對於自身目標的達成率
團體共同解鎖景點
每週參與成就
團隊合作任務

個人排行榜可作為選配功能，並應允許場域管理人員關閉，以避免對體能較弱的使用者造成壓力。

2.2 區分實測數據與推估數據

單純的踏頻感測器主要提供曲柄轉數與時間資訊，也就是 RPM；若要取得車輪速度，感測器必須另外提供車輪轉數資料。Bluetooth Cycling Speed and Cadence 規格本身也將曲柄轉數與車輪轉數區分為不同欄位。區分：

實測數據

踏頻 RPM
騎乘時間
踩踏／停止狀態
BLE 連線狀態
心率，例如另配心率帶
功率，例如健身車或感測器支援功率輸出

推估數據

虛擬速度
虛擬距離
估算熱量
團隊努力指數

只有踏頻感測器時，畫面及報表應標示為「虛擬速度」、「虛擬距離」及「估算熱量」，不得描述為精確的實際量測值。

若專案需要較準確的速度、距離或運動強度，應改採：

支援輪速資料的速度／踏頻感測器
支援 Bluetooth FTMS 的健身車
功率計
可由原廠設備輸出阻力、速度或功率資料的健身車

三、系統特色

3.1 沉浸式團體騎乘

大螢幕播放單車、景觀道路或旅遊路線影片，例如：

花東海岸
北海道
日本京都
瑞士
紐西蘭
阿里山
台灣環島路線
澎湖跨海大橋及海岸路線

讓參與者產生「一起騎車旅行」的情境感。

影片來源可包括：

場域或專案自行拍攝的影片
已取得公開播放及系統使用授權的影片
合法授權的圖庫或影音平台內容
概念驗證階段使用的可嵌入 YouTube 影片

YouTube 服務條款對公開放映及非個人用途設有限制，因此正式部署於長照、醫院或商業場域前，應確認影片權利及公開播放授權。正式產品不宜將任意 YouTube 影片視為唯一內容來源。 3.2 多人即時互動

每台健身車的踏頻資料傳送至中央系統，由中央系統計算團隊努力程度。

例如：

Bike 1：62 RPM／個人目標 60 RPM
Bike 2：58 RPM／個人目標 55 RPM
Bike 3：65 RPM／個人目標 65 RPM
Bike 4：45 RPM／個人目標 50 RPM
Bike 5：61 RPM／個人目標 60 RPM

                ↓

依個人目標正規化

                ↓

團隊努力指數：101%

                ↓

控制團隊進度及影片播放模式

不同使用者可設定不同目標踏頻，因此體能較弱者只要達成自己的目標，也能對團隊產生相同程度的貢獻。

這種方式比直接計算全體平均 RPM 更適合銀髮與復健場域。

3.3 遊戲化機制

系統可加入：

今日團隊目標
團隊虛擬里程
個人目標完成率
沿途景點解鎖
每週參與成就
團隊連續運動時間
語音鼓勵
選配式排行榜
團隊合作挑戰

提高參與者持續運動及社交互動的意願。

四、系統架構

┌───────────────────────────────────────────────────────┐
│ 健身車與感測設備                                      │
│                                                       │
│ Bike 1   Bike 2   Bike 3   Bike 4   Bike 5           │
│ 踏頻／速度／功率／心率感測器                          │
└───────────────────────┬───────────────────────────────┘
                        │
                 Bluetooth Low Energy
                        │
                        ▼
┌───────────────────────────────────────────────────────┐
│ Mini PC                                               │
│                                                       │
│ Ubuntu LTS                                            │
│ BlueZ                                                 │
│ BLE Manager                                           │
│ 即時數據處理服務                                      │
│ 規則引擎／互動服務                                    │
│ WebSocket Server                                      │
│ PostgreSQL                                            │
└───────────────────────┬───────────────────────────────┘
                        │
                     WebSocket
                        │
                        ▼
┌───────────────────────────────────────────────────────┐
│ Browser Dashboard                                     │
│                                                       │
│ 影片播放器                                            │
│ Overlay HUD                                           │
│ 團隊進度                                              │
│ 使用者資訊                                            │
│ 語音及動畫回饋                                        │
└───────────────────────┬───────────────────────────────┘
                        │
                        ▼
             大型電視／投影機／音響系統

五、硬體規劃

設備	建議數量	規格及說明
磁控或臥式健身車	4～5 台	優先選擇座椅穩定、上下車容易且阻力可調的機型
BLE 踏頻感測器	4～5 個	應確認支援標準 CSC Profile，並進行多台同時連線測試
心率感測器	選配	可採胸帶或臂帶，需確認使用者適用性及清潔流程
Mini PC	1 台	建議 16 GB RAM、256 GB 以上 SSD、Gigabit Ethernet、HDMI 2.0 以上
BLE Adapter	1 支＋1 支備品	優先使用經過多裝置連線驗證的接收器，不建議一開始同時使用 2～3 支
大型商用電視	1 台	建議 65～85 吋；維護及環境光適應性通常優於投影機
投影機	選配 1 台	依場地照度及畫面尺寸評估，明亮場域可考慮 4,000～5,000 ANSI 流明以上
投影布幕	選配 1 組	約 100 吋，依空間及觀看距離調整
音響系統	1 組	用於語音提示、背景音及活動引導
有線網路	1 組	播放串流影片時建議優先使用有線網路
工作人員控制平板	選配 1 台	用於開始、暫停、選擇影片及處理異常狀態

Mini PC 應具備 VP9、AV1 或 H.265 等硬體解碼能力，以降低播放高畫質影片時的 CPU 負載。

BLE 同時可維持多少連線，取決於接收器硬體及作業系統環境，不能只依「Bluetooth 5.3」版本判定。應以實際感測器、接收器及 Mini PC 進行壓力測試。、軟體架構

BLE Sensor
     ↓
BlueZ
     ↓
Bleak
     ↓
BLE Device Manager
     ↓
Data Normalization
     ↓
Rule Engine／Team Effort Engine
     ↓
WebSocket
     ↓
Browser Dashboard
     ↓
Video Player + HTML/CSS Overlay

建議技術平台：

項目	建議
作業系統	Ubuntu 26.04 LTS
後端語言	Python 3.13 或 3.14，依套件相容性鎖定版本
BLE Library	Bleak
Linux BLE Stack	BlueZ
API Framework	FastAPI
即時通訊	WebSocket
資料庫	PostgreSQL
前端	HTML5、CSS、JavaScript 或 TypeScript
UI Framework	Bootstrap 或其他無障礙友善框架
圖表	Apache ECharts
部署	Docker Compose
反向代理	Nginx 或 Caddy
語音	瀏覽器 TTS、地端 TTS 或雲端語音服務

Ubuntu 26.04 為 LTS 版本，標準安全維護至 2031 年；Python 3.14 則是目前的穩定主版本之一。正式部署仍應鎖定經專案完整測試的 Python 與套件版本，而不是自動追逐最新版。、BLE 裝置管理

BLE Manager 應負責：

感測器掃描
裝置與車位綁定
自動重新連線
斷線偵測
資料合理性檢查
感測器電量顯示
裝置狀態監控
記錄最後收到資料的時間
區分「停止踩踏」與「感測器斷線」

建議每個感測器預先與固定車位綁定，例如：

Bike 1 → Sensor A1:B2:C3
Bike 2 → Sensor D4:E5:F6
Bike 3 → Sensor G7:H8:I9

現場不應僅依感測器名稱自動配對，以避免重新開機後車位錯置。

第一階段可使用單一 BLE Adapter 連接 5 個感測器；只有在實測發生連線數限制、訊號干擾或穩定性問題時，再考慮增加第二支 Adapter，並分配不同感測器群組。

八、即時顯示介面

8.1 顯示技術

影片播放器作為背景層，運動資訊則以獨立的 HTML/CSS 元件顯示於畫面周圍。

Canvas 可用於動畫或特效，但一般文字、數字及進度資訊建議使用 HTML 元件，以提升：

文字清晰度
無障礙支援
響應式排版
維護便利性
瀏覽器相容性

┌────────────────────────────────────────────┐
│                                            │
│          沉浸式騎乘影片                    │
│                                            │
│                                            │
│ 1 號車   62 RPM     目標完成率 103%        │
│ 2 號車   58 RPM     目標完成率 105%        │
│ 3 號車   65 RPM     目標完成率 100%        │
│ 4 號車   45 RPM     目標完成率  90%        │
│ 5 號車   61 RPM     目標完成率 102%        │
│                                            │
│ 團隊努力指數：101%                         │
│ 團隊虛擬里程：8.2 km                       │
│                                            │
└────────────────────────────────────────────┘

感測數據可每秒更新 2～5 次；畫面動畫可維持 30 或 60 FPS。沒有必要宣稱所有感測資訊都以 60 FPS 更新。

8.2 YouTube 顯示限制

若使用 YouTube IFrame Player：

Overlay 不得遮住 YouTube 控制元件、廣告或平台識別
不得阻擋 YouTube 的播放及來源驗證機制
應保留必要的播放控制介面
必須處理影片被移除、禁止嵌入或無法播放的狀況
應設計備援影片或地端授權影片

YouTube 開發者政策允許部分播放控制用途的 Overlay，但前提是不與 YouTube 播放器介面衝突。、資訊顯示設計

9.1 個人資訊

公共大螢幕原則上使用暱稱、座位號或角色名稱，避免直接顯示完整姓名。

1 號車｜王阿姨

踏頻：62 RPM

目標完成率：103%

騎乘時間：15 分鐘

虛擬距離：2.8 km

若顯示熱量，應標示：

估算熱量：120 kcal

並在報表中說明計算方法及限制。

只有踏頻資料時，熱量估算誤差可能較大；若要提高可信度，應加入體重、年齡、心率、阻力或功率等資料。

9.2 團隊中央資訊

━━━━━━━━━━━━━━━━━━━━

北海道團隊騎乘

團隊努力指數

101%

團隊虛擬里程

17.6 km

下一個景點

還差 1.4 km

━━━━━━━━━━━━━━━━━━━━

9.3 個人成就

排行榜應採選配設計，也可改為個人進步榜。

本週進步成就

🏅 3 號車

比個人上週平均增加 12%

🏅 1 號車

連續參與 3 次活動

🏅 5 號車

完成本週個人目標

相較於單純依距離排名，個人進步及參與成就較適合能力差異較大的族群。

9.4 今日團隊目標

今天團隊目標

20 公里

█████████████□□□□□□□

完成率

65%

十、影片與團隊進度控制

10.1 建議控制方式

系統不應直接將 RPM 線性轉換為任意影片播放倍速，而應採用：

計算每位使用者相對於個人目標的完成率
排除明顯異常或斷線資料
計算團隊努力指數
使用分級控制及遲滯機制
限制播放速率切換頻率

例如：

團隊努力指數	團隊進度	建議影片狀態
低於 60%	暫停累積或極慢累積	正常播放或顯示鼓勵
60%～79%	0.8 倍進度	採最接近的可用播放速率
80%～109%	1.0 倍進度	正常播放
110%～129%	1.2 倍進度	採最接近的可用播放速率
130% 以上	1.4 倍進度	設定上限，避免鼓勵過度踩踏

為避免影片速度頻繁跳動，可設定：

每 5 秒計算一次團隊狀態
連續維持 10 秒後才切換級距
播放速度最高不超過場域核定值
由工作人員設定長者適用的踏頻範圍

10.2 YouTube 播放速率限制

YouTube IFrame API 的 setPlaybackRate() 只是一個建議值，播放器不保證一定切換成功，而且每部影片支援的播放速率可能不同。系統必須先呼叫 getAvailablePlaybackRates()，再從實際支援的速率中選擇最接近的值。：

0x
2x
3x
5x

並不保證全部可用。

正確流程應為：

取得團隊努力指數
        ↓
取得影片可用播放速率
        ↓
選擇最接近的支援值
        ↓
呼叫 setPlaybackRate()
        ↓
等待 onPlaybackRateChange
        ↓
確認實際播放速率

若影片不支援變速，仍可保持影片正常播放，僅改變：

團隊虛擬里程累積速度
畫面中的前進動畫
景點解鎖進度
背景粒子或道路動畫

這樣可以降低系統對 YouTube 播放速率功能的依賴。

十一、互動與語音功能

11.1 規則式教練

安全與活動控制應優先採用可解釋的規則，例如：

王阿姨已經持續騎乘 15 分鐘。

再完成 5 分鐘，

就能達成今天的個人目標。

大家目前維持在目標區間。

請保持穩定節奏。

團隊再前進 500 公尺，

就能抵達下一個景點。

11.2 AI 輔助互動

生成式 AI 可用於：

將統計資料轉換成自然語句
依活動主題產生旅遊介紹
產生多樣化鼓勵語句
協助工作人員製作活動摘要
根據個人歷史產生非醫療性的運動回顧

AI 不應直接：

診斷疾病
判斷使用者是否發生心血管事件
自動提高運動強度
取代醫師、治療師或照護人員的判斷
根據單一感測數值發出醫療結論

11.3 狀態與安全提示

只有踏頻感測器時，系統只能判斷「未收到踩踏資料」，不能直接判斷使用者身體不適。

正確提示方式例如：

4 號車超過 30 秒未偵測到踩踏資料。

可能原因：

・使用者停止踩踏
・感測器斷線
・感測器位置偏移

請工作人員確認。

若感測器斷線，應顯示：

4 號車感測器連線中斷。

正在嘗試重新連線。

不得把「感測器斷線」誤判為「使用者停止運動」。

十二、運動活動管理

每位使用者可建立「運動活動檔案」，而不是直接稱為醫療或健康履歷。

可記錄：

活動日期
騎乘時間
平均踏頻
最高踏頻
個人目標達成率
團隊參與時間
虛擬距離
估算熱量
心率資料，例如有配戴心率感測器
每週活動量
出席率
歷次活動趨勢
工作人員備註

可匯出：

PDF 活動報告
Excel 或 CSV
長照據點活動紀錄
去識別化統計資料

12.1 個資與安全

系統應具備：

使用者同意及告知機制
帳號與角色權限管理
傳輸加密
資料庫加密或敏感欄位保護
操作紀錄及稽核軌跡
備份及還原機制
資料保存期限設定
帳號停用及資料刪除流程
公開畫面姓名去識別化
報表下載權限控制

若未來要與醫院 HIS、電子病歷或臨床復健流程串接，應另行進行：

個人資料保護評估
資訊安全評估
醫療院所資安規範檢核
臨床流程及責任歸屬確認
醫療器材或軟體醫材適用性評估
數據正確性及臨床效益驗證

十三、可擴充設備

系統未來可整合：

真茂寶貝機
世大福智互動地墊
支援 FTMS 的健身設備
心率帶
血壓計
血氧機
握力計
身體組成量測設備
AI Kiosk
智慧體適能設備
復健訓練設備

不同設備資料應先經過標準化及來源標記，不應直接將不同精度、不同用途的數據混合比較。

十四、內容來源策略

14.1 概念驗證階段

YouTube 可作為概念驗證或內部展示的內容來源，優點包括：

可快速取得不同地區的騎乘影片
不需立即投入影片拍攝成本
可測試使用者對不同場景的接受度
可快速建立原型

但實際畫質會受到原始影片、網路頻寬、瀏覽器、顯示設備及 YouTube 自動調整機制影響，不能保證所有影片均以 4K 或 HDR 播放。

14.2 正式營運階段

正式營運建議建立自有或授權影片庫：

自行拍攝台灣及離島騎乘路線
向創作者取得系統使用及公開播放授權
購買商用影音素材
建立可離線播放的地端內容
保留 YouTube 作為補充來源，而非唯一來源

自有影片可進一步加入：

路線座標
景點事件
坡度資訊
語音導覽
階段任務
自訂播放速度
多語字幕
離線播放
無廣告體驗

十五、系統維護特色

本系統採 Web 架構，具備以下優點：

前端更新方便
可集中管理設備
可遠端進行版本更新
可新增影片及活動模板
可新增感測設備
可支援不同螢幕尺寸
可逐步串接雲端平台
可匯出標準化報表
不必使用 Unity 即可完成主要功能

但遠端管理應採 VPN、零信任存取或其他安全機制，不應直接將管理介面暴露於公開網路。

十六、建議導入階段

第一階段：概念驗證

功能包括：

4～5 台健身車
BLE 踏頻感測器
即時 RPM
團隊努力指數
團隊虛擬里程
大螢幕騎乘影片
基本語音鼓勵
工作人員控制介面

本階段不宣稱提供精確速度、距離、熱量或醫療監測。

第二階段：場域實證

增加：

個人帳號或識別卡
個人化踏頻目標
心率感測
活動紀錄
PDF／Excel 報表
個人進步成就
感測器斷線管理
自有或授權影片庫
場域操作及安全流程

第三階段：平台整合

增加：

FTMS 健身車
功率及阻力資料
真茂寶貝機
互動地墊
AI Kiosk
多據點管理
雲端活動分析
長照活動紀錄介接
醫療或復健系統介接
去識別化數據分析

十七、未來發展方向

本系統可逐步發展為 Silver Active Platform（銀髮互動運動平台），將健身車、互動地墊、復健設備、健康量測設備與 AI 輔助教練整合於同一平台。

平台可提供：

運動活動管理
團體互動
個人化目標
長期參與趨勢
場域活動報表
設備使用分析
多據點管理
去識別化成效分析
長照及健康促進活動紀錄

可應用於：

長照 C 據點
日間照顧中心
社區關懷據點
醫院復健中心
醫療院所
健康促進中心
企業員工健康管理
離島及偏鄉健康促進據點

十八、總結

本方案以 「多人團隊騎乘、沉浸式影片、即時互動介面及運動活動管理」為核心設計理念，兼顧娛樂性、運動參與、社交互動與系統擴充性。

第一階段可透過一般健身車、BLE 踏頻感測器、Mini PC 及 Web 技術快速完成概念驗證；後續再依場域需求增加心率、功率、FTMS 健身設備、個人化目標及多據點管理。

系統應明確區分實測與推估數據，避免將踏頻直接描述為真實速度、距離或熱量；YouTube 可用於原型測試，但正式營運應優先採用自有或取得授權的影片內容。

透過分階段導入，本系統可由單一場域的團體健身車應用，逐步發展為具備設備整合、活動管理、數據分析及 AI 輔助互動能力的銀髮健康促進平台。

多人健身車沉浸式互動系統技術方案