📝 LocalPapa Notes

開發紀錄系列第三十一篇。我們靠數據找到一頁「排名第 6、點閱率卻只有 0.53%」的工具，發現問題既不在排名也不在內容，而在一句已經不成立的文案。附一份你可以照著做的檢查清單。

The thirty-first dev-log post. Data pointed us at a tool page ranking sixth with a 0.53% click-through rate. The problem was neither the ranking nor the content — it was one sentence that had stopped being true. With a checklist you can follow.

開發紀錄系列第三十篇。雲台系列到目前為止十二篇都在講「怎麼算」，還沒有一篇講「怎麼組」。這篇補上：四個零件各自落在三層迴路的哪一層、IMU 與編碼器量的為什麼不是同一件事、同一顆編碼器如何同時服務換相與位置環、以及 BaseCam 這類現成控制器的覆蓋範圍——它跟第 28 篇的文獻缺口重疊在同一格，而且板子的驅動分層會回頭把馬達的 Kt 下限與天底禁區一起綁死。

The thirtieth dev-log post. Twelve gimbal posts so far have all been about how to compute; none has been about how to assemble. This one is: which of the three loops each part sits on, why the IMU and the encoder do not measure the same thing, how one encoder serves both commutation and the position loop, and what a BaseCam-class controller actually covers — a gap that overlaps post 28's literature gap on the same cell, with the board's driver tier reaching back to pin the motor's Kt floor and nadir keep-out.

開發紀錄系列第二十九篇。上一篇盤點文獻時發現「架構選擇」是論文最少的一格，偏偏它又是設計流程裡最先要做的決定。這篇把四個決策攤開來算：第三軸其實不解 gimbal lock；諧波減速的背隙就已經是穩定精度規格的 2.9 到 8.7 倍；天底禁區只取決於有效 Kt、跟減速比完全無關；而「把鏡面對慣性空間穩住」反而讓基座運動百分之百漏到視線上。

The twenty-ninth dev-log post. Mapping the literature in the previous post showed architecture choice to be the thinnest cell — and yet it is the first decision in the design flow. This post works the four decisions out with numbers: a third axis does not fix gimbal lock; a harmonic drive's backlash alone is 2.9 to 8.7 times the stabilization spec; the nadir keep-out depends only on effective Kt and not at all on gear ratio; and holding a mirror inertially still lets 100% of the base motion through to the line of sight.

開發紀錄系列第二十八篇。寫完前十篇雲台文章、累積約六十篇引用之後，回頭把這些文獻攤開來看：它們各自從哪個角度出發、用什麼方法、以及最關鍵的——各自把什麼當成常數。整理出來會看到一件事：同一個系統被切成八塊，每一塊的邊界都剛好停在別人的問題上，而中間有三個接縫沒有人負責。

The twenty-eighth dev-log post. After ten gimbal posts and about sixty citations, this one steps back and maps the literature: where each cluster starts from, what method it uses, and — most revealing — what each one holds constant. The picture that emerges is of one system cut into eight pieces, each stopping exactly where someone else's problem begins, with three seams in between that nobody owns.

開發紀錄系列第二十七篇，也是雲台系列的收尾。前面九篇的公式都對，但每一個代進去的數字都是估的。這篇補上最後一塊：轉動慣量、黏滯摩擦、庫倫摩擦、Kt、殘留重心偏移、線束彈性、結構共振，各該用什麼實驗量回來。核心是一個很漂亮的性質——正弦速度激勵下，摩擦力矩與速度同相、慣性力矩差 90°，所以一次掃描就能把兩者分開。

The twenty-seventh dev-log post, and the last of the gimbal series. The formulas in the previous nine are right, but every number fed into them was an estimate. This post fills the final gap: which experiment recovers inertia, viscous friction, Coulomb friction, Kt, residual CG offset, cable stiffness and structural resonance. At its heart is one elegant property — under sinusoidal velocity the friction torque is in phase with velocity while the inertia torque is 90° out, so a single sweep separates them.

開發紀錄系列第二十六篇。前面八篇把雲台從力矩算到迴路，但一直停在「把視線穩住」。這篇往外再走一步：從一個像素走到一組經緯度要經過幾個座標系、每一跳注入什麼誤差、以及為什麼掠射角一低定位就垮。算完會發現一個反直覺的結論——在幾乎整個實用範圍內，主導誤差是地形而不是指向，把雲台精度再翻一倍幾乎沒用。

The twenty-sixth dev-log post. Eight posts took the gimbal from torque to control loops, but all of them stop at holding the line of sight steady. This one goes one step further out: how many frames sit between a pixel and a latitude, what error each hop injects, and why a low grazing angle wrecks geolocation. The arithmetic lands on a counter-intuitive conclusion — across almost the whole usable range the dominant term is terrain, not pointing, and doubling the gimbal's accuracy barely helps.

