Check the vehicle state before sending each command
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- rust
- 領域
- embedded-iot
調査の方向性
Read the command handlers and state handling around the existing command flow, then review related issues #14, #11, and #37–#42 for context. Add a shared precondition check before command frames are built, with fixture state tests and documentation of the rule. Done means the first implemented command uses the helper and rejected commands receive a failed CommandResponse.
索引モデルが issue の本文から書いたものです。
説明
Part of the prerequisites for real commands (tracking issue to follow). Related: #14, #11.
Problem
The generic "command availability" work (#14, contracts#13) is a larger feature and will come later. Until then, a command handler that just sends frames could, for example, open the charge port or close a window while the car is driving, or act on a state that went stale when the bus fell silent. All E-GMP commands are still "Not implemented" (#37–#42), so this can be settled before the first one lands.
Proposal
- A shared check that runs before a command's frames are built. Each command declares the state it needs, and a command that doesn't hold is answered with a failed
CommandResponseand a clear message. A dedicated status code comes with contracts#13. - State freshness counts as a precondition. Don't act on state older than N seconds, or while the bus is silent (see #11).
- The response is always sent, including when the command is rejected because read-only is on or the identity isn't confirmed.
- Consider a minimum interval between repeats of the same command, so a stuck button can't flood the bus.
- Each command PR lists its preconditions in its description and in
docs/. Candidates to settle per command from real behaviour: not driving (charge port, trunk and frunk), car awake, current state differs from the requested one.
Done when
There is a helper and tests with fixture states, the docs describe the rule, and the first implemented command uses it.
- 主要言語
- Rust
- スター
- 1
- フォーク
- 0
- 平均マージ
- 14時間 32分
- マージ済み PR（30日）
- 21
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
OpenCarControls/firmware のほかの issue
-
e-gmp enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
OpenCarControls/firmware#75 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
OpenCarControls/firmware#74 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
OpenCarControls/firmware#72 ·
メンテナーはふだん 1 日以内に返信
-
e-gmp enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
OpenCarControls/firmware#71 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
OpenCarControls/firmware#70 ·
メンテナーはふだん 1 日以内に返信
OpenCarControls/firmware の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
メンテナーはふだん 1 日以内に返信
-
C-bug needs-triage O-UEFI T-libs
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
bug priority: P3 ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
shep-pm/shep-kelpie#1332 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
ramensoftware/windhawk#1156 · コメント 2 件 ·
-
area/cli complexity:trivial good first issue Stellar Wave test
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Externalize-Labs/externalize#23 ·
メンテナーはふだん 1 日以内に返信