My Yarbo needlessly strands itself by determining it is out of bounds and suspending the plan when GPS signal is poor.
It should only be allowed to make the determination it is out of bounds if it has a reliable GPS signal. If the signal is poor it should just wait for a better signal.
I’ve seen the “bug” he’s describing. Basically poor GPS and it shifts its location in realtime on the map (which is impossible for it to move so quickly and it should know this) and then suspends the plan. Instead it should pause and wait for green GPS before actually suspending the plan if it is truly out of bounds. It should also not untether itself from its previously known good location so easily. This is how when mapping you get crooked lines when you were driving straight but encountered bad GPS and it shifted your location in the process of that.
I’ve never seen that one.
This. There’s no need to immediately suspend the plan, nor is there any reason for the robot to aimlessly drive about, unsure where it is.
When it notices there is a GPS accuracy issue, I would prefer it to pause for a moment, waiting for the accuracy to recover. If the accuracy does not recover, I think the robot could optionally back up a bit to assist in GPS recovery (assuming it remembers where it has been).
The ‘back up’ feature should be optional, because it would be leveraging PPVS.
If all else fails, send a notification to the app so the user can try and manually drive it around until it recovers positioning.
I like everything but the back up part. If it had just completed a turnaround at the boundary or a NGZ… well, we all know what comes next.
I feel like Yarbo should be smart enough to backtrack what it has just done. So basically rewind its actions for a couple of feet. Not randomly drive backwards. But perform a reverse of what it had just finished doing.
Your “should” made me laugh…
I thought about being even more sarcastic, but decided to be nice. 
Thanks for sharing this suggestion.
I can understand the reasoning behind it. I’ll continue to keep an eye on the community’s interest in this feature request, and if more users express similar feedback, I’ll be happy to pass it along to our product team for consideration.
We appreciate you taking the time to share your thoughts and ideas with us.
The challenge with that is track slop, where both motors are turning but one track has a half turn of gear lash and the other track engages immediately. PPVS will think the core is moving directly ahead/back, when it actually is zero-turning while the slop track takes up the lash. Then it physically moves in whatever direction that resulted in, while PPVS thinks the core is somewhere else.
