m0601 on m0601 — RS485 hub motor driver

Crate examples

Mon, 01 Jan 0001 00:00:00 +0000

Crate examples#

Two files, with very different jobs. One is meant to be read and run; the other exists only to be compiled.

`four_wheel_minimal.rs` — the driver on one screen#

cargo run -p m0601 --example four_wheel_minimal -- /dev/ttyUSB0

Four motors at IDs 1–4 on one RS485 adapter. About 50 lines of actual code, and it touches every part of the multi-motor API in the order you’d meet them:

One shared bus. Bus::open(&port, Duration::from_millis(150))?.with_min_gap(…) — the generous timeout is a backstop for the open; the loop passes its own short reply wait per poll. The idle gap is tightened to 2 ms so the cycle in step 5 fits.
One handle per wheel, sign convention applied once. A const WHEELS: [(u8, bool); 4] table pairs each RS485 id with whether that corner is a mirror-image build, and bus.motor(id)?.mirrored(mirror) bakes it in at construction. After that line the application never touches a sign again — +60 means forward on all four. (Mirroring.)
A stop guard armed before the first frame. A tiny struct StopGuard { bus, ids } whose Drop calls bus.safe_stop_all(&self.ids). Because Bus is Clone it holds its own handle to the same port, and because it’s armed before anything moves, a ? early-return or a panic anywhere below still lands on a bus-wide stop.
A group mode switch. bus.set_mode_all(&ids, Mode::Velocity)?.
The loop, budgeted before it moves. A startup assert! on bus_period(4, 1, bus.min_gap(), REPLY_WAIT) — ~17.2 ms at the 2 ms gap and 2 ms reply wait — checks the traffic fits inside the 20 ms cycle and that the cycle stays at or under drive_floor(). Then: drive all four at 60 RPM, resend every ~20 ms (the 50 Hz floor), and poll one wheel per cycle round-robin — never substituting a query for a drive frame, and never polling all four in one cycle. That is the bus budget advice as working code, right down to the assertion that page recommends.

This is the distilled essence of m0601-quad with the TUI, the logger, and the safety state machine removed, so the driver API is the only thing on screen.

Polling and the fail-safe

Mon, 01 Jan 0001 00:00:00 +0000

Polling and the fail-safe#

A drive command to an M0601 does not latch. Send “100 RPM” once and the wheel gives you a brief twitch and then coasts. To make it hold 100 RPM you have to keep saying so — resend the drive frame at least every 20 ms, which is the 50 Hz floor for sustained motion. The motor accepts commands up to 500 Hz; below ~50 Hz it decides you’ve gone away and spins down.

Quickstart

Mon, 01 Jan 0001 00:00:00 +0000

Quickstart#

The smallest useful program: open the port, ask the motor how it’s doing, print it.

use std::time::Duration;
use m0601::M0601;

fn main() -> m0601::Result<()> {
 let mut motor = M0601::open("/dev/ttyUSB0", 0x01, Duration::from_millis(150))?;
 match motor.query()? {
 Some(fb) => println!(
 "{:+} RPM, {:.1}°, {:?} °C, faults: {}",
 fb.speed_rpm, fb.position_deg, fb.temp_c, fb.faults
 ),
 None => println!("no reply — check 18 V power, wiring (brown → GND), A/B, --id"),
 }
 Ok(())
}

query() sends a 0x74 feedback frame and parses the reply. It’s the only reply that carries winding temperature, which is why fb.temp_c is populated here and comes back None from a reply to a drive frame (Telemetry has the details).

scan

Mon, 01 Jan 0001 00:00:00 +0000

`scan` — find motors on the bus#

m0601 scan # broadcast, then poll 0x01..0x0F (~3 s)
m0601 scan --full # poll every address 0x01..0xFE (~40 s)

Reach for scan first whenever the bus misbehaves: it’s how you confirm a motor is present, discover an address you’ve forgotten, or check that you don’t have two motors fighting over one ID.

The two-stage scan#

A default scan does two things. It sends one broadcast query that every motor answers at once, then it polls addresses 0x01 through 0x0F individually. That range is a deliberate bet: motors ship at 0x01 and small fleets stay in single digits, so polling sixteen addresses catches the common case in a couple of seconds instead of the ~40 it takes to walk all 254. If your motors live at higher addresses, you need --full.

Drive loops

Mon, 01 Jan 0001 00:00:00 +0000

Drive loops#