開發紀錄系列第二十五篇。前面七篇把「要多大的馬達」算得很細，卻一直沒回答「馬達裝上去之後控制怎麼做」。這篇補上那個斷點：電流環、速率環、位置環三層各自負責什麼、頻寬為什麼必須差五倍、調參為什麼一定要由內而外。最後回答一個從機械手臂帶過來的問題——雲台需要運動學嗎？需要，但只需要一小塊，而那一塊就是前一篇已經在算的 yaw gain。

The twenty-fifth dev-log post. Seven posts have worked out how big the motor needs to be, without ever answering what happens once it's bolted on. This one fills that gap: what the current, rate, and position loops each do, why their bandwidths must differ by five times, and why tuning has to go inside out. It closes with a question carried over from robot arms — does a gimbal need kinematics? It does, but only a small slice, and that slice is the yaw gain from the previous post.

開發紀錄系列第二十四篇。雙軸不是三軸砍掉一軸——方位軸的慣量、角速率需求、重力力矩全都隨俯仰角變化，而兩軸的最壞情況落在行程的相反端。這篇以 Ekstrand 2001 的雙軸運動方程為基礎，走完兩條獨立的力矩→電流鏈，並推出一個很少被先講清楚的結論：你選的 Kt 直接決定了正下方那個追不動的禁區有多大。

The twenty-fourth dev-log post. Two axes is not three axes minus one — the azimuth axis's inertia, rate demand, and gravity torque all vary with elevation, and the two axes hit their worst cases at opposite ends of the travel. Building on Ekstrand's 2001 two-axis equations of motion, this post works through two independent torque-to-current chains and arrives at a result rarely stated up front: the Kt you pick directly sets how big the straight-down keep-out cone will be.

開發紀錄系列第二十三篇。第二十一篇的入門手冊給了一個完整範例，但用的是計算機預設值——那組數字描述的是「裸露在氣流中的酬載」。大多數人手上的其實是球型吊艙，力臂小一個數量級。這篇換一台中型三光球型吊艙（150mm／1.8kg 級）重算三軸，並在過程中發現手冊那張拆解表裡的「摩擦 13.0%」其實是模型的恆等式，跟設計無關。

The twenty-third dev-log post. The handbook in post twenty-one worked a complete example, but used the calculator's defaults — and those numbers describe a payload hanging exposed in the airstream. What most people actually have is a ball gimbal, where the moment arm is an order of magnitude smaller. This post reruns all three axes for a mid-size tri-sensor ball gimbal (150mm / 1.8kg class), and finds along the way that the '13.0% friction' in the handbook's breakdown table is an identity of the model, not a property of that design.

開發紀錄系列第二十二篇。上一篇的入門手冊給了一條從風阻到電流的完整力矩公式鏈，但那條鏈上的每一項，背後其實都是一個獨立的研究領域。這篇把力矩分析的文獻分成六類整理——剛體動力學與軸間耦合、LuGre 摩擦、走線阻力的 Kirchhoff 桿模型、砲塔氣動的風洞與 CFD、馬達端的力矩漣波，以及 NASA 與 ECSS 標準怎麼算裕度——每一類都標出它對應手冊的哪一項、在什麼條件下簡化版會失效。

The twenty-second dev-log post. The previous handbook laid out one complete formula chain from wind drag to motor current — but every term on that chain is its own research field. This post sorts the torque-analysis literature into six clusters: rigid-body dynamics and cross-axis coupling, LuGre friction, Kirchhoff-rod models of cable harness drag, wind-tunnel and CFD work on turret aerodynamics, motor-side torque ripple, and how the NASA and ECSS standards actually compute margin. Each cluster is mapped back to the handbook term it refines, and to the conditions under which the simplified version stops holding.

開發紀錄系列第二十一篇。前三篇雲台文章各自處理了量測、控制優化、機構設計，但都預設讀者已經懂 ISP（慣性穩定平台）的基本語彙。這篇回到最前面，以 Hilkert 2008 的方法論為主幹，從「什麼是視線」開始，一路推到單軸力矩預算的完整範例計算，再擴展到多軸的巢狀慣量與軸間耦合，最後說明這套方法論的邊界在哪裡。

The twenty-first dev-log post. The previous three gimbal posts covered measurement, control tuning, and mechanical design — all assuming the reader already speaks ISP (inertially stabilized platform). This one goes back to the start: beginning from "what is a line of sight," building up to a fully worked single-axis torque budget, extending to nested inertia and cross-axis coupling in three axes, and finally marking out where this methodology stops being valid.

