文章總列表

解析Garmin FIT file，計算累計里程和累計高度

緣起

以東三塔規劃表為例，大會有檢錄點，我們有休息點，把他們全部塞入試算表。要估算時間，得猜平均速度，我的方法簡述如下

  • 距離：絕對里程相減，簡單
  • 爬升量：累積爬升量相減，麻煩
  • 坡度：爬升量/ 距離
  • 平均速度：平地速度 - 坡度*K，騎一趟觀霧可以估算

這篇要解決累計爬升量，我想要有一份軌跡檔（FIT），計算出每公里的資訊


預期的產出

假如弄得到軌跡檔（比如我自己的FIT檔），我就能算出下表，這樣規劃路線就是查表而已

  • 累積里程
  • 海拔高度
  • 累計爬升
  • 經緯度

上表做圖，看得出蘇花公路120~200，爬升1000，可以用來分配體力，安排休息點


解析FIT檔案

Garmin FIT檔可以用fitfileviewer閱讀，“record”是單車碼表運作的依據，每一秒的經緯度，心律，功率，踏頻，高度，左右腳平衡，blah blah。這裡只需要

  • 時間
  • 經緯度
  • 高度

不同廠商的碼表，紀錄邏輯也不同，寫軟體處理相容性問題，也是非常有趣

  • Garmin/ Wahoo：每秒紀錄
  • Bryton/ iGPSport：有變化才紀錄

假如上面的資訊完全沒誤差，計算每秒之間的移動距離，和爬升量，得到

  • delta_distance[n]
  • delta_altitude[n]

累加上述參數，就有每秒鐘的絕對里程，累積爬升量。最後再查表，問題就解完了

  • 累計距離=1km，經緯度，累計高度，海拔高度
  • 累計距離=2km，經緯度，累計高度，海拔高度


處理誤差

真實世界感應器都有誤差，GPSVisualizer提供兩個完美教學，解釋如何修正誤差

核心概念很簡單，水平和垂直處理的手法，基本上是一樣的

  1. 假設第0點是有效參考點pt[0]
  2. 計算distance(pt[1], pt[0])，小於5公尺，pt[1]當成雜訊丟掉
  3. 計算distance(pt[2], pt[0])，超過5公尺，pt[2]有效並當成新的參考點
  4. 計算distance(pt[3], pt[2])，...


得到里程表

所以FIT檔照以下順序處理，就有里程表

  1. 水平過濾
  2. 垂直過濾
  3. 剩下的點，計算累積距離，累計爬升，得到表格
    {時間，里程，高度，累計爬升，經緯度}
  4. 最後這張表格，用0.5公里當精準度取值，輸出結果


結語

處理GARMIN FIT file不是很難，這一篇研究單車碼表內，怎麼處理距離和高度。我也解決最初的問題：取得每公里的高度和爬升量

最初沒有考慮雜訊，算出來的速度和高度誤差不少；詢問AI介紹GPSVisualizer的算法，照著實作效果滿好的；這篇就沒太多source code，意義不大；如果您真的動手解這題想看我怎麼寫再聯絡我吧

最後這些運算結果，我架了一個簡單的網站，如果有需要，可以自取來用。下一篇來寫一下，架網站的心得


留言

張貼留言

這個網誌中的熱門文章

STM32 UART + DMA，使用HAL實作TX/RX，以及不定長度接收

圖片
前言 我一般用Segger-RTT來debug。不過這東西也有限制，比如MCU進出sleep mode，他的data stream就會斷掉，也是不方便 http://lihgong.blogspot.com/2016/05/segger-rtt-1.html http://lihgong.blogspot.com/2016/05/segger-rtt-2.html http://lihgong.blogspot.com/2016/05/segger-rtt-3_6.html 我不是很喜歡UART，根本原因是把他 用好 其實不容易。當年選用Segger RTT其實就是要逃避這題（笑）；很多年過去了，總是要回來解決這題 STM32 HAL UART driver足足有3726Lines，這代表他的複雜度。假如UART跑在115200bps來說，傳送1byte需要約100us，假設CPU跑在16Mhz就需要1600T。簡單用Polling mode丟資料（或是接收資料）效能很悲劇；用了中斷模式會好一點，但是每個字元都來中斷，遇到高速UART其實效率也不大好；這題的根本解法是需要DMA mode 這篇我會介紹怎在使用STM32CubeIDE，把UART+DMA mode跑起來，TX/RX都有，實作我心裡最佳的框架。這篇直接講結論和步驟，原理很複雜，但是架起來卻很簡單 環境 STM32CubeIDE 你改用STM32CubeIDE了嗎？如果還沒，可以試試看；我用起來很滿意！ Nucleo F411RE Board 上面有ST-LINK加開發版，帶條USB線就能出去玩；缺點是MINI-USB線有點討厭 MobaXTerm 好用的Terminal工具，可以連SSH/ RDP/ Serial Terminal UART-TX設定步驟 STM32CUBEIDE設定UART，關鍵是要打開UART中斷，以及打開TX/RX的DMA Enable UART IRQ Enable UART DMA channels 假如要傳送資料，這一段code能幫上忙。這裡面有個資料結構內藏ring-buf，每次user要寫東西就往buf[]擺，並且更新wptr；資料擺上去會呼叫UART HAL library的API來傳送；或是DMA傳送完了，也會檢查還有沒有剩下的要傳。因為有Global variabl...
Read more »