drive_velocity, drive_current, and drive_position each send one frame and return. That’s the whole method. Motion is sustained only if you keep calling them at 50 Hz or faster; stop, and the wheel coasts within a couple of cycles. This isn’t a limitation to paper over — it’s the protocol’s fail-safe, and the API is honest about it rather than hiding a background thread you can’t see.

use std::time::{Duration, Instant};
use m0601::M0601;

fn main() -> m0601::Result<()> {
 let mut motor = M0601::open("/dev/ttyUSB0", 0x01, Duration::from_millis(150))?;

 // Spin at 100 RPM for three seconds: one frame every 20 ms.
 let deadline = Instant::now() + Duration::from_secs(3);
 while Instant::now() < deadline {
 motor.drive_velocity(100)?;
 std::thread::sleep(Duration::from_millis(20));
 }

 motor.safe_stop(); // force velocity, zero, brake. Never errors.
 Ok(())
}

20 ms per cycle is 50 Hz, the floor. Faster is fine (up to 500 Hz); slower and the motor starts coasting between frames, which reads as a wheel that stutters or won’t hold speed.

info

Mon, 01 Jan 0001 00:00:00 +0000

`info` — config plus a live snapshot#

m0601 info
m0601 --id 0x02 info

info answers “is this motor there, and what does it say about itself right now?” It prints the connection configuration and the fixed ranges for each control mode, sends a single query, and shows one decoded reply. Nothing moves. It’s the natural follow-up to scan and a handy scriptable presence check, because it exits non-zero when the motor doesn’t answer.

m0601-quad

Mon, 01 Jan 0001 00:00:00 +0000

`m0601-quad` — the four-wheel reference app#

m0601-quad drives four M0601 wheels as one skid-steer rover, and it is this repo’s reference implementation for multi-motor use of the library. Where four_wheel_minimal shows you the API, m0601-quad shows what an application built on that API has to add: a durable wheel map, a dedicated scheduler thread, a safety state machine, a dashboard, and logging.

It is not published to crates.io (publish = false) — it’s meant to be read and adapted, not depended on. Clone the repo and run it from the workspace.

The bus

Mon, 01 Jan 0001 00:00:00 +0000

The bus#

RS485 is a two-wire, half-duplex, multi-drop bus. One differential pair (A/B) carries traffic in both directions but only one direction at a time, and any number of motors can hang off it, each with a unique address from 0x01 to 0xFE. The host talks, a motor answers, and everyone shares the same two wires.

“One direction at a time” is the whole story on this page. It’s why the driver is careful about when frames go out, not just what’s in them.

Modes

Mon, 01 Jan 0001 00:00:00 +0000

Modes#

The motor runs one control loop at a time, and the active mode decides how it reads the 16-bit value in a drive frame. Switch with set_mode, then drive:

use m0601::Mode;

motor.set_mode(Mode::Current)?; // sends the 0xA0 switch frame 5×, ~100 ms
motor.drive_current(4096)?; // ≈ 1 A of torque; resend at 50 Hz to hold

motor.set_mode(Mode::Position)?; // only legal below 10 RPM
motor.drive_position(16384)?; // ≈ 180°; resend at 50 Hz to hold

Mode	Setpoint	Physical meaning
`Velocity` (default)	−330..330 (i16)	RPM
`Current`	−32767..32767 (i16)	≈ −8..+8 A (`A = raw × 8 / 32767`)
`Position`	0..32767 (u16)	0°..360° (`deg = raw × 360 / 32767`)

A few things the table doesn’t tell you:

monitor

Mon, 01 Jan 0001 00:00:00 +0000

`monitor` — continuous telemetry#

m0601 monitor --hz 5 # live one-line dashboard, Ctrl+C to stop
m0601 monitor --hz 20 --csv log.csv # ...and log every reading to a CSV (see the truncation note)

monitor is info on repeat: it polls at a rate you choose and keeps a single line updated in place, optionally logging every reading to CSV. It only ever queries — it never sends a drive frame — so the wheel keeps doing whatever it was doing (idle, or driven by something else on the bus). Use it to watch temperature climb under load, capture a run for later analysis, or just confirm a controller elsewhere is doing what you expect.

Telemetry and echo

Mon, 01 Jan 0001 00:00:00 +0000

Telemetry and echoes#

Two things make decoding a reply less obvious than reading ten bytes off the wire: the motor answers in two different layouts, and many USB adapters prepend a copy of what you just sent. Get either wrong and you don’t get an error — you get a plausible, confidently wrong number. On a motor with real torque, one of those wrong numbers is dangerous.

