Yes. The unneeded Deadend zero turns are problematic. I’ve had to abandon them in couple areas to save my grass. This is for sure new behavior and a fix is urgently needed.
It treats every Deadend as an independent task and whatever is happening during the initialization of the Deadend process may be at fault.
I tried to Reduce Boundary to 0 for the first time yesterday and it didn’t seem to change the boundary gap. It had just cut my 2 perimeter laps when I ended the task, changed the setting, and restarted the task. It cut on nearly the identical path as when Reduce Boundary was set to 4 inches. Can anyone confirm this is working for them?
Thank you for your clarification and response. I appreciate your support.
I believe you, when you say that you changed nothing in yarbos turning algorithm.
But with the latest update something changed for the worse. There are multiple post (included mine) that noticed a different turning behavior.
The ignoring of 0" boundary reduction (and instead doing 4") is a good example of an issue that was reported by PPP, before the release to the public, but it was not fixed.
Well, I received some news from Yarbo Support today. Apparently a hot fix is in progress, specifically for the dead-end zero-point turn issue. How long it will take, who knows. Will it actually work, who knows. Will it introduce more bugs, probably. Not getting my hopes up, but at least some communication is taking place.
lol it would seem so. I would expect some productivity boost if they start using Claude Code. Get that context engineering just right, and we’ll have all the software updates we want
I was thinking the same thing. The new AI’s are exceptional at coding - even if it needs some human tweaking.
The one that baffles me is Yarbo running back and forth all over the yard to finish areas it was right next to earlier in the cut. It gives the appearance of lazy coding. It works, but is completely unrefined.
So sensor was reading 3 before rain
During the rain was reading 5-6
Minutes after the rain ended it was reading 38
15 minutes after the rain ended reading 82
All the time sitting on the dock fully charged.
Rain sensitivity setting are 20 to 1000.
How will Yarbo’s rain sensor configuration will ever work.
Rollover& Tilt Detection.
30 minutes before the Rain.
Rollover& Tilt Detection - ON
Rover reported a Rollover. Had to unplug battery and go through was feels like 5 minute boot up. As soon as I unplugged the battery the rover rolled forward over my foot. There was no other way to clear Rollover Error and take control of the Rover.
Lift Detection.
Lift Detection doesn’t work either.
I’m working on a bigger posting where the app showed the rover mowing and moving to the East, as I watched it make a turn to the West and head back for charging… app didn’t update for 3-4 minutes.
Lift detection can also mean drop detection. If the module drops over an edge you will get a lift detection error. Whatever mechanism they are using to detect this doesnt distinguish between a lift and a drop.
The rain sensor is, well, it kinda doesn’t work for me. It needs to be perfectly clean to register over about 200. It’s a sensor telling you how wet the rover is, not how wet the grass is. The Rain Detection setting doesn’t survive a reboot if you turn it off (not sure if they’ve fixed that).
I turned Rain Detection on and set the threshold to 50 on a sunny day, and the rover started the Work Plan but went right back to the charging station. My sensor bounces all over the place as it turns out, from 3 to 50 or so. I set it to 70, and it’s been OK. I figure what the heck, if I get some rain, it might trigger the 70 threshold and send the rover back to charge. But I’m not relying on it, no.
I’m not entirely sure, but I believe the rain sensor operates on electrical conductivity. Correct me if that’s not the case.
When this type of sensor comes into contact with water, its resistance decreases. These sensors can be effective, but achieving accurate readings typically requires more advanced logic.
First, they usually need to be individually baseline calibrated by determining their resistance when wet and when dry. Then, logic must be applied to interpret resistance trends over time — for instance, rising resistance may indicate the sensor is drying out, while falling resistance suggests increasing moisture, such as when it starts raining.
It doesn’t look like any intelligence is being applied. The sensor appears to be displaying some simple inverse product of the current resistance. This alone isn’t very useful.
I will note that my rain sensor seems to work very well on 2 units when it’s mowing. Sitting in the dock in a torrential down pour it doesn’t read much. Afterwards when the water pools on the sensor it reads pretty high. 200 threshold works well for me. It it may not for others. Interestingly enough, one sensor has ceramic coating and the other one doesn’t. The coated one reads double what the uncoated one does.
Thank you for sharing your observations. We’ve also noticed similar posts from other users. Currently, the only change we’ve made is to the turning behavior before reaching a dead end, where the system now automatically uses zero-turn mode.
We’ve passed along all your feedback regarding this change to our product team for further review. We truly appreciate your understanding and continued support!
Thank you for providing such detailed information. Could you please submit a support ticket regarding these three issues? It may require further investigation from our support team to resolve them properly.
Do you use the spiral route pattern? If so, this is a known issue—when the route pattern is set to Spiral, the Reduce Boundary setting may not function as intended.
We’re aware of the problem and will address it in future updates. We sincerely apologize for the inconvenience and appreciate your patience and understanding.