The Rogue Tensor 72″ is our autonomous mowing platform — a Bad Boy Rogue 72″ with the Kawasaki FX1000V EFI, retrofitted into a mower that learns a property, maps its keep-outs, and quietly takes the Saturday-morning chore off the calendar. This page is the running log of every decision that got us here.
Before any code or sensors, we needed a chassis we could trust to take the abuse of being controlled by a computer for hours at a time. Here's how we landed on the Bad Boy Rogue.
A zero-turn radius (ZTR) mower controls each rear wheel independently with a hydrostatic transmission. From a controls standpoint, that's a gift — the platform is already a differential drive, which is the same kinematic model nearly every wheeled robot uses. We don't have to fight an Ackermann steering geometry or simulate a virtual rear wheel. Forward kinematics and odometry slot right in.
The Rogue 72″ ships with Kawasaki's FX1000V EFI — a 999 cc, 90° air-cooled V-twin rated by Kawasaki at 38.5 hp at 3,600 RPM and 57.8 lb-ft of peak torque at 3,200 RPM. It's a commercial engine in a commercial deck, and the EFI side of it matters to us for reasons that all get worse the moment a human isn't standing on the platform:
Bad Boy's commercial line is the Rogue, and the spec sheet shows it. The 72″ deck is 3-gauge fabricated with a 1/4″ top, reinforced 3/8″ sides, and a 1/2″ leading edge — meaningfully heavier-built than a stamped residential deck, which matters when the thing driving it is a state machine and not a person reading the terrain ahead. Underneath, dual 16 cc Hydro-Gear pumps drive 18 ci Parker wheel motors — commercial drivetrain components, not the integrated transaxles you find on consumer ZTRs. Top ground speed is 13 mph; curb weight is 1,595 lb.
The frame uses cast I-beam rails and a 3-link rear trailing-arm suspension with independent fronts (Bad Boy's "EZ-Ride"). The suspension matters more than it sounds: a rigid frame transmits every bump straight into the camera mounts, the IMU, and the GPS antenna. Compliance in the chassis means cleaner sensor data.
For the record: we paid full retail. Bad Boy isn't a sponsor, Kawasaki isn't a sponsor, nobody is — this is a self-funded project and every part on the mower came out of our own pocket. We picked it up from Springfield Mow in Springfield, Missouri, and the experience was genuinely excellent: straight answers on what the Rogue does well, what the trade-offs are, and zero pressure to upsell into something we didn't need. If you're in southwest Missouri and shopping for a commercial ZTR, they're worth the drive.
Two lap bars, two pedals, one PTO clutch. Picking how to move them was the single biggest rabbit hole of the build.
The first instinct — and the one a lot of DIY mower builds reach for — is a pair of large hobby servos. They're fast, they're precise, and the firmware to drive one is a single PWM line. We seriously considered them. The problem is that mowing a long row holds the lap bars at near-full deflection for minutes at a time, and hobby servos are spec'd for movement, not for parking against a continuous load. Hold a hobby servo at stall against a return spring for a 4-hour mow and you cook the windings. That's a duty-cycle problem, and duty cycle is the lens we're using to pick everything that moves on this build.
Duty cycle is how much of any given hour the actuator is allowed to be moving or holding force without overheating. A consumer-grade linear actuator — the kind that lifts a TV out of a cabinet — is typically rated around 25% duty: one minute on, three minutes off. That's fine for a TV. It is catastrophic for something that has to run a lap bar through hundreds of position corrections per minute for hours at a stretch.
A 100% duty cycle rating means the manufacturer says you can drive it continuously, indefinitely, without thermal de-rating — achieved through some combination of bigger motors, better thermal paths, and built-in temperature monitoring. That's the rating class the lap-bar actuators on this mower need to live in.
We're currently evaluating the 100%-duty offerings from Progressive Automations. They publish honest duty-cycle numbers, the lineup runs from very small to industrial-class, and they offer variants with built-in position feedback — which we want, because closing a position loop in firmware is the difference between "actuator at neutral" being a hopeful command and a checkable fact. We haven't locked a model yet; this section will get updated with the part number, stroke, and force rating once it's bolted on.
Engaging the blades is a single 12 V solenoid clutch — binary on/off, switched by a logic-level MOSFET behind a flyback diode. We kept this dirt simple on purpose: when the safety system says "blades off," there's exactly one wire to interrupt.
Sun. Dust. Vibration. Bumps. The yard tries very hard to make a camera lie to you.
Rolling-shutter sensors give you "jelly cam" the moment the chassis hits a tree root. Every line is exposed at a slightly different time, so straight fence posts come out curved. You can maybe dewarp it in software; you absolutely cannot trust the geometry for SLAM or obstacle distance. We pay the global-shutter premium.
A 12 MP sensor staring at a deep shadow next to a sunlit driveway just clips everything. A 2 MP sensor with proper HDR / wide-dynamic-range modes (think IMX462 class) reads both ends of the histogram. We'd rather have a clear 2 MP image than a useless 12 MP one.
Stereo depth assumes both lenses see the same world. Pollen on one lens and not the other and your disparity map turns into modern art. We baked in two mitigations: hydrophobic lens coatings, and a confidence threshold that throws out points whose left/right matches don't agree.
A 120° horizontal FOV gets us peripheral awareness without going full fisheye. Past ~140° the edge pixels carry so little angular resolution that we'd rather just add a third camera.
GigE Vision is the "right" answer industrially — deterministic, long cable runs, PoE. But for a single-vehicle build with the compute mounted three feet from the cameras, USB 3.0 is half the cost and half the configuration. We can revisit when we want PoE-powered cameras on the deck corners.
The CMOS itself shrugs off mower vibration. The thing that fails is the lens locking ring backing off and slowly defocusing the image over a 40-hour mow. Loctite and a witness mark on every lens. Boring, essential.
Hardware on this build
Not sponsors. Not partners. We bought their gear at retail — this is just credit where credit's due.
Early plans had a Raspberry Pi 5 doing the whole job. Once we wrote down the perception loop we actually wanted, the math stopped working.
The deciding factor was the perception loop. Once you commit to running stereo depth, obstacle classification, and grass-vs-not-grass segmentation against multiple camera streams in parallel, you've left the Pi's comfort zone. CPU-only inference of even a small detector model is single-digit FPS on a Pi 5; an add-on AI accelerator helps, but you're still working around limited camera bandwidth and a software stack that wasn't built for it. The Jetson Orin Nano is built for exactly that workload — CUDA, TensorRT, MIPI CSI-2, the whole pipeline.
Our Jetson is shipping now with a 256 GB NVMe SSD, so we get fast model loads and plenty of headroom for cached map tiles, recorded sessions, and on-device datasets without juggling SD cards. Once it's in hand we'll write up the actual perception framerates we measure, side by side, and replace this paragraph with real numbers.
We're going off-the-shelf — we just haven't locked in which off-the-shelf yet. Here's the shape of the decision.
The job isn't mapping. The job is "what's in front of me that wasn't there yesterday." A toy in the yard. A hose. A sleeping cat. We already know the boundary from the teaching pass, and we expect the ground to be roughly planar, so the sensor's job is obstacle detection inside the volume immediately ahead of the mower — not 200 m range, not centimeter-grade accuracy. The bar is "never run over the cat."
The honest answer is "once the cameras and Jetson are integrated." Stereo depth from the cameras might cover more of the obstacle-avoidance load than we initially expected, in which case a 2D spinning unit is plenty as a backup. If stereo struggles — sun glare, dappled shade through trees, low-contrast grass-on-grass targets — we'll move up to a Livox-class solid-state unit. We'd rather decide with real perception data than guess from a spec sheet.
Whatever LiDAR we pick will feed an occupancy grid at the planner level. Stereo cameras feed the same grid. Disagreements are voted on by the safety supervisor: if either sensor says "stop," we stop. Ugly redundancy and we love it.
A standard GPS fix is good to maybe three meters. A mower wandering by three meters eats the flowerbed. RTK gets us to two centimeters — but the question was whether to build our own base station or piggy-back on Missouri's free network.
A normal GPS receiver computes its position from the timing of satellite signals, and the atmosphere mangles those timings just enough to put you a few meters off. Real-Time Kinematic (RTK) cancels that error by comparing your rover's measurements against a second receiver — the base — sitting at a precisely surveyed point. The base broadcasts the local error correction over a stream called NTRIP, and your rover applies it in real time. Two receivers, one stream, and you're suddenly accurate to about 1–2 cm.
The DIY route uses a multi-band receiver like the u-blox ZED-F9P with a survey-grade helical antenna mounted on a tripod or rooftop monument. You let it average a position for 24 hours (longer is better), feed the result back as the base's "known" location, and run an NTRIP caster on a Raspberry Pi to broadcast corrections.
Missouri runs MoDOT GNSS, a public Continuously Operating Reference Station network covering the whole state. Anyone can register for a free NTRIP account and pull corrections from the nearest reference station — or, better, from a Virtual Reference Station the network synthesizes near your rover. The state maintains the monuments, surveys the antennas, and runs the casters. It's a public good and it's outstanding.
We use MoDOT as the primary source. A 4G modem on the mower pulls a VRS stream over NTRIP and feeds it into the ZED-F9P's correction port; first fix typically resolves in under 30 seconds at the start of a mow. When we lose cell signal — back of the property, behind the tree line — the receiver falls back to RTK Float and the mower auto-pauses until Fixed is restored. The mission-control UI surfaces this with a yellow GPS pill in the header so you always know which mode you're in.
MoDOT is excellent, but a private base is a great belt-and-suspenders: it works during cell outages, and during the brief windows when the public caster goes down for maintenance. We're prototyping a Pi-based caster on the workshop roof now. If/when it's reliable, the rover will prefer the local base and silently fall back to MoDOT.
A phone-first mission-control web app on top, ROS 2 in the middle, a safety MCU at the bottom. Each layer has exactly one job.
A single-page web app you install to your phone like a native app. Boundary teaching ("walk the perimeter, I'll record"), keep-out drawing, mow start/pause/stop, live telemetry, session history, return-home. Works offline once map tiles are cached. Built so the mower itself is the server — you connect to its WiFi and you're in.
On the Jetson: stereo + LiDAR fusion into an occupancy grid, RTK-GPS into the EKF,
nav2 for local planning, Fields2Cover for coverage path
generation across the boundary polygon. State-machine over the top so "mowing,"
"transit," "RTK degraded — pause," and "return home" are explicit, observable
modes — not flags.
A Teensy 4.1 sits between the brain and the actuators. It does three things and nothing else: closes the actuator position loop at 1 kHz, runs a 500 ms watchdog (no command => lap bars to neutral, blades off), and listens for the physical e-stop. If the Jetson kernel panics, the MCU doesn't care — it just keeps running the watchdog.
Walk the boundary with the phone. The mower records every step as RTK fixes and simplifies the trace into a polygon. Add keep-outs the same way.
Fields2Cover generates an efficient mow with proper headland turns. The user picks stripe direction; the planner does the rest.
Perception runs on every camera frame. New obstacle? Stop, classify, route around if possible, alert the user if not.
RTK drops to Float? Pause and wait. Camera goes blind? Reduce speed and lean on LiDAR. Connection drops? Lap bars to neutral, immediately.
Explicit "return home" command from the UI, or automatic at end-of-mow. Follows a recorded home path so it never improvises a route through the gate.
Every session writes a JSON log: path, fuel burn, RTK quality history, obstacle events. We mine these to figure out what to fix next.