The two reply layouts#

Bytes 0–5, 8, and 9 of a reply are the same in both layouts: address, mode, current, speed, faults, checksum. Only bytes 6–7 differ, and which meaning they carry depends on the command that asked:

control

Mon, 01 Jan 0001 00:00:00 +0000

`control` — drive from the keyboard#

m0601 control --rpm 100 # full-screen dashboard; F/B drive at ±100

control is the interactive cockpit: a full-screen dashboard that runs the 50 Hz drive loop for you and takes live keystrokes. It’s what you want when you’re bringing up a motor by hand and reacting to what you see. Its non-interactive twin is drive.

This starts a live control session with no confirmation. Presets reach 250 RPM on a gearless wheel. Clear it first. → Safety

Stopping safely

Mon, 01 Jan 0001 00:00:00 +0000

Stopping safely#

Stopping a motor sounds like it should be the easy part — send zero. It isn’t, because on this motor zero doesn’t mean what you’d assume, and because a stop often has to run from the worst possible moment: a panic, a signal, a dropped connection.

The mode switch before the stop#

A zero setpoint means “stop” only in velocity mode. The identical zero-valued drive frame means “rotate to 0°” in position mode — a stop command that could spin the wheel up to half a turn on its way to “stopping” — and in current mode it means zero torque, a coast, with the brake byte ignored entirely.

Telemetry

Mon, 01 Jan 0001 00:00:00 +0000

Telemetry#

Every frame the motor replies to carries telemetry, including drive frames — so a 50 Hz loop can read while it commands. transact is the method for that: send a frame, get the parsed reply back in one exchange.

use m0601::protocol::frame_velocity;

let frame = frame_velocity(motor.id(), 100, 1);
if let Some(fb) = motor.transact(&frame, std::time::Duration::from_millis(6))? {
 // A drive reply: fine 16-bit angle, but NO temperature.
 assert!(fb.temp_c.is_none());
 println!("{:+} RPM at {:.2}°", fb.speed_rpm, fb.position_deg);
}

The two layouts#

The catch is that the motor answers in two different frame layouts, and which one you get depends on the command that asked:

drive

Mon, 01 Jan 0001 00:00:00 +0000

`drive` — hold a setpoint, scriptably#

m0601 drive velocity --rpm 100 --secs 3
m0601 drive current --amps 1.5 --secs 2
m0601 drive position --deg 180

drive is the batch counterpart to control: it holds a single setpoint in one mode, resending it at 50 Hz until a timer elapses or you interrupt, then it brakes. It’s what you use in scripts and test rigs, where you want one command that does one thing and stops itself cleanly.

Latency

Mon, 01 Jan 0001 00:00:00 +0000

Adapter latency#

Here’s a failure that looks like a protocol problem but is really a USB one. You send a query, wait a reasonable 6 ms for the reply, read the port — and get nothing. Do it again, same result. The motor is fine, your framing is fine, and the reply did arrive. It’s just still sitting inside the adapter.

FTDI-based adapters — the usual RS485 dongle — don’t hand each byte to the host as it lands. They batch received bytes until a USB packet fills or their latency timer fires, and from the factory that timer is 16 ms. A 10-byte reply that physically arrived in under a millisecond can therefore sit in the adapter for up to 16 ms before your program sees it. That’s longer than this protocol’s entire reply window, and it’s far longer than the 20 ms cycle a 50 Hz loop lives in. Short reply waits read nothing, every time, and the bus looks dead.

Odometry

Mon, 01 Jan 0001 00:00:00 +0000

Odometry#

The motor’s position reading is single-turn absolute: it tells you where in a revolution the wheel is, and it wraps from 359.99° back to 0° every turn. That’s exactly wrong for distance travelled — naïvely differencing samples gives you a −360° jump each revolution.

PositionAccumulator unwraps it into a continuous angle:

use m0601::PositionAccumulator;

let mut odo = PositionAccumulator::new();
// in the poll loop:
if let Some(fb) = motor.query_with(reply_wait)? {
 let travelled_deg = odo.update(fb.position_deg);
 println!("{travelled_deg:.1}° ({:.2} rev)", odo.revolutions());
}

Method	What it does
`update(deg)`	feed one absolute sample; returns the updated continuous angle
`update_raw(u16)`	same, from a raw drive-reply reading (`0..=32767`)
`cumulative_deg()`	the running total without feeding a sample
`revolutions()`	the same value as whole and fractional turns
`reset()`	forget the reference and zero the total

