Looks that current firmware wont clear obstacles even those move away. Specially annoying is that is can see ghost obstacle and persist it to end of current task. Thing is even more worse because looks that navigation around obstacle wont work properly. Here is example video.
In video device is infinite loop of trying navigate around obstacle. It try drive out of area (and partially does it) and then it drive back and try again and again. It does this until battery runs out. And btw there is no obstacle at all. So basically this is report of 3 different bug or poorly implemented feature. 1) obstacles should not be permanent 2) pathing need optimization so that it wont drive out of area and can go from tight space. 3) if pathing solution is impossibe it should stop, evaluate is that obstacle still there and wait. Maybe after 5 minutes it can give up and send message to user that route is blocked.
I think I have seen similar behavior when it is near the edge of its route and it seems to need to travel just a tiny bit more to get where it wants to be to make the turn for the next line. In my case it was definitely persistent, but I honestly don’t remember if I intervened by pausing and driving it manually for a small bit, or what, but I do know it did not simply keep trying until battery died. It seems plausible that they implement some sort of cycle counter such that if it cycles maybe 5 times in roughly the same orientations, that it skips backwards or forwards by 1 or 2% of work plan. In my case, it was getting into the snow pile at the edge of the driveway which was too much for it handle with the plow blade, so it would back up, push forward, maybe slip a bit, and repeat. I didn’t really consider it a “flaw” at the time - just one of those situational times where you simply can’t program for every single circumstance Mother Nature puts in the way…
Disable car avoidance beta in safety settings and see if the issue persists.
yes I think that is workaround until it get fixed. But I report this mostly that dev team get information and can fix it in future.
Thanks for letting us know. Do you have a support ticket regarding this issue? If not, please submit one so that we can investigate further.
You can be 100% sure that I will not open a support ticket about this. The soul-suckers working in your customer service have certainly taught me to stay as far away from them as possible unless it’s absolutely necessary. I have better things to do with my life than waste it answering their stupid question-bingo, responding over and over again to the same irrelevant questions when they don’t even bother to read the answers. This will either be passed on to the dev team as general feedback, or it won’t and it will remain a bug in the firmware. In any case, communicating with your customer service would require being paid an hourly wage. Even then, I might manage to do it for a day or two before it would be time to go on burnout-related sick leave.
@Yarbo-Forum This does seem to be an issue. When I talk to tech support they ask the same questions multiple times. A lot of the time the answers are already in the notes on the ticket. It seems they just don’t bother to read them.
I agree. I’ve seen this and hear this a lot.
I agree as well. Frustrating when it is apparent that support isn’t reading the ticket history before sending an email.
I was thinking about a potential solution — with the optimistic assumption that messages from this forum might reach the dev team.
The most sensible way to handle vehicle and visual obstacle detection would be to base it on cumulative scoring. Judging from the shape of the obstacle areas, it seems that the system currently adds them as static-sized squares that form a unified area. Let’s call these squares “pixels” for the sake of this explanation.
Whenever an obstacle is detected, each corresponding pixel would receive a score of +1. Every time no obstacle is detected at that location, the score would decrease by -1. The minimum score would be capped at zero.
The software could then include either user-adjustable (preferably) or hard-coded threshold and persistence values.
The threshold value would determine how sensitively something is interpreted as an existing obstacle. A default value could be 5. In other words, if the score is above 5, the obstacle is considered present. If the score is below 5, it is ignored.
The persistence value would define the maximum score a pixel can reach. By default, this could be 10, placing the threshold in the middle of the range so that obstacles appear and disappear with equal weight. If persistence were set to, say, 20, the score could grow up to 20, meaning it would need to lose 15 points before the obstacle is removed. This would allow fine-tuning of how quickly and easily Yarbo concludes that an obstacle no longer exists.
Ideally, these parameters should be user-adjustable, since some environments may have many obstacles that frequently appear and disappear. In such cases, both persistence and threshold should be set low. On the other hand, in environments where it is absolutely critical to avoid colliding with obstacles under any circumstances, persistence could be set high and threshold low. In locations where a balance is desired — meaning objects shouldn’t be classified as obstacles too easily, but once classified they should remain obstacles for a long time (closest to the current solution) — persistence could be set high and threshold at a medium level.
I’m really sorry you’ve had that experience, and I completely understand how frustrating it feels to be asked the same questions multiple times — especially when you’ve already provided the information in the ticket notes.
We recognize that there is still room for improvement in our first-level support process. Your feedback is valid and important. I will pass this along to our customer service team so they can review and improve how tickets are handled, particularly in terms of carefully reading existing notes before responding.
When a behavior is repeated (bad or good) it reflects on management. If they don’t equip their personnel with tools, systems, and processes to be efficient in their time it speaks volumes about management’s care for both (or lack thereof).
Assocaites don’t want to frustrate customers, rather they are forced to repeat questions because of rigid processes or tools.
This is very very fixable without a large investment of time or money. There are good knowledge base systems and (re)writing processes only requires prioritization. Invest an hour or two up front and it pays back over countless customer interactions.
[Stepping off my soapbox]
p.s. I know I’m preaching to the choir 
here in the forum.
I like to think it’s because they are very junior and very busy. I’ve had some responses here on the forum myself where I was busy and didn’t read the full question(s) or see some of the indicators. Thankfully the forum has a bunch of really smart people here that help catch those things.
I’m sure if it was actually your job you would have. You don’t represent Yarbo.
I’m willing to bet quite a few people in this forum had first jobs in or related to tech support. The problem with tech support, in a lot of cases, is once you get really good you move on to better opportunities.
I had a similar experience with this latest heavy snowstorm. It was see a phantom object and spend 10+ minutes going back and forth trying to do something. Often it ended up reversing into the uncleared snow and then it would spend 10 minutes trying to free itself before I would go out and push it. I don’t remember this from the previous firmware.
Recommend opening a ticket with the times so they can pull the logs and see what the issue might be and hopefully train it to not do that again.
I think that at snow blowe you just cannot avoid phantom objects. And other hand some times there can be real temporary objects. So It wont help to try resove those cases one by one. Handling detected obstacles as permanent is just bad way to do it and no matter how many exception and glue patches they will do to that it will not work properly. There is reason that no other robot (lawnmowers, vacuums, diy projects) do it that way. And I am littile bit puzzled why yarbo even try go with own route with this because it is 100% proof recept for failure.