开发日志 #1：为什么选这些零件，为什么是这个架构

这不是教程。这是一篇关于 3we 平台设计决策的日志——我们选了什么、放弃了什么、以及中间踩了什么坑。如果你在评估这个项目是真实工程还是空中楼阁，这篇文章写给你。

---

我们在解决什么问题

大多数”开源机器人”项目分两类：

1. 玩具级 — Arduino 小车加超声波传感器，没有路径规划，没有 SLAM，做不了研究
2. 学术一次性 — 定制硬件动辄 3-5 万，跑着没人维护的 ROS1 代码，需要博士生才能操作

我们想要第三种选择：成本低于一台好显示器、跑现代 ROS2、有 Python API 让 ML 研究者不用学 colcon build 就能上手。这个目标决定了下面所有的选择。

---

为什么选 ESP32-S3 + Raspberry Pi 5

我们否决的方案

方案	否决原因
纯 STM32	电机控制很好，但没有内置 WiFi/BLE。加无线=多一颗芯片、PCB 更复杂、故障点更多
Jetson Nano/Orin	成本是 Pi 5 的 4 倍。GPU 对 2D 导航来说是杀鸡用牛刀——我们用 Hailo-8L 做推理，更便宜更省电。而且 Jetson 意味着 NVIDIA SDK 锁定
单芯片方案（Pi 5 干所有事）	Pi 5 跑 Linux。Linux 不是实时的。在 Linux 调度器上做 1000Hz 电机 PID = 抖动 = 里程计漂移 = SLAM 不准
ESP32（初代，非 S3）	没有 USB-OTG。我们需要 USB-CDC 跑 micro-ROS 通信。而且内存更少

最终方案

ESP32-S3 负责：

• 1kHz 电机 PID（4 通道，正交编码器）
• 100Hz IMU 融合（BNO055，I2C）
• 安全看门狗（Pi 心跳丢失 200ms 立即停电机）
• micro-ROS agent（USB-CDC 通信）

Raspberry Pi 5 负责：

• ROS2 Jazzy（Nav2、SLAM Toolbox、感知）
• Hailo-8L 推理（13 TOPS，M.2 HAT）
• Python SDK 服务
• WiFi AP 开发接入

这个分层并不新颖——和商业 AMR（ABB、MiR 等）是同样的架构。我们的贡献是让它在 2200 元以内可复现。

选 ESP32-S3 的真正原因

说实话？因为它淘宝 28 块，文档写得好，ESP-IDF + micro-ROS 工具链能用，不用和 CMake 打三天架。我们先试了 STM32，HAL 库和 CubeMX 代码生成的体验痛苦到两周后直接切换了。

---

为什么选麦克纳姆轮

差速驱动更简单也更便宜。我们还是选了麦克纳姆轮，因为：

1. 全向运动 — 机器人可以横移。这让对接变得很简单（垂直靠近、平移进入），室内导航更干净（走廊里不用三点掉头）。

2. Nav2 兼容 — Nav2 的全向运动模型直接支持麦克纳姆。差速驱动需要不同的控制器配置，在狭窄空间里路径更差。

3. 研究价值 — 全向平台对 RL 研究更有趣，因为动作空间更丰富（3自由度：vx, vy, omega vs 2自由度：v, omega）。

我们接受的缺点

麦克纳姆轮在地毯和不平地面上抓地力很差。辊子会打滑。在地毯上里程计 10 米漂移约 5%（无 LiDAR 修正时）。硬地板上在 1% 以内。

我们接受这个限制，因为主要使用场景是室内实验室和办公室（硬地板）。如果需要户外能力，换差速驱动——SDK API 不变，只改固件运动学模型。

---

PBC-34：载荷总线

问题

研究者想安装自定义硬件：机械臂、额外摄像头、土壤传感器、空气质量检测器。显而易见的方案是”直接接 GPIO”——但这带来三个问题：

1. 无隔离 — 载荷短路会干掉机器人主控
2. 无发现 — SDK 怎么知道接了什么载荷？
3. 无电源管理 — 不做浪涌保护就没法热插拔

我们做了什么

一个 34 pin 连接器（2×17，2.54mm 间距，便宜且随处有售），包含：

• 独立供电轨（5V/5A、12V/3A、VBAT/10A），每路有 P-MOS 高侧开关
• I2C、UART、SPI、CAN、USB、GPIO——按需选用
• EEPROM 自动发现（24C02，I2C 地址 0x50）——插上，机器人读描述符，SDK 暴露载荷 API
• 硬件过流保护（每路独立，<1ms 关断）
• DETECT 物理触点引脚——不靠纯软件检测

原型阶段踩的坑

Rev A：我们用了 N-channel MOSFET 做低侧开关。问题：MOS 关断时载荷地浮空。载荷和机器人底盘之间的寄生电容产生噪声，把 I2C 总线搞崩溃。花了两周调试”随机 I2C 错误”。

修复：换成 P-channel 高侧开关（5V 用 Si2301CDS，12V 用 AO3401A）。地线始终连接，再无浮地问题。

Rev B：EEPROM 检测能用了，但我们忘了在机器人侧 PCB 上给 DETECT 引脚加上拉。如果载荷没有 DETECT 电阻（早期原型），引脚浮空，固件以为载荷在反复插拔。

修复：加了 10k 上拉，固件改为要求稳定低电平持续 50ms 才触发发现流程。

这些是无聊的、真实的问题，不会出现在 README 里。但也正是因为我们踩了这些坑、诊断了原因、修好了它们，我们才有信心说这个设计是靠谱的。

---

目前真实状态

组件	状态	缺什么
Mock 后端	✅ 可用	309 个测试通过，导航演示可跑
固件	✅ 可用	台架电机测试通过，需要现场跑时长
ROS2 栈	✅ 可用	Nav2、SLAM、感知在 Gazebo 中运行
真实硬件后端	部分可用	ROS2 桥接能跑，需要与完整 SDK 集成测试
PyPI 发布	未完成	从源码安装可用，还没发到 PyPI
Isaac Sim 后端	已打桩	接口已定义，未与真实 Isaac Sim 测试
Gazebo 后端	部分可用	独立运行没问题，还未通过 SDK 完整测试
硬件验证	进行中	充电底座 PCB 未测试，主板在 rev C

诚实总结：软件栈在 mock 模式下端到端跑通了，固件在真实硬件上跑通了，但完整的 Sim2Real 链路（SDK → ROS2 → 固件 → 电机）还没有作为完整链条验证过。 这是下一个里程碑。

---

现在就可以在你的电脑上跑

不用相信我们说的任何话。克隆，安装，运行：

git clone https://github.com/telleroutlook/3we-robot-platform.git
cd 3we-robot-platform
pip install -e sdk/threewe/
python examples/navigate_office.py

Mock 后端模拟机器人在办公室中导航，有碰撞检测和 LiDAR 光线投射——纯 Python，除了 numpy 零依赖。

---

下一步

1. PyPI 发布 — pip install threewe 应该直接能用
2. 完整 Sim2Real 链路测试 — SDK → Gazebo，录视频证明
3. 真实硬件视频 — 电机转起来、LiDAR 扫描、Nav2 导航
4. 社区反馈 — ML 研究者到底想要什么样的 API？

如果你对第 4 点有想法，欢迎开 issue 或参与讨论：github.com/telleroutlook/3we-robot-platform