Three properties worth knowing:

Multi-motor bus

Mon, 01 Jan 0001 00:00:00 +0000

Multi-motor robots#

RS485 is multi-drop: every wheel shares one A/B pair, each answering to a unique address. A Bus owns that shared port and mints per-motor handles that are cheap to clone and safe to move between threads — they all funnel through one physical port, with the coordination handled for you.

use std::time::Duration;
use m0601::Bus;

fn main() -> m0601::Result<()> {
 let bus = Bus::open("/dev/ttyUSB0", Duration::from_millis(150))?;
 let mut left = bus.motor(0x01)?.mirrored(true); // FIT1042, left side
 let mut right = bus.motor(0x02)?; // FIT1038, right side

 // Mirrored, "+100" drives the robot forward on both sides.
 left.drive_velocity(100)?;
 right.drive_velocity(100)?; // ...and resend both at ≥50 Hz
 Ok(())
}

Mirroring#

On a two-sided robot the left and right wheels face opposite ways, so “forward” is +RPM on one and −RPM on the other. mirrored(true) hides that: it negates velocity and current setpoints on the way out and flips the signs of reported speed and current on the way in, so your code speaks in robot-forward terms and both sides agree.

set-id

Mon, 01 Jan 0001 00:00:00 +0000

`set-id` — change a motor’s address#

m0601 set-id --new 0x02 # prompts for confirmation
m0601 set-id --new 0x02 --yes # skips the prompt

Every motor on an RS485 bus needs a unique address. Fresh motors all ship at 0x01, so before you can put two on one bus you have to renumber them — one at a time, with this command. The new address is written to flash and survives power cycles.

Options#

Flag	Default	Meaning
`--new <id>`	(required)	the new address, `0x01..0xFE` (hex or decimal)
`--yes`	off	skip the confirmation prompt

The one-motor guard#

The set-ID frame is unaddressed. It carries no target — every motor that hears it takes the new address. Put two motors on the bus and run set-id once, and now you have two motors at the same address, which you can only untangle by disconnecting them one at a time and renumbering again. It’s persistent state that’s tedious to undo, so the command works hard to stop you doing it by accident.

The driver boundary

Mon, 01 Jan 0001 00:00:00 +0000

The driver boundary#

This crate is a motor driver, not a robot framework. Knowing exactly where it stops saves you from two opposite mistakes: reaching around it to re-encode things it already owns, and waiting for it to grow features that are yours to write. This page draws the line and explains why it sits where it does.

The boundary rule#

The driver owns three layers, and nothing above them:

Budgeting the wire

Mon, 01 Jan 0001 00:00:00 +0000

Budgeting the wire#

Every multi-motor loop eventually asks the same question: will N wheels plus their polls fit in my cycle? The crate answers it with arithmetic rather than advice, so you size a loop instead of guessing at one and discovering the answer as a wheel that stutters.

Three functions, all pure and I/O-free:

use std::time::Duration;
use m0601::{bus_period, drive_floor, frame_time};

let frame = frame_time(); // ~868 µs — one 10-byte frame at 115200 8N1
let floor = drive_floor(); // 20 ms — the longest gap before a wheel coasts
let gap = Duration::from_millis(2);
let period = bus_period(4, 1, gap, gap); // four drives + one poll ≈ 17.2 ms

The two cycle bounds#

A periodic control loop has to satisfy both of these at once, and they squeeze from opposite sides:

raw

Mon, 01 Jan 0001 00:00:00 +0000

`raw` — send an arbitrary frame#

m0601 raw "01 74 00 00 00 00 00 00 00" # 9 bytes: CRC appended for you
m0601 raw "01 74 00 00 00 00 00 00 00 FF" # 10 bytes: sent exactly as typed
m0601 raw --yes "01 64 00 64 00 00 03 00 00" # a drive frame — needs --yes

raw is the protocol workbench. It sends bytes you specify and prints what comes back, decoding the reply when the command you sent is one that elicits telemetry. Use it to poke at the protocol, reproduce a frame from the reference, or test how the motor reacts to something deliberately malformed.

Testing without hardware

Mon, 01 Jan 0001 00:00:00 +0000

Testing without hardware#

M0601 and Bus are generic over a Transport, and one of the transports is a mock. That means the same code you ship on hardware runs unchanged against a scripted in-memory bus — no cfg flags, no seams to maintain. It’s how the crate’s own driver tests work, and it’s public API you can use for yours.

