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.