小米掃地機器人S20+ review

圖片
貓吉與新的掃地機器人 初代小米掃地機器人 我的初代機是 2017四月上市 購買，報價8895元。八年來出動4269次，執勤2130小時，非常耐用 換過不少耗材，模組化設計，幾乎什麼都買得到 常見耗材：主刷，濾網，邊刷 不常見耗材：行走輪，雷射感應頭，主刷馬達，電池*3 經過八年以後，機器開始會不大可靠，也別再逼他了 不容易啟動，似乎馬達需要啟動幾次才開始動 充電失敗，有時候抱怨充電異常，有時候是充電座沒電 小米掃拖機器人S20+ 前一台表現良好，我決定再買一台；我偏好簡單的機器（比較不會壞）。官網有兩台，我分不出明顯的差異，所以買貴的，價格都比8895便宜 S20 ：4495 S20+ ：6795 使用體驗，都過八年了，變厲害也不過分 基於全室地圖運作 初次使用建立地圖後，可以針對某個區塊掃地或拖地 舊機器每次都是獨立事件，沒有房間的概念 機器比較安靜 睡前按下去掃，噪音不影響睡覺，睡醒就掃好了 拖地功能 平常不用。額外多買了抹布，每個房間拖完換下一條抹布，用抹布海解決問題 除塵盒改善 多了初級濾網，沒讓高階濾網直接碰灰塵；比較好清洗 速度 似乎掃得比較快 電力 似乎有改善耗電量，能用較低的功耗，達成一樣的效果 辨識功能加強 能辨認地毯，並且經過時增強吸力 希望這台機器能像小米初代機一樣耐操。舊的機器還是能當救援投手，每天掃貓砂
Read more »

玩CAN bus的傢伙們 (1) CandleLight-based USB-CAN

圖片
硬體介紹 要玩CAN bus，準備一條USB-CAN的線，搭配一台筆電就能樂無窮，我們就從這條線講起。這條線的檔次變化很大，這篇先從[最便宜]的版本說起 這上面其實就是兩樣東西 MCU:  STM32F042x6 or STM32F072RB CAN Transceiver:  NXP TJA1051/3 簡單看一下MCU的block diagram，關鍵是圖上紅框的CAN和USB介面，完成介面的轉換。我愛用的STM32 F103 C8T6也有這兩個介面，但是USB/CAN不能同時開；倒是比較低階的F0就沒這個限制 這東西的結構簡單，其實網路上很多來源都買得到這個硬體 https://github.com/HubertD/candleLight https://wiki.linklayer.com/index.php/CANtact https://canable.io/ TAOBAO 想要自己做可以參考這個 線路圖 ，很簡單 韌體介紹 最早Geschwister Schneider Technologie生產USB-CAN裝置（以下簡稱gs_usb），他的 Linux kernel driver 已經合入公版，各大Linux版本可以直接使用。驅動程式揭漏gs_usb通訊協定，於是有高手仿照通訊協定寫了 CandleLight FW ，燒入MCU後，電腦就認為這是gs_usb！ 分析一下FW的效能，這些介面轉換的東西，不掉封包是基本的需求。STM32F0的記憶體不大，只有16K，他的source code宣告QUEUE深度是64層 假設我們的封包都是8byte放到滿（沒放到滿時case，狀況更差了），不同CAN bus速度能承受的時間如下 1000Kbps, 1us per bit, ~100bit per packet = 100us, 64x = 6.4ms 500Kbps, 2us per bit, ~100bit per packet = 200us, 64x = 12.8ms 125Kbps, 8us per bit, ~100bit per packet = 800us, 64x = 25.6ms USB是主機主機端定期詢問裝置是否有封包要傳送，如果電腦USB很忙，比如正在傳輸檔案，能分到的頻寬就變少；或是CAN bus很滿，buff...
Read more »