use std::time::Duration;
use m0601::{M0601, MockTransport};

let mock = MockTransport::with_replies([
 // one query reply: 100 RPM, 40 °C, position byte 0x00
 vec![0x01, 0x02, 0x00, 0x00, 0x00, 0x64, 0x28, 0x00, 0x00, 0x00],
]);
let mut motor = M0601::with_transport(mock, 0x01, Duration::from_millis(150))?;

let fb = motor.query()?.unwrap();
assert_eq!(fb.speed_rpm, 100);

// Then inspect exactly what your code put on the wire:
let mock = motor.into_transport().unwrap();
assert_eq!(mock.sent.len(), 1);

Two halves make it useful: you script what the “motor” says with with_replies, and afterward you recover the transport with into_transport to assert on sent — every frame your code transmitted, in order. So you can test both directions: did the motor report what I expected me to do with it, and did I send the right bytes?

Getting started

Mon, 01 Jan 0001 00:00:00 +0000

Getting started#

This page gets you built, wired, and permitted. If you’d rather learn by doing, the first-spin tutorial covers the same ground with a motor actually turning.

Build & install#

You need Rust 1.88 or newer — the crate uses edition 2024 and let-chains, so older toolchains won’t compile it. Linux is the tested platform; the serial layer is portable, but the device paths and the dialout group below are Linux-isms.

First spin

Mon, 01 Jan 0001 00:00:00 +0000

First spin#

This is the motor-on-the-bench walkthrough: from bare wires to a spinning wheel and back to a controlled stop, with what you should see at each step and what to do when you don’t. It assumes you’ve built the CLI (Getting started).

A direct-drive hub motor has real torque (2 N·m stall) and no gearbox to slow it down. Before anything spins: get the wheel off the ground or clear of fingers, cables, and the edge of the bench. Ctrl-C brakes, but only while the process is alive to do it. → Safety

Safety

Mon, 01 Jan 0001 00:00:00 +0000

Safety#

A direct-drive hub motor is not a hobby servo. There is no gearbox between the winding and the tyre, 2 N·m of stall torque, and the CLI’s presets reach 250 RPM. It will drive a chassis off a bench, and it will not notice your hand.

This page is the one place all of that is stated plainly. The warnings scattered through the rest of the docs point here.

Setpoint shaping

Mon, 01 Jan 0001 00:00:00 +0000

Setpoint shaping#

There are four different things in this system that can be called “ramping,” and they act at different places. Getting them straight is the difference between a machine that starts smoothly and one that trips its own overcurrent protection.

Firmware-side control loops#

The M0601 closes velocity, current, and position in its own firmware. Selecting a Mode chooses which of the motor’s PIDs your drive frame feeds. It does not hand you an open-loop actuator to close a loop around.

Protocol reference

Mon, 01 Jan 0001 00:00:00 +0000

M0601 protocol & hardware reference#

Everything this repo knows about the DFRobot M0601 direct-drive hub motor, compiled from the official documentation and three independent implementations, cross-checked byte-for-byte against this crate’s test vectors. Where sources disagree, the disagreement is recorded (see Known contradictions) rather than silently resolved.

This is the byte-level reference. For what these frames mean and why the driver handles them the way it does, see Concepts — especially The bus and Telemetry and echo.

FAQ & gotchas

Mon, 01 Jan 0001 00:00:00 +0000

FAQ & gotchas#

The questions that come up once you’re past “does it turn,” most of them the kind you only ask after something surprising happened. Troubleshooting is the symptom-to-fix table; this is the why-does-it-do-that.

Wheel spins briefly, then coasts#

Your control loop is running below 50 Hz. A drive command doesn’t latch — the motor holds a setpoint only while frames keep arriving at least every 20 ms, and coasts otherwise. Either your loop’s sleep is too long, or you replaced a drive frame with a telemetry query on some cycles (that leaves a hole in the drive cadence). Read telemetry from the drive reply instead, and keep the loop at 20 ms. See Polling and the fail-safe.

Troubleshooting

Mon, 01 Jan 0001 00:00:00 +0000

Troubleshooting#

Symptom on the left, the thing to check on the right. This page is deliberately just the table — where a symptom has a Why link, that’s the FAQ entry which owns the full explanation, so nothing is explained twice in two places.

