I have an area across the street from the main property that I’d like to mow but I don’t want it automatically crossing the street without me. What can I do?
I tried manually driving it over into the strip, but no matter where I drove it said I was 1.5m outside the area even though it was in the exact middle of the 10’+ strip.
See the Support & Solutions summary for the “gate” functionality. I wonder if that includes getting to and pausing at a gate and sending a notification – could be the same for crossing a road, same idea.
This should work if you’re in the area. Seems like a bug. Did you try a restart?
I have a similar setup with a road crossing. It mows it without issue, so yours should be possible. The only warning I get is that it cannot automatically return to the dock.
There’s really no (positional) reason this task should not run. Just for the heck of it, see what clicking “Preview” does, to see what the core thinks it should be doing.
As an aside, once you get it running? See if it is practical to clean up this corner, to avoid making a mud pit. Some of that might be better served with a DeadEnd or two.
That corner is actually the issue. Edit your map and take that out. There’s a path planning bug for when maps have a small or overlapping section like when you backed up when mapping. Setting boundary offset to zero seems to highlight this issue. You could also try setting the boundary offset back to the default of 4 and it may run the plan without remapping.
I squared off that corner, and I changed the edge back to 4" and it worked as expected.
Now onto figuring out that gate option!
Thanks guys!!
Does it work with zero now that you’ve squared it off?
I’ll try 0" in the morning, I ran out of time to test this evening.
I couldn’t find anything about a “gate option” in Support & Solutions. I did find a suggestion for it though. Sounds like it might be a later version thing.
For the gate thing, my solution is based on manually kicking off the task for that area.
I know when I’ll start the job, so I’ll be there to escort it.
I don’t know when it’ll end, so I need it to wait.
I made a small area on the off-side of the street, and connected it with a pathway to an area on mine. The off-side area does not connect to any work areas on that side. I have a dedicated task to run that pathway to that area.
Come time to escort, start that task and it’ll leave the dock and head across the road. When it reaches that area, stop the task.
Manually drive it a few feet into the first workarea for that side, then kick off the task that mows them all.
For me, the last step of that task is a dead-end near the street-cross area. When the task is complete, the core will park itself, unable to go anywhere.
When I’m available to escort it back, just drive it to that crossing-area and hit the recharge button.
It’s not perfect, by any means. But since I can control when I send it, but not when it completes, this works for me.
Hope it was helpful.
Note that I do NOT know what happens if that crossing area overlaps a working area, and the core is in that overlap when I hit the recharge button. I expect any behavior like that will change in the future, so I have a deliberate air-gap between them. Same holds true for the crossing-area to be completely within the work-area.
I’m tempted to try those out just to see what happens, now. But again, one firmware change and it’d be a disaster. Regardless of how it works, I’d avoid it for real-life
.
So, quick update using a neighbor’s driveway.
For firmware 3.8.18,
Created a “crossing area” joined by pathway to a dock-connected area. Yarbo can traverse directly to it, and return to the dock from it. That’s basically the road-crossing part, but none of the area is in the road. It’s just a place for the pathway (which IS across the road) to go to.
Created “working area” that overlaps the crossing-area. Driving the core to that overlap allows me to start a task for that working area.
When the task is complete, if it leaves the core in that overlap (just below the green dot), and the solver does not find a path back to the dock.
Driving the core a short distance, still within the overlap, and hitting the recharge button also fails to find a path back to the dock. Probably because the unconnected “working area”, being on top of the Z stack, is the first (and only) area it considers. It does not consider the lower “crossing area” which is connected.
After driving the core a short distance to a non-overlapped region of the crossing area, hitting the recharge button works as expected.
So, there we go!
And with that said, absolutely do not do it that way.
I fully expect that the order the areas were drawn in will dictate how that solver can path things around. Drawing the work-area first, I expect the solver WOULD consider the crossing-area first, and it would cross the road.
I also fully expect that if we game this overlap behavior to prevent the core from crossing a road, you’ll have a flat Yarbo about an hour after the next firmware update.
If the path solver starts looking at all the areas in an overlap when trying to get somewhere, this stops behaving like a gate, “in a flash”.
I’d keep an airgap between the working area and the crossing area, and use that gap to control the return trip to the dock.
Yes, definitely do not count on overlap glitches to solve for this (or any glitches for that matter). I believe they are looking into the gate functionality. My assumption is it might be done with waypoints. It may take some time though as I believe waypoints will be a SAM only release initially if I remember correctly.
I finally was able test it, and setting it to 0" gave me the same error as before. I might try remapping that area, instead of relying on the edit.
Let us know how it goes!
