firmware-review_skill

This skill helps you review Rust firmware for safety-critical CAN, watchdogs, e-stop handling, and VESC integration to ensure robust BVR operation.
  • Rust

28

GitHub Stars

4

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill ecto/muni --skill firmware-review

  • can-protocol.md12.4 KB
  • safety-checklist.md10.0 KB
  • SKILL.md20.1 KB
  • state-machine.md14.6 KB

Overview

This skill reviews Rust firmware for the BVR (Base Vectoring Rover) with emphasis on safety-critical systems, CAN bus protocol correctness, motor control logic, and embedded testing patterns. It targets Jetson Orin NX firmware using Tokio async runtime and SocketCAN, and focuses on watchdogs, e-stop behavior, rate limiting, VESC integration, and state machine correctness. Use it to get concrete findings, risk categories, and actionable recommendations for firmware changes.

How this skill works

The review inspects control and state crates, CAN abstractions, VESC protocol encoding/decoding, and the main daemon for correct async patterns and error handling. It checks watchdog feed/timeout logic, e-stop transitions, rate limiter math and dt handling, VESC frame encoding (extended ID, big-endian), LED peripheral commands, and CAN error paths. The skill flags red flags, maps them to lines/files, and proposes fixes and unit/integration tests to validate behavior.

When to use it

  • Reviewing BVR firmware pull requests or commits before merge
  • Debugging actuator/motor behavior or lost CAN communication
  • Validating safety mechanisms after configuration or logic changes
  • Evaluating async runtime usage and potential deadlocks in bvrd
  • Designing tests for watchdogs, e-stop, rate limiting, or VESC frames

Best practices

  • Verify watchdog creation, feed() on valid commands, and periodic is_timed_out() checks in main loop
  • Ensure E-Stop is handled from every mode and can only be released via explicit event
  • Apply rate limiting using dt with direction-change detection and clamp velocities before sending
  • Encode VESC extended CAN IDs as (cmd << 8) | id and use big-endian byte order for payloads
  • Use thiserror for library crates, anyhow with context in binaries, and avoid unwrap() on recoverable errors

Example use cases

  • Identify missing watchdog checks that allow motors to keep running when teleop stops
  • Find state-machine paths that permit e-stop bypass or improper transitions
  • Detect VESC encoding bugs: little-endian payloads or unclamped duty values
  • Validate rate limiter resets on mode change and check dt edge cases to avoid divide-by-zero
  • Review LED command mapping to ensure correct colors/periods for each rover state

FAQ

Focus is on crates/control, crates/state, crates/can (vesc.rs, leds.rs) and bins/bvrd/src/main.rs, plus config/bvr.toml for ID and timeout settings.

How are VESC IDs and byte order verified?

Check that IDs are read from config (not hardcoded), commands form extended IDs with (cmd << 8) | id, and payloads use to_be_bytes() for big-endian encoding.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
firmware-review skill by ecto/muni | VeilStrat