開發紀錄系列第二十篇。前兩篇分別講了怎麼量 LOS 抖動、量到之後控制端怎麼優化，兩篇都預設「雲台已經存在」。這篇回頭補上前面缺的那塊——馬達怎麼選（直驅 vs 齒輪）、配平機構怎麼設計、動力學怎麼建模、感測器與集電環怎麼配置、被動隔振跟主動控制怎麼分工，並找出兩篇奠基性但先前沒引用過的 IEEE 論文。

The twentieth dev-log post. The previous two covered measuring LOS jitter and optimizing the control loop afterward — both assumed the gimbal already exists. This one goes back and fills the gap: how the motor gets chosen (direct-drive vs geared), how the balancing mechanism is designed, how the dynamics get modeled, how sensors and slip rings get laid out, and how passive isolation divides labor with active control — plus two foundational IEEE papers this series hadn't cited yet.

開發紀錄系列第十九篇。上一篇整理了怎麼量測 LOS 抖動；這一篇往前一步，回顧雲台 LOS 優化的控制與機構文獻——主動抗擾控制、滑模控制、摩擦補償的量化效果、結構最佳化案例，以及強化學習這條還在驗證中的新方向，並標出每一條線在馬達選型計算機裡的落點。

The nineteenth dev-log post. The last post covered how to measure LOS jitter; this one goes a step further and reviews the control and mechanical literature on LOS optimization — active disturbance rejection, sliding mode control, quantified friction compensation results, structural optimization case studies, and the still-unproven reinforcement-learning frontier — with notes on where each line of work lands in the motor sizing calculator.

開發紀錄系列第十八篇。雲台馬達選型計算機用「LOS 穩定度目標」反推馬達扭力與電流，但那個目標本身要怎麼實際量出來？整理三種主流光學量測架構（自準直儀、雷射＋位置感測探測器、目標板＋攝影機）與對應文獻，並給出一套適合中小型雲台的最小可行量測方案。

The eighteenth dev-log post. Our gimbal motor sizing calculator works backward from a LOS stability target — but how do you actually measure that target in the real world? A survey of three optical measurement architectures with supporting literature, plus a minimal practical rig for small-to-mid gimbals.

開發紀錄系列最新篇。定期定額（DCA）是台灣最常見的投資方式，但多數試算工具把你的數字送上伺服器。我們把它變成一個完全本地、支援多情境比較的複利試算器。

The latest post in our dev-log series. Dollar-cost averaging (DCA) is the most common investment approach in Taiwan — but most calculators send your numbers to a server. We turned it into a fully local, multi-scenario compound-growth simulator.

開發紀錄系列第十六篇。樂透開獎是獨立隨機事件，無法預測。那「樂透預測工具」裡的「預測」是什麼？時間種子 LCG、每 30 分鐘一組確定性號碼、滾球動畫——以及為什麼在搜尋引擎面前「預測」是一個有意義的標籤，但對使用者則必須立刻誠實澄清。

The sixteenth dev-log. Lottery draws are independent random events — they can't be predicted. So what does "prediction" mean in a lottery predictor tool? Time-seeded LCG, deterministic numbers per 30-minute block, rolling ball animations — and why "prediction" is a meaningful SEO label but requires immediate honest clarification to the user.

開發紀錄系列第十五篇。排盤完了，然後呢？我們評估了三條解讀路徑（本地查表、我方呼叫 AI、本地＋用戶自己的 AI）、設計了「星曜本質×宮位領域」組合式查表以避免硬刻 168 組，並把三方四正做成服務間可複用的深度解讀模式。

