The common definition of open source is that the source code and other digital artifacts can be used for commercial purposes. The non-commercial licensing makes this project not open source. A list of resources discussing the definition of "Open Source" is given below. The Open Source Initiative (OSI) has a list of approved licenses. The Creative Commons licenses that are libre/free/open are CC0, CC-BY and CC-BY-SA.

Please consider removing the non-commercial clause in the license to make this project open source.

If you decide to keep the non-commercial licensing, please consider renaming the project to something other than "OpenMower" as the term "Open" holds connotations of it being open source and causes confusion. Additionally, if you decide to keep the non-commercial license, please remove the "open source" project goal in the README.md file.

For projects that aren't libre/free/open source but still wish to make their source available, a good compromise I've found is to indicate that the project has "source available" rather than specifying it is "open source".

Open Source Initiative

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Wikipedia's entry on Open Source

Licenses which only permit non-commercial redistribution or modification of the source code for personal use only are generally not considered as open-source licenses.

At this point it would be nice to think about release + versioning, since it's not optimal right now.

Current State Currently, I'm just pushing updates and we're using the latest development state. This is fine for now, because I try to only push things that are working, but in the future it might be nice to have a "stable" release.

Goal Since the OpenMower is basically two components, the hardware and the software, it would be nice to have a versioning system which shows which hardware version works with which software version.

Also it would also be nice to provide a packaged bundle of hardware (BOM, Gerbers,...) and software (precompiled image).

Progress Vermut on my Discord is working on streamlining the KiCAD releases and jakub is working on streamlining software releases.

Currently the idea for hardware is to have a GitHub action which checks DRC, packs gerbers, generates iBOM, etc. This solves the problem of people just wanting to get Gerbers + BOM to order the PCBs without getting into KiCAD. This also prevents me from forgetting to generate the artifacts.

For the software the idea is to have a GitHub action to pack a docker image. This allows people to quickly get the software, they won't need to compile + it's easy to upgrade.

This issue is meant for discussion about where to go from here basically.

• fix(soundmodule): female socket instead of male headers
• fix(motorsensor): J10 was upside-down
• feat(pcb): rotate J10 and move lower, soundboard pin sockets

Is there a possibility to remove the custom PCB and use "standard components" e.g. pi cluster ?

This would enable more people in development.

If the magnetic offset of the WT901 is too large, the values will overflow or clip. This way the orientation in the open mower software will be nonsense. The solution is to move the WT901's offset register in such a way that the values are in a sensible area. We should probably detect the overflow somehow and move the offsets accordingly.

I updated the scripts, now it runs CI on every commit that does DRC/ERC failing due to ERC https://github.com/rfvermut/OpenMower/runs/7030384610?check_suite_focus=true

Release now includes a render of a board with git tag as version on a silkscreen: https://github.com/rfvermut/OpenMower/releases/tag/v0.9.10

also I added the script that regenerates GH pages with a navigator of all artifacts (except ibom, somehow it dislikes it) https://rfvermut.github.io/OpenMower

see commits for change list

Idea behind 3.81 terminal block is to allow reusing existing orange terminals from old PCB

Idea behild extra pin holes next to DC/DC is to connect wires to blue terminal w/o desoldering it.

We agreed to bump MINOR when PCB changes, and bump PATCH when software changes, so in order to have same PCB versions when software is upgraded we tag PCB with v1.2.x instead of v1.2.3, v1.2.4

Also GH workflow refactoring to reuse artifacts

Looks like this:

• https://github.com/rfvermut/OpenMower/releases/tag/v0.0.108
• https://github.com/rfvermut/OpenMower/actions/runs/2773901745

Fixes the issue when automatic KiCAD BOM (.csv) generator includes any parts that have something in Config field, but the rest of the generated files have DNFs (ibom, pick-and-place etc).

Hi fellow robot mower owners,

I was wondering if anyone has tried converting a Gardena mower with this project.

Some Gardena mowers have a slot for a smart module, and I am wondering if that could be a way into controlling it without replacing hardware.

Actually this is more of a question or a feature request. So is there a way to adjust blade height? In my yard there are places that I would like blade to be lower and places where it should not be as low or it might hit something Also this would be a great feature combined with other feature requests, while having different patterns in place one could make all kinds of nice patterns like on a football fields. Pic for reference

It's not obvious for a newcomer to click the "Wiki", so for ease of access, I propose including a link to the relevant Wiki section that guides those interested forward.

Problem Statement: Since the Mainboard of the Robotic Mower has been substituted the emergency Stop button functionality is assumed not to be working. This part is one of the most important safety measures beside the Gyroscope based deactivation of the mower, I propose to integrate a low-level emergency switch which deactivates the Motors.

Expected Behavior:

• If Emergency Button is pressed the Robot stops mowing instantly and requires manual reset
• The low Level Controller (PiCO or similar) requires an reinitialization routine from Raspberry in order to restart operation
• Saving the location and time of event on storage

Proposed approaches:

• Hardware based Kill-switch cutting the motor driver voltages
• Software based ISR listening on the Emergency Button Pin and actively deactivates motors