OpenMower: turning a cheap robotic mower into an RTK GPS robot

The random-walk problem OpenMower was built to remove

The README opens with a blunt complaint: current robotic mowers drive in a random direction until they hit the border of the lawn, rotate for a randomized duration and repeat. That describes the boundary-wire generation of machines, where a buried loop defines the mowing area and the robot has no idea where it is inside it. Coverage is statistical, the wire is a permanent installation job, and splitting a garden into several areas means more wire.

OpenMower's answer is to take the cheapest off-the-shelf mower the authors could find, a YardForce Classic 500, strip out its controller, and put custom electronics and open-source software in its place. The stated goals are autonomous mowing, an emergency stop when the robot is lifted or crashes, no perimeter wire, support for multiple mowing areas, obstacle detection, rain detection and a cost below a mid-range commercial mower. The audience is the person who owns one of the many mowers built on the same SUMEC hardware and sold under brands such as YardForce and Herkules, and who would rather spend a weekend with a soldering iron than pay for a wire-laying service.

How the ROS stack, mainboard firmware and app fit together

The top-level repository is not the robot. It is a container of git submodules, and the README splits them into three groups. Under software/ sit open_mower_ros for navigation, planning and the state machine, openmower-app for the mobile and web client, and OpenMowerOS for the operating system image. Under firmware/ sit fw-openmower-v2, which handles motor control, sensors and the hardware abstraction layer, and xesc_firmware for the xESC motor controller. Under hardware/ sit three board designs: a universal mainboard, a YardForce-specific one, and one for Sabo and John Deere mowers.

That split tells you where the work lands. Navigation and path planning live in the ROS node graph, the low-level timing-sensitive work lives on the mainboard firmware, and the phone talks to the ROS side through the app. The choice of submodules rather than a monorepo means a clone without the recursive flag leaves you with a README and empty directories, which is the first practical trap of the layout. It also means an issue about path planning belongs in open_mower_ros, not here, and the README's contribution section points at CONTRIBUTING.md for that flow. The topics list confirms the stack: ros, raspberry-pi, arduino, rtk, gps, path-finding.

Cloning OpenMower with its submodules

There is no installer and no package to fetch. The README's only commands are for pulling the repository together with the code it references. The first form clones everything in one pass, which is what you want on a fresh machine:

# clone the repository and all submodules in one pass
git clone --recursive https://github.com/ClemensElflein/OpenMower

If you already cloned the repository and ended up with empty software/, firmware/ and hardware/ directories, the README gives the repair command:

# fetch submodules after an existing clone
git submodule update --init --recursive

After either command the tree should contain the ROS package, the app, the OS image sources, both firmware repositories and the board designs. That is the end of what this repository tells you to run. Everything past this point, the compatibility check, the hardware shopping list, robot modification, software setup and recording mowing areas, is delegated to openmower.de, and the README directs new users there before anything else. The build guide states the hardware comes to roughly €700 excluding the mower and the RTK base station, and that a YardForce-class conversion typically takes a weekend.

The repository layout also shows a configs/ directory at the top level, which is where per-machine configuration is expected to live, but the README does not document its contents or the keys inside it. Treat openmower.de as the source of truth for configuration rather than guessing from the directory names.

What you are signing up for: skills, cost and missing documentation

The disclaimer is not decorative. It says that if you are not 100 percent sure what you are doing, you should not try this at home, and that real technical know-how is required. The getting-started section repeats the point: intermediate electronics, Linux and mechanical skills, with a weekend of work for a YardForce-class mower. That is a fair description of a project that expects you to open a mower, replace its controller board, flash firmware and then debug a ROS system on a Raspberry Pi.

Several things are simply not in this repository. There is no rollback procedure, no recovery path for a bricked mainboard, and no troubleshooting section in the README; those questions are routed to a Discord server the README describes as having more than 2000 members. The licence situation is also split: the README says software repositories are generally GPL or MIT and that you must check the LICENSE file in each individual repository, while this documentation repository uses CC BY-NC-SA 4.0. The repository metadata reports the licence as NOASSERTION because GitHub cannot reduce that mix to a single identifier. If you plan to sell anything built from these designs, the non-commercial clause on the documentation and the per-repository terms are the first thing to read, and the README adds its own warning about patents and local laws that may prohibit building such a robot in your region.

The hardware constraint is the one that decides most projects before software ever runs. The README states that many mowers share hardware manufactured by SUMEC and sold under brands like YardForce and Herkules, and that upgrading one of these makes a large number of devices OpenMower-capable, but compatibility must be checked on the openmower.de getting-started page. A mower outside that family is not a supported target, whatever the software can do.

OpenMower against buying an RTK mower outright

The obvious alternative is a current RTK-guided mower from a commercial vendor, and the difference is not only price. A commercial RTK mower arrives assembled, calibrated, with a warranty and a support channel, and its mapping and obstacle handling are the vendor's problem. OpenMower gives you the same category of capability, map-based mowing without a perimeter wire, but you own the integration: the board, the firmware, the ROS configuration and the failure modes.

The second alternative is to keep the stock mower and its boundary wire. That is genuinely the right answer for a simple, single, rectangular lawn where the robot already works and the wire is already buried. Random-walk mowing is inefficient, but it is also maintenance-free in a way a self-built robot is not. The case for OpenMower is strongest when the lawn is irregular or split into several areas, when a wire cannot be laid, or when the mower body is already sitting in the shed and only its brain is the problem.

A third path is the Husqvarna-style ecosystem, which the related searches pair with OpenMower. Those machines are closed and their navigation is vendor-controlled, so the comparison is really about whether you want to modify hardware at all. OpenMower is the answer for people who do; it is not a drop-in firmware for someone else's robot.

Release cadence and what upgrading costs you

The releases tell a mixed story. v0.13.2 dates from 2023, the entry labelled Latest Firmware from 2025, and v1.4.0 from 2026-09-03, the same day as the most recent push to the default branch. The gap between v0.13.2 and v1.4.0 is more than three years, which is worth knowing if you are reading an old build log: instructions written against 0.13 may not match the current tree. The jump in major version also suggests the project does not promise a smooth upgrade path between them, and the README says nothing about migration or version pinning.

Upgrading is not a package manager operation. Because the code lives in submodules, moving to a newer state means updating the submodule pointers and rebuilding the relevant parts, and the firmware on the mainboard and the xESC controllers is a separate flash from the ROS side. A mismatch between firmware and software is a plausible failure mode, and the repository does not document a compatibility matrix between the two. Budget for that: an upgrade is a reflash and a re-test, not a pull and restart, and the place to ask about a specific combination is the Discord server the README links.

Editorial conclusion

OpenMower suits people who already own a compatible SUMEC-built mower, can solder and debug a custom mainboard, and are comfortable with Linux and ROS; the repository states the build needs intermediate electronics, Linux and mechanical skills. It is not for anyone who wants a mower they can unbox and run, since there is no assembled product, no support contract and the documentation warns that if you are not sure what you are doing you should not try it at home. Before buying parts, confirm your mower model against the compatibility page at openmower.de, read the System Architecture and Step by Step Guide pages, and check the LICENSE file in each submodule you plan to ship, because the licences differ between the ROS stack, the app, the OS image and the firmware.

Frequently asked questions

Official sources

1. ClemensElflein/OpenMower on GitHub
2. Issues
3. README
4. Releases