Aurora Riding OS · 骑行设备与语音交互

面向 ESP32-S3 AMOLED 设备的骑行系统探索,包含自有界面、本地按住说话验证与原生手机端配网。

本文目录

个人设备产品原型 · 依据 2026 年 9 月 2 日至 3 日的工程记录整理

Aurora Riding OS 是把 骑行座舱的想法 落到独立设备上的一次尝试:车把上的小屏保留当前需要的信息,复杂操作交给手机,语音提供另一种输入方式。

工程面向 Waveshare ESP32-S3-Touch-AMOLED-2.06 板卡,使用 410 × 502 AMOLED 触摸屏、麦克风、扬声器与电源管理组件。它从独立仓库开始组织设备系统和配套客户端,现成板卡与第三方组件仍属于各自原作者。

设备、手机与语音如何分工

  • 设备端:原生 ESP-IDF 工程管理显示、触摸、电源与本地音频,自有界面承载骑行交互;在线语音计划由设备通过 Wi-Fi 直接连接服务。
  • 手机端:规划承担地图、路线、设备管理与骑行记录。目前已有 iOS 原生客户端和 Security 2 配网流程;Android 仍处于协议与工程规划阶段。
  • 语音运行时:通过受限适配层接入小智事件。设备保留自己的界面与动作边界,手机不承担麦克风音频中继。

先验证一次按住说话

第一阶段选择半双工 PTT:按住屏幕中央区域采音,松开后结束。先让麦克风、扬声器、触摸和状态提示在本地工作,再接网络识别与对话。

2026 年 9 月 2 日的记录确认了 24 kHz 本地音频、非零麦克风采样、松开后的硬件静音和可听提示音。这个阶段的原始音频只保留在 RAM,松手后的声音是本地确认音,还不是 AI 回答。

两个架构取舍

语音可以提出动作,但操作范围由设备限定。 方案只开放查询状态、切换指定页面、停止导航等有限能力,不把重启、升级或清除网络配置交给自由生成的命令。

切换服务配置,不让用户填写任意地址。 9 月 3 日的决策采用经过审核的官方与自建网关配置档,通过加密配网通道选择并保存。选择在下一次创建语音会话时生效,不直接改变正在运行的会话。

原稿记录的进度

范围记录中的状态
电源、屏幕与触摸已完成基础真机验证,包括显示偏移和颜色刷新适配
本地按住说话已完成 9 月 2 日真机验收,覆盖采音、松手静音与提示音
语音事件适配、网关选择已接入并构建,完整交互仍待真机验收
在线语音、OTA、导航数据链路尚未完成验收
手机客户端iOS 已有初版;Android 为后续规划,不能视为双端已交付

这些状态来自仓库 README 与架构决策记录,本次网站整理未重新进行固件构建或真机测试。实际骑行中的风噪、阳光可读性、续航与断连恢复仍需要验证。

技术与来源

设备工程采用 ESP-IDF 6.0.2、LVGL 与板卡音频组件;iOS 使用 SwiftUI,Android 计划使用 Kotlin / Jetpack Compose。原创代码标注 MIT,第三方组件保留各自许可证。

资料依据:项目与客户端 README、原生设备架构决策、本地 PTT 验证记录、可切换语音网关决策。页面日期取自明确标注的 2026-09-02 验证与 2026-09-03 决策,不推断项目创立时间。