Symptom	Check	Why
`scan` finds nothing	18 V power on? A/B swapped (try orange ↔ white)? Brown wire → GND? A silent bus is almost always wiring.	why
`Permission denied` on the port	`sudo usermod -aG dialout $USER`, then log out and back in.
Found the motor, but `info` won’t read it	Wrong `--id`, or the RX half of the wiring. `scan` shows the real address.
Wheel spins briefly, then coasts	Your loop is under 50 Hz, or a query is replacing a drive frame on some cycles. Keep the drive cadence at 20 ms.	why
Sent zero, but it moved or didn’t brake	You weren’t in velocity mode. Use `safe_stop` / the `S` key, which force velocity first.	why
`control`’s `P` (or `drive position`) refused	Wheel at ≥10 RPM, or no telemetry yet (it fails closed on unknown speed).	why
Faults the instant a drive starts	Ramp too steep — accel `1` (and `0`, the same ramp) spikes current past the 3 A protection. Soften with a larger accel byte; `3`–`5`, not 40. Auto-resets in ~5 s.	why
Motor ignores drive frames, a fault bit is set	A protection is active (3 A bus / 4.6 A phase / 80 °C / stall). The motor stops responding to drive commands until it clears — ~5 s, or on cooling to 75 °C for overheat.
`raw` refuses to send my frame	It’s a motion command (byte 1 = `0x64` or `0xA0`). Pass `--yes`.	why
Intermittent garbage / dropouts	Brown wire floating, or missing 120 Ω termination on a cable over ~1 m.	why
Chaos after a `set-id`	The unaddressed frame renamed every motor that heard it. Reconnect one at a time and renumber.	why
A rejected `--rpm` / `--amps` / `--deg`	Out of range. The CLI rejects rather than clamps; the library clamps.	why
`kill -9` didn’t stop the motor	Correct — nothing runs, so it coasts. Not an emergency stop; cut power.	why
Short reply waits read nothing	FTDI 16 ms latency timer. See Latency — the udev rule fixes it.

End-to-end checklist#

Work outward from the physical layer, because that’s where the failures cluster:

Internals

Mon, 01 Jan 0001 00:00:00 +0000

Internals#

For contributors and the curious: how the crate is put together, and why it’s shaped that way. None of this is needed to use the driver — it’s the map you’d want before changing it.

The transport seam#

All I/O goes through one small trait, Transport, with two implementations: SerialTransport for real hardware and MockTransport for tests. M0601 and Bus are generic over it, so the exact code that ships runs unchanged against a scripted in-memory bus — there are no cfg(test) branches threading through the driver logic.

m0601 on m0601 — RS485 hub motor driver

Crate examples

Crate examples#

four_wheel_minimal.rs — the driver on one screen#

Polling and the fail-safe

Polling and the fail-safe#

Quickstart

Quickstart#

scan

scan — find motors on the bus#

The two-stage scan#

Drive loops

Drive loops#

info

info — config plus a live snapshot#

m0601-quad

m0601-quad — the four-wheel reference app#

The bus

The bus#

Modes

Modes#

monitor

monitor — continuous telemetry#

Telemetry and echo

Telemetry and echoes#

The two reply layouts#

control

control — drive from the keyboard#

Stopping safely

Stopping safely#

The mode switch before the stop#

Telemetry

Telemetry#

The two layouts#

drive

drive — hold a setpoint, scriptably#

Latency

Adapter latency#

Odometry

Odometry#

Multi-motor bus

Multi-motor robots#

Mirroring#

set-id

set-id — change a motor’s address#

Options#

The one-motor guard#

The driver boundary

The driver boundary#

The boundary rule#

Budgeting the wire

Budgeting the wire#

The two cycle bounds#

raw

raw — send an arbitrary frame#

Testing without hardware

Testing without hardware#

Getting started

Getting started#

Build & install#

First spin

First spin#

Safety

Safety#

Setpoint shaping

Setpoint shaping#

Firmware-side control loops#

Protocol reference

M0601 protocol & hardware reference#

FAQ & gotchas

FAQ & gotchas#

Wheel spins briefly, then coasts#

Troubleshooting

Troubleshooting#

End-to-end checklist#

Internals

Internals#

The transport seam#

`four_wheel_minimal.rs` — the driver on one screen#

`scan` — find motors on the bus#

`info` — config plus a live snapshot#

`m0601-quad` — the four-wheel reference app#

`monitor` — continuous telemetry#

`control` — drive from the keyboard#

`drive` — hold a setpoint, scriptably#

`set-id` — change a motor’s address#

`raw` — send an arbitrary frame#