hardware | 林德旸

硬件 C 端 Pest Control 创业（2024～现在）

Mon, 01 Apr 2024 00:00:00 +0000

从工作室之后寻找新方向

XbotPark Camp 与陪伴机器人探索

其实在意识到工作室没有办法做的很大的时候，我就一直在想究竟要去做什么方向，在2024年4月份的时候，入选了李泽湘老师的XbotPark的Camp，认识很多朋友，最开始在探索的方向是陪伴机器人，思考如何把机器人造出类似猫猫带来的感觉？

遇到 Enzo，切入 Pest Control

不过也是探索了两个月，做了大量的用户访谈，始终也是没有能找到一个很好软硬件的切入点，如果只是做一个AI对话机器人那真的太没意思了，为什么猫猫能给人带来很舒服感觉，这种舒服的感觉究竟是什么要如何有软硬件实现，一直没找到；不过很巧的就是刚刚好的是，有个朋友Enzo是一直在找懂技术的人，而我则是一直在找要做什么，然后我们就通过一个投资人朋友认识了，并且发现PestCtrl是个很好的方向，从而开始这个tour；

为什么选择 Pest Control

市场筛选逻辑

我在上一个工作室的创业经历中，我感觉最大的教训就是

1）要选择好一个好的市场，这个市场要够大，天花板够高，并且是最好和吃饭一样，长期极强的需求，这个才是一个好方向；

2）同时这个方向也要尽可能避开和追觅、小米、美的这种白色家电的巨头竞争，同时也要避开专门做出海的深圳厂家之间的竞争，类似安克、傲基；

3）另外是一定要做出海，国内C端硬件利润非常非常低；

4）这个领域要足够的传统，暂时缺乏现代技术；

5）要去最好做软硬件结合，去提高用户的粘性，并且通过软件订阅而非硬件去实现盈利；

而PestCtrl其实就是符合对应的筛选；

我们要解决的问题

而我们在做的PestCtrl究竟是在解决什么问题，这个因为还没上线，没办法给出太多，但是核心就是：

1）智能化IOT；

2）人道化无痛的击杀；

3）方便后处理；

4）正确摆放；

从真实场景做用户研究

杭州小屋子里的 0 到 1

我们早期并没有选择去融资+scale，两个人纯自己来，先从这个PestCtrl的提出，而且探索我们究竟要去做一个什么样的形态，它并不是一个很明确的问题，而更多是类似去找是不是有个更好的解决方案，早期蛮像科研的

然后我们两个人就在杭州从0从一个小屋子去开始去做

（杭州最开始的办公室)

跟着消杀师傅进后厨和用户家

同时我们找到一个朋友的消杀公司，然后陪着师傅天天去抓各种老鼠，后厨+普通的用户家里，我们当时也并不明确究竟要做C端还是先做B端，所以也是一直在探索

（和消杀公司师傅去一起抓老鼠）

（学习市面上的消杀工具问题究竟是什么）

（现在最有效的消杀就是拉高压电网，然后我们需要通宵的守着）

学习工具痛点与采集数据

（在最开始的时候设计了一套设备去采集老鼠的视频、声音、震动、红外热释数据）

早期原型：检测、结构与击杀方式

第一个 insight：人道化高效击杀

我们确定的第一个insight就是，如何更好的人道化的去击杀老鼠，为此我们提出的idea就是高压电+合理的结构设计，然后开始各种测试，软件+硬件一起开始设计和测试

（第一版的测试电路）

我们最开始还在用小白鼠做测试

（小白鼠去测试各种各样的形态）

从小白鼠到野生老鼠测试环境

不过后面我们发现小白鼠的活性+能力离真正的野生老鼠差太多了，就也去造了个专门养野生老鼠测试的屋子

（早期测试老鼠设备的笼子）

几十种形态与第一版验证

在里面去测试各种形态，测试各种各样的检测方法+击杀结构，设计了各种各样的电路，最终我们花了大概2～3个月左右完成了第一版的形态，并开始测试

（各种各样的形态电路的测试）

搭建老鼠屋做长期测试

我们花了差不多几个月时间，设计了几十种各种各样的形态，从最开始的买小白鼠测试，到后面我们自己租了个场地，在里面搭建一个15方平米的老鼠屋，里面放进去从菜市场抓到的各种野生老鼠，然后测试我们设计的设备是否真的有用，可能这其中最痛苦的事情就是有点吓人（野生的老鼠真的很凶）+没办法很快速的去知道是否真的有用，和没办法知道老鼠的真实想法是什么。

（构建设备老鼠测试屋子）

（B端的长条击杀测试）

B 端测试与关键市场教训

长条设备的消杀验证

我们这个长长的条，有了非常好的击杀效果，击杀速度极快，并且其实对老鼠就是瞬间致命，并且实现了更加安全的人体检测+对应的通知去解决消杀师傅需要通宵的问题，我们在差不多第5个月的时候，做了十五条左右去给到消杀师傅去做测试，有很好的击杀效果