The fifteenth dev-log. Placing stars is one thing; reading the chart is another. We evaluated three interpretation paths (local lookup, server-side AI, local + user's own AI), designed "star essence × palace domain" combinatorial lookup to avoid 168 hardcoded entries, and turned Three Directions/Four Alignments into a cross-service reusable deep-reading pattern.

開發紀錄系列第十四篇。達摩一掌經的開發決策從第一行就定調：完整複製紫微斗數的三層架構，而不是從頭寫。DRY 重用農曆表、mod12 排盤、六道根性、流派設定、流年——一個從 MVP 快速深化的命理服務。

The fourteenth dev-log. The architectural decision for Da Mo Yi Zhang Jing was settled before the first line: copy Zi Wei Dou Shu's three-layer architecture wholesale, not start from scratch. DRY lunar reuse, mod12 chart layout, six-path root nature, school settings, annual fortune — one divination service that deepened quickly from MVP.

開發紀錄系列第十三篇。紫微斗數是入門最高的華人命理術——農曆換算、五虎遁年起命宮、納音定五行局、古法起紫微……全在瀏覽器本地跑，不上傳任何生辰資料。我們如何用交叉驗證確保排盤準確，並把命理知識沉澱進 OKF。

The thirteenth dev-log. Zi Wei Dou Shu is one of the most complex Chinese metaphysical systems. We built a fully local chart engine — solar-to-lunar conversion, Ming Gong stem calculation, Five-Element Bureau from nayin, and the ancient Purple Star placement algorithm — all running in the browser, uploading nothing.

開發紀錄系列第十二篇。AI agent 不該為了讀懂你的網站去解析滿是廣告與版型的 HTML。我們如何用一支生成器，把整站工具自動變成乾淨、互連的 OKF 知識包與 llms.txt。

The twelfth dev-log post. An AI agent shouldn't have to parse ad- and layout-cluttered HTML to understand your site. How one generator turns the whole tool catalog into a clean, interconnected OKF knowledge pack and llms.txt.

開發紀錄系列第十一篇。相機是繼動作感測器、麥克風之後第三個瀏覽器能直接讀的硬體。我們如何用它做 QR 掃描與數位放大鏡，並讓畫面一格都不離開你的裝置。

The eleventh dev-log post. The camera is the third hardware the browser reads directly, after motion sensors and the microphone. How we built a QR scanner and a digital magnifier with it — and kept every frame on your device.

開發紀錄系列第十篇。同一個麥克風 + Web Audio API，能做出調音、測噪音、打拍子、即時變聲。背後是自相關音高偵測、音訊硬體時鐘排程與即時變調演算法。

The tenth dev-log post. One microphone plus the Web Audio API yields tuning, noise metering, click tracks and live voice changing — powered by autocorrelation pitch detection, audio-clock scheduling and a real-time pitch-shift algorithm.

開發紀錄系列第九篇。第二次造訪如何瞬開、甚至離線可用？我們如何用「自托管 + Service Worker 分層快取」降低 CDN 依賴，又不把 30MB 的 wasm 塞進 repo。

The ninth dev-log post. How does the second visit open instantly, even offline? How we used "self-hosting + a layered Service Worker cache" to cut CDN dependence — without stuffing a 30MB wasm into the repo.

開發紀錄系列第八篇。LLM 常輸出 Mermaid 純文字，卻看不到圖。我們如何在瀏覽器裡即時渲染、防競態、保真匯出，還能把整張圖壓進一條分享連結。

The eighth dev-log post. LLMs spit out Mermaid text you can't actually see. Here's how we render it live in the browser, fight race conditions, export faithfully, and squeeze a whole diagram into a single share link.

開發紀錄系列第七篇。從「在手機上看感測器」到「把數據即時串流到電腦」——WebSocket、HTTP POST、Web Serial（USB），還有那個惱人的 Mixed Content 難題怎麼解。

The seventh dev-log post. From "viewing sensors on the phone" to "streaming the data live to a computer" — WebSocket, HTTP POST, Web Serial (USB), and how we tackled the maddening Mixed Content problem.

開發紀錄系列第六篇。水平儀、指南針、G 力計、震動偵測——我們如何只用瀏覽器原生 API，把手機的加速度計與陀螺儀變成一個即時儀表板，而且資料完全不離開裝置。

The sixth dev-log post. Level, compass, G-meter, shake detection — how we turned a phone's accelerometer and gyroscope into a live dashboard using only native browser APIs, with data that never leaves the device.

開發紀錄系列第五篇。免費工具也有伺服器、網域與資料庫的帳單。我們如何在不背叛「檔案不上傳」承諾的前提下，加入廣告並把合規做對。

The fifth dev-log post. Free tools still rack up bills for domains, hosting and databases. Here's how we added ads — and got the compliance right — without betraying the "files never leave your device" promise.

開發紀錄系列第四篇。LocalPapa 曾是一個漂亮的單頁應用，卻幾乎搜不到。我們如何把它重構成多頁網站，讓每個工具都有自己的落地頁與自然流量。

The fourth dev-log post. LocalPapa was once a slick single-page app that almost nobody could find. Here's how we rebuilt it into a multi-page site so every tool gets its own landing page and organic traffic.

開發紀錄系列第三篇。旋轉、PDF 轉圖片、解鎖、圖片轉 PDF——我們如何只用 pdf-lib、pdf.js 與 JSZip，在不上傳檔案的前提下把進階 PDF 操作搬進瀏覽器。

The third dev-log post. Rotate, PDF-to-image, unlock, image-to-PDF — how we brought advanced PDF operations into the browser with just pdf-lib, pdf.js and JSZip, without ever uploading a file.

開發紀錄系列第二篇。安防工程師規劃攝影機時要反覆手算 DORI 有效距離——我們把它變成一個即時、本地運算的視覺化工具。

The second post in our dev-log series. Security engineers hand-calculate DORI distances over and over — so we turned it into an instant, browser-local visual tool.

LocalPapa 的第一個工具開發紀錄。我們如何只用瀏覽器、不上傳任何檔案，從 PDF 的文字座標還原出有結構的 Markdown。

The very first tool in our dev log. How we reconstruct structured Markdown from a PDF's text coordinates — entirely in the browser, with zero uploads.