Prerequisites for implementing real vehicle commands

未关闭
  • 哪里不对？
#75 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
文档
描述清晰度
描述清楚
活跃度
活跃
技术栈
rust
领域
embedded-iot

调研方向

Read the linked prerequisites #71–#74, #15, #16, and the command issues #37–#42 to understand their dependencies and order. For command frame work, the issue points to SavvyCAN logger #22 and contracts/dbc/m-can.dbc. Done means the prerequisites and suggested order are recorded; actual command work waits on those linked issues.

由索引模型根据 Issue 内容生成。

描述

e-gmp enhancement

Tracks what must be settled before the E-GMP commands (#37–#42) start sending frames to a real car. Each item has its own issue; this one only records the order and what each command class needs.

Before any vehicle command transmits

  • #71 Confirm the E-GMP car identity without the VIN on M-CAN (done in #80–#82: the platform from the bus, the exact car from the head unit serial)
  • #72 Decide when CAN read-only is turned off, and who can do it
  • #73 Check the vehicle state before sending each command
  • #15 Fix response routing and dedupe commands (done in #83)
  • #77 Limit how often the same command can repeat (done in #84)
  • #74 Validate a phone in the car before it can send vehicle commands (done in #90, with contracts#35). It gates every vehicle command and splits CAN TX into platform frames and command frames.
  • #92 E-GMP phone validation methods (ignition on + a button first, a code shown on the cluster later)
  • mobile-app#60 The app side of the validation, planned as part of the app UI redesign (mobile-app#50). Until it lands the app cannot validate, so every vehicle command it sends is refused with REJECTED_NOT_VALIDATED.

Before security-sensitive commands (door unlock, windows)

  • #54 Reset the bonds with a power-cycle gesture (done in #87; the way to revoke a lost phone)
  • mobile-app#25 Unpair should remove the phone's bond on the device (follows the #74 rules)

Can follow the first commands

  • #14 Command availability (done in #78, with contracts#32 and mobile-app#56)
  • #11 Stale or asleep state (also feeds the command requirements from #73)
  • #85 Open the pairing window from a validated phone (needs a device-management screen in the app)
  • mobile-app#58 Explain how to recover when a paired device can't be found (done in mobile-app#59)
  • #86 Upgrade trouble-host and esp-radio (BLE-level MITM pairing, if it is ever wanted)

On hold: commands over MQTT (the remote tier)

Remote commands wait until everything works well over BLE. Most users have a plain WiCAN and a custom harness, which have no remote link, so BLE is where the value is. Basic commands over MQTT stay rejected until then (#47).

  • #16 MQTT TLS and signed commands (with contracts#8, contracts#15 and mobile-app#24)
  • mobile-app#57 MQTT topics use the app's client ID instead of the car's

Suggested order for the commands

Start with low-risk commands once the first group is done (flash lights #39, climate #40), and hold the security-sensitive ones until the second group is done. Each command still needs frames captured from the car (SavvyCAN logger, #22) and added to dbc/m-can.dbc in contracts. Each command's PR sets its own requirements and repeat interval (see docs/commands.md).

主要语言
Rust
星标
1
派生
0
平均合并
13 小时 27 分钟
30 天内合并 PR
31

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

OpenCarControls/firmware 的其他 Issue

查看 OpenCarControls/firmware 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。