好设备不等于市场买单

不过后厨挺复杂，有类似积水，高油污的问题，有超级多的corner case要解决，另外是这个是新产品，需要去教育市场，如果是在国内销售，B端其实非常重视公司的销售能力，这个其实对年轻人并不是很友好，另外是我们后面发现国内的消杀公司有个很尴尬的问题，就是如果你的设备真的很好可以帮助消灭很多老鼠，但是对消杀公司来说，一个是需要付一笔高的费用去买设备，另外是这个老鼠很快消灭了，其实他们的甲方也会要求他们减少对应的上门次数，这个好的设备反而会影响他们的收入，我们后面感觉也是挺神奇的，不过市场就是这样子，最重要的insight还是要在做之前就足够的深刻了解用户他们究竟是如何思考问题的，而不是设备越好市场就买单，用户需求永远永远是最重要的；

转向 C 端产品化

把 B 端能力下放到 C 端捕鼠器

而意识到这个问题后我们也其实考虑了一段时间，最终方案就是我们其实可以把里面用到的很多技术去下放到C端的捕鼠设备上，因为C端用户是自己购买，自己消杀，他们最需要就是能有好的消杀效果，我们B端已经验证了一个很好的击杀形态，所以我们可以从很方便去从长条的B端去改为C端的更小的样子，所以我们就马上开始做了很多个版本去测试：

样机、ID、模具、PCB 与团队扩充

我们基本在25年7月份左右完成最终版本的样机设计，然后就开始回到深圳开始找工业设计公司、去和一个一个模具工厂聊、去找对应量产经验负责PCB的公司，这个时候，我们开始考虑融资开始接触一些机构，也从最开始的两个人逐渐的扩充到五个人，一部分是去推动量产

IoT 软件架构与 App 准备

另外是开始我们需要设计IOT软件架构+对应的APP。最终的形态其实会和早期上述的这些在功能和设计上都有了很大的区别，因为还没上线，这部分等后面上线再详细聊聊比较合适。

Pest Control 产品线继续探索

覆盖更多老鼠需求与蚊子方向

然后我们也就在推动C端捕鼠器量产的同时，继续做各种PestCtrl的探索，覆盖更多老鼠的需求+开始做蚊子，下面还是放了一些我们早期探索的样机设计，后面有部分也开始做推动到下一个阶段；

多相机 4D 采集系统（2026～现在）

Fri, 07 Aug 2026 00:00:00 +0000

多相机 4D 采集系统

自己设计、自己造、自己写软件的一套动态 4D 采集设备：8 组双目相机（16 路）由 ESP32 门控触发做到亚微秒同步，整机碳纤维、单人免工具拆装、充电宝供电，采集与标定全在浏览器里完成。采下来的数据直接进 4D 高斯重建管线，结果做成打开网页就能实时播放的 4DGS。


相机	8 组双目 / 16 路 · 1920×1200
跨相机同步抖动	~0.4 µs（跨两台主机一致）
标定	8/8 合格 · stereo RMS ≈ 0.6px · 基线 59.35–59.83mm
便携性	单人免工具拆装 · 充电宝供电 · 阵列可跟随被摄者移动
数据集	静态阵列 23 场景 + 移动阵列 2 场景（含 IMU）· 83.4 GB
浏览器播放	400 万高斯 / 267 MB · M5 Mac 约 20 fps

采集：16 路、0.4 µs 同步

相机被配置成纯触发从机——没有脉冲就不出帧，由单个 ESP32 门控触发器并联驱动全部 8 台的触发线。软件下一条指令，ESP32 用硬件定时器精确发脉冲，8 台在同一瞬间曝光，实测跨相机抖动 ~0.4 µs，跨两台主机也是同一量级。这套逻辑后来做成了独立四路同步器，两台级联覆盖 8 组模组。

每组模组自带并排双目，模组内立体基线 ≈ 59.5mm——这条物理基线直接给整套重建提供尺度。

碳纤维四面体采集架 · 8 组双目环绕中央被摄区

8 组双目模组 · 3D 打印外壳 + 网口

四路同步器：ESP32 门控触发做成独立硬件

8 路同步立体视频合成宫格回看，每一格是一台相机的同一时刻画面，同名帧 = 同一触发瞬间：

当前浏览器不支持直接播放该视频。

便携：能装进后备箱，还能跟着人走

立柱、横梁、相机模组、同步器、供电全部独立，免工具、单人拆装；相机模组与横梁之间用快拆座 + 定位销，靠定位销保证重复安装的一致性，标定才能跨场次复用。供电换成充电宝方案，整套系统不再需要往外拉电线。末端相机的晃动用斜拉碳纤维管解决，斜拉件同样支持快拆。

充电宝供电 + 全可拆卸：架子摆到哪里都能开机

加装斜拉碳纤维管后的整架 · 末端刚性显著提升，仍保持快拆

这直接解锁了一种新的采集方式：整个相机阵列跟着被摄者一起移动。看宫格里的背景，同一段视频里从开阔区域一路换到工作台旁——人在走，架子也在走。

