The mower wouldn’t return to base because it kept trying to “navigate around an obstacle”, on perfectly flat ground with nothing within ten feet. Right at the start of a pathway that has worked several times before, but it’s only a couple of weeks old. I tried turning off vision but it had the same issue. No obstacle showed on the app.
M1 mower, or Pro mower?
Do you have Obstacle Avoidance enabled for the Pathway?
Do you have Boundary Obstacle detection enabled for the Area?
Pathway offset could also be sending it into an obstacle or closer to a perceived obstacle. Turning off ultrasonics as well (if pro mower) could help.
Pro.
I’ll try turning off the ultra sonics but there’s no obstacle even remotely close. 25ft maybe
Hmm. Boundary Obstacle detection hadn’t occurred to me, but I need that for mowing the area unless I want to lose an antenna in a hedge.
What made me consider it is how shallow the Pathway is into area. If turning off Boundary detection fixes the issue, making the pathway extend into the area a couple more feet might be the permanent solution.
Now it won’t calculate a path from anywhere back to the docking station. The error message about “please ensure the map is built according to the guide” has to be one of the worst choices ever, for anything. If something is wrong with the map, add that to the message. Better yet, mention it when the map is being built or don’t allow the item causing the error to be saved.
Have you disabled pathway offset?
What did you change when new error occurred?
Hi there,
Have you tried checking the Pathway Offset feature? If it’s enabled, you could try toggling it to see if the issue persists.
It wasn’t enabled. I have turned it on to see if that helps. I assume you mean it’s more likely to cause the issue though.
In the area you split. Did you add a Pathway between the new and old?
Maybe share another screen shot of your map.
I did add a pathway between the new and old for that section. i have pathways joining the areas, then one long pathway back to the docking station near each end. At one spot the pathways overlap.
The maddening thing is knowing that “something” is wrong with how I’ve created the maps, but not what. It’s 9 hours of mowing area done in a busy park.
I’m going to run it through “claude”
Can you post your map?
| # | Severity | Element | Name | Issue |
|---|---|---|---|---|
| 1 | error | area 50 | play area to 34th ave | Working area polygon self-intersects; boundary must be a simple closed ring. |
| 2 | error | elec_fence 49 | Geo-fence 1 | Element ref origin is zero/degenerate (lat=0.0, lon=0.0); local meters cannot be georeferenced. |
| 3 | problem | area 142 | East of hedge | Working area has 3 connected pathways ([164, 169, 206]); Yarbo allows up to two per area. |
| 4 | problem | area 145 | North fence by play area | Working area has 3 connected pathways ([151, 169, 186]); Yarbo allows up to two per area. |
| 5 | problem | area 50 | play area to 34th ave | Working area has 3 connected pathways ([64, 71, 164]); Yarbo allows up to two per area. |
| 6 | problem | area 199 | Area 2 | Working area boundary is wound opposite the calibrated CCW direction; Yarbo wants Area boundaries counter-clockwise. |
| 7 | problem | nogozone 112 | No-go Zone 4 | No-go zone has area_id == -1 yet sits inside area 55; no-go zones should be bound to their working area. |
| 8 | problem | nogozone 116 | No-go Zone 8 | No-go zone has area_id == -1 yet sits inside area 199; no-go zones should be bound to their working area. |
| 9 | problem | nogozone 117 | No-go Zone 9 | No-go zone has area_id == -1 yet sits inside area 199; no-go zones should be bound to their working area. |
| 10 | problem | nogozone 118 | No-go Zone 10 | No-go zone has area_id == -1 yet sits inside area 199; no-go zones should be bound to their working area. |
| 11 | problem | nogozone 120 | No-go Zone 12 | No-go zone has area_id == -1 yet sits inside area 199; no-go zones should be bound to their working area. |
| 12 | problem | nogozone 150 | No-go Zone 15 | No-go zone has area_id == -1 yet sits inside area 145; no-go zones should be bound to their working area. |
| 13 | problem | nogozone 111 | No-go Zone 3 | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 14 | problem | nogozone 113 | No-go Zone 5 | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 15 | problem | nogozone 114 | No-go Zone 6 | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 16 | problem | nogozone 116 | No-go Zone 8 | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 17 | problem | nogozone 118 | No-go Zone 10 | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 18 | problem | nogozone 119 | No-go Zone 11 | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 19 | problem | nogozone 150 | No-go Zone 15 | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 20 | problem | nogozone 59 | black rubber | No-go zone boundary is wound opposite the calibrated CW direction; Yarbo wants No-go Zone boundaries clockwise (opposite of areas). |
| 21 | problem | area 142 | East of hedge | Snow-module area has push_snow_dir == 9999.0 and no snowPiles/trimming_edges; snow-throwing direction is unset. |
| 22 | inefficiency | area 55 | playground | Working area has 1 duplicate/zero-length consecutive vertex pair(s) (< 0.01 m). |
| 23 | inefficiency | area 142 | East of hedge | Working area has 3 sharp spike/sliver vertex/vertices (angle < 5.0 deg or edge < 0.1 m); avoid jagged geometry. |
| 24 | inefficiency | area 199 | Area 2 | Working area has 16 sharp spike/sliver vertex/vertices (angle < 5.0 deg or edge < 0.1 m); avoid jagged geometry. |
| 25 | inefficiency | area 50 | play area to 34th ave | Working area has 2 sharp spike/sliver vertex/vertices (angle < 5.0 deg or edge < 0.1 m); avoid jagged geometry. |
| 26 | inefficiency | area 55 | playground | Working area has 16 sharp spike/sliver vertex/vertices (angle < 5.0 deg or edge < 0.1 m); avoid jagged geometry. |
| 27 | inefficiency | pathway 151 | Pathway 1 | Pathway is 120.7 m long (> 50.0 m); long pathways risk navigation drift, keep them short and chained. |
| 28 | inefficiency | pathway 64 | clubhouse to hedge | Pathway is 70.0 m long (> 50.0 m); long pathways risk navigation drift, keep them short and chained. |
Where is all that data from? I was expecting a screen shot of the current map.
It’s from Claude comparing the map data to the documentation. The 3 connected pathways is my guess for the problem, but I might fix anything I can on the list.
I doubt they’re all correct, but the App should be returning something similar.