当前浏览器不支持直接播放该视频。

软件：采集、标定、导出都在浏览器里

不装客户端，手机 / 平板 / 电脑打开局域网地址就能用。设备墙汇总两台主机上的 8 台相机 + 实时预览，一键跑完「全开流 → 就绪 → ESP32 触发 → 录 → 停 → 跨主机汇总 → 对齐报告」，两台 NUC 之间 2.35 Gbps 直连汇总数据。曝光参数一键广播到 16 路并逐路回读校验。

MultiCam Studio 设备墙：8 相机 / 2 主机 + 采集控制

标定同样在网页里完成：屏幕按真实物理尺寸显示 12×7 · 44mm · DICT_5X5_1000 标定板，手持相机逐姿态 ~1Hz 自动采集，一键产出内参。8 台全部合格，基线聚集在 59.35–59.83mm，总跨度仅 0.5mm：

相机	Cat	Cow	Dog	Fish	Mouse	Pig	Sheep	Tiger
stereo RMS (px)	0.6154	0.5927	0.6119	0.5985	0.5993	0.6163	0.5941	0.6857
基线 (mm)	59.832	59.366	59.351	59.467	59.573	59.595	59.666	59.627

浏览器内屏幕 ChArUco 双目标定

拍摄记录带缩略图与同步质量，导出时自动避开丢帧造成的时间断点，保证导出片段的时间轴严格均匀（相邻帧恒为一个触发周期），可直接进重建管线。

拍摄记录：缩略图、同步质量、一键导出数据集

标定内参送进 FoundationStereo 即得逐像素度量深度，反投影得到带真彩、尺度正确的 3D 点云：

深度反投影得到的彩色 3D 点云（单台相机）

重建结果

以 FreeTimeGS 为主线（每个高斯自带速度向量 + 存活时长，快速运动用「短命高斯接力」表达），16 路全用、全分辨率 1920×1200：

指标	结果
PSNR ↑	20.7 → 23.3
SSIM ↑	0.74 → 0.79
LPIPS ↓	0.534 → 0.393
人脸边缘与真值的差距	关闭 48%
快动肢体误差	−13%，首次反超基线

自由视角环绕 · 横向 ±74cm · 1918×1198 · 2× 超采样：

当前浏览器不支持直接播放该视频。

GT（左）vs 渲染（右）· 6 帧对照

移动阵列的重建

阵列移动 + 被摄者走动，两层运动叠加。刚体内部的相对位姿不变，但阵列相对世界的位姿逐帧在变，需要额外估计每帧的 6 自由度整体位姿——好在阵列是刚体、物理基线又给了尺度，这件事可解。

当前浏览器不支持直接播放该视频。

与 LetCamsGo（据我所知是唯一公开做「相机采集中移动 + 动态场景」的工作）对比：

方法	逐场景 PSNR（Lunch / Blackboard / Play）	均值
我们（500K 冠军配置）	—	22.11
LetCamsGo “Ours”	21.07 / 19.23 / 16.85	19.05
他们跑的 FTGS*（与我们同底座）	20.12 / 18.60 / 15.90	18.21
他们跑的 MoSca	20.40 / 18.86 / 16.08	18.45

这个 +3.06 dB 的口径尚未完全对齐，所以我没把它当成结论，正在采更多移动场景做受控验证。

浏览器端 4DGS

不装任何软件，打开链接即可播放动态高斯场景——高斯模型参数化裁剪 + WebGPU 渲染，模型经 CDN 分发，加载完成自动播放。

在线体验：https://dede-4dgs.zeabur.app/　（建议 Chrome；首次打开需下载 267–437 MB 模型）

当前浏览器不支持直接播放该视频。

浏览器内实时播放：400 万高斯，可自由旋转 / 平移 / 缩放

帧率完全取决于设备。同一份场景的全量 655 万高斯在原生查看器 + RTX 3060 笔记本上只有 3 fps、显存占 6 GB；裁剪后的 400 万高斯版在浏览器里、M5 Mac 上约 20 fps。

数据集

每个数据集都是拆分好的左右目 + 每台相机自带标定内参，时间轴严格均匀，可直接进重建管线。静态阵列累计 23 个场景，移动阵列 + IMU 单独建库 2 个场景，共 83.4 GB。素材覆盖大幅形变织物、多人遮挡、大范围站姿活动与移动阵列几类难点。

数据集归档 · 静态阵列 23 个场景

下一步

重建：采更多移动场景做受控验证，把 +3.06 dB 的口径彻底对齐；
Web 播放：前后景分离（静止背景用 3DGS、动态部分才用 4DGS），渲染底座换成 fastgs，目标是更快加载、更稳帧率；
硬件：外场验证「拆卸—搬运—复位」后的标定复用性，这是全可拆卸方案唯一的真风险点；
表达能力：转向动态外观残差——当前颜色模型每个高斯固定不变，表达不了表情变化带来的阴影与牙齿显露。