memory path toggle dont reverse back. am really happy with my new trimmer. only has line feed errors when i use it manually. works well with memory path but have experienced 2 times that yarbo will reverse back on the memory path. when you have to be in an area to complete the memory path then you would think that yarbo would continue on to the next task from there.
Can you elaborate? I’m not completely understanding.
so you can use the memory path as a dead end and reverse back or use the memory path as a pathway from A to B and so on to the next task
I don’t think this would be a good idea with the trimmer hanging off the back. You could maybe loop around and bring it back into the area?
Now I get it and agree, I want it driving forward whenever possible and looping back into the area.
Yes, I will too. But I see it starting to back up when it ends the memory path even though it is in an area and can continue forward.
The core does a lot of backing up and it’s all because of the path planning. Instead of just continuing forward in a smooth arc, it reverses and twists on the angles. Definitely a problem with the trimmer on the back if it is too close to something that it will run it into. I know sometimes it will back up the entire length of a memory path. That is a bug that sometimes triggers. That isn’t expected behavior and I don’t think reversing down a memory path as an option either is ideal. Too many things for the trimmer to potentially snag on in reverse and also the limit of its reach is very small on reverse. So it will potentially hit the limit angle quite frequently on reverse. For dead end type situations, start in an open area, go out of the area and complete the trimming task, then loop around and drive straight back into the open area to complete it. IMHO, it should always just continue moving forward. But Yarbo also has this weird quirk where if you start a plan in an area, it tends to reverse first for no apparent good reason. So this could also be what you are seeing. These idosyncracies ideally need to be fleshed out.
Hi there, thanks for sharing your feedback. I understand there is still room for improvement when it comes to the Memory Path behavior, especially regarding the reversing logic. We’ll continue following up on the community’s ideas and feedback around this topic with the team.
It’s not just Memory Path. It does all sorts of unneeded twitching and carrying on to start plans, aligns it’s start angle at 90 degrees then zero turns into the correct heading. It’s gotten much worse since the winter update.
Agreed.
okay thanks. happy. it’s a bug yarbo reversing on the memory path. yes there is room for improvement but am really happy with the trimmer attachment overall. 
I’ve had this issue. I have some big MPs and for some reason it is reversing back on them.
I had been noticing I was getting extremely long planned Estimated Times (like 10 hours on what should be 2 hours), and I’ve been getting the “Limit angle reached” error. I also occasionally noticed backing-up but I thought it had some other issue and then made a runtime decision to backup.
Well, I “caught it” reversing on big MPs for no reason, and it is planning these backups in the WP.
ALL of my MPs start and end in an area, and I have the WP meticulously setup with a clear sequence of MP-to-Area-to-MP etc. Even it if wasn’t meticulously setup, I have Paths between all these areas too, plus MPs between them and sometimes multiple, and I don’t have an DEs.
This is the type of issue that causes more issues. E.g. it decides it should back-up along long MPs as part of Planning. This makes the WP run longer than it should (in my case the estimate is like 5 TIMES longer). And then, because it is backing-up when it shouldn’t, it gets itself into trouble. I have at least two WPs that are unexecutable right now without errors, because the Yarbo plans back-ups that guarantee it will reverse the trimmer into something.
@Yarbo-Forum I’m pretty confused by this message below. What more ideas and feedback do you need on this? The Yarbo is backing-up on MPs (and it sounds like other scenarios) when it shouldn’t. You don’t need any more ideas or feedback on this, it is clearly an impactful bug. This probably doesn’t impact everyone but I can’t imagine there exists a feature higher priority than this bug (or at least reducing the prevalence and/or impact of the bug).
@Yarbo-Forum if fixing the bug is too daunting to do soon, a suggestion for a programming work-around would be before accepting a planned route (there must be some iterative logic in route planning and acceptance), you could look at the portion of time the Yarbo is spending backing-up and compare it to past successful executions and/or to some reasonableness number, etc. and reject or lower-the suitability calculation for those WPs with a high % of Planned Back-up Time. Or, it seems to me that a WP that determines it is going to run a MP in reverse must always automatically be wrong.
Don’t worry I sent them a video of it doing a path in reverse, it will be fixed asap now.
We are aware of the issue and truly appreciate you sharing your feedback with us.
I didn’t catch the irony the first time : )
B-Mod, have you gotten anything from Support? I’ve sent multiple examples; the latest info I have back is:
The current Path Memory feature is designed to follow the recorded route in one direction only. As a result, Yarbo will travel from the starting point to the endpoint instead of automatically selecting the shortest route.
I’d hope it has been “designed” as such, the problem is that isn’t what it is doing.
What I have observed, and am trying to work-around. I imagine stubby-dead-ends is a natural workout but I had been resisting, thinking the problem is so egregious that Yarbo would do some quick-fixing.
-
Yarbo Work Planning seems to route itself to/fro a MP by looking at “whichever part of it is closer”, or perhaps via a centroid or some other point-representation of the MP. FIX - only look at the START of an MP when Planning a route to the MP.
-
Yarbo Work Planning seems to think it’s okay to run a MP in ‘reverse’ from how it was recorded by the user. FIX a) any Planning that requires running a MP in reverse-from-original-recording should be invalidated / not considered. FIX b) just don’t EVER run a MP in reverse; if Yarbo finds itself doing this - stop and report an error.
-
Yarbo Work Planning uses MPs like normal Paths to get from one place to another even when the MP is not in the current Work Plan. I didn’t expect this…it isn’t completely crazy for Yarbo to do this, but if Yarbo Work Planning does this - it needs to only use MPs in the same direction recorded from. ADJUSTMENT - don’t use MPs for transportation - only run them when they are explicitly put into a Work Plan by a user.
-
There is at least one more thing going on I’m less certain about / I can’t quite put my finger on. Yarbo seems to want to “anchor” to a WA. So if it executes a MP that brings it out of that currently-favorite WA and ends in another WA, it seems to want to go back to the first WA before the next task - even if the next task is a MP that starts right there from the destination WA.
The team working on mine seem to have never heard of this issue before, yet @Yarbo-Forum says it is a known issue.
This past thursday am support ran my trimmer in different areas around my yard and found nothing, nothing. I can’t even believe it. But part of the reason is they never even ran the memory path that causes most of my issues. They ran the trimmer in to mowing areas that I have set up for trimmer use on the outer boundary about 50% of the outer boundary, but these are not memory paths.
The did mess with one memory path, not sure what they found.
They never did the memory path that causes me the most issues, and I gave them the name of the memory path in the ticket, as they asked for it.
I had yarbo do the wrong memory path in reverse, not even the one I chose for it to do.
Also had it mow and trim across my front yard on a path it picked to correctly start a memory plan, but it should not be mowing and trimming on the way to a memory path.
Now they want me to video record the screen as it is doing a reverse memory path, as I guess the logs and actuall video were not enough evidence. I am happy to do this, but is this really going to help, if it is already a known problem, how many videos do they need? This seems like something they could set up and prove in 10 minutes at their own facilities.
Thanks for the update,
I was afraid it would be something like that. Totally agree it should take like 10 minutes for them to recreate.
I’ll see what they say on my ticket tonight. If there is still evidence the Yarbo handlers aren’t getting it, tomorrow I’ll see if I can setup a new MP and I’ll video it from start to finish. I’m pretty sure I know enough to “design” an entire new, simple MP and WP where it will reverse the MP.
I haven’t yet had my Yarbo drive a memory path backwards, but then again, I’ve been deliberately trying to avoid the likelihood of it happening.
That said, I’ll do some experiments to see if I can get it to run one backwards and if I can find a pattern that is repeatable. If I can repeatedly make it run in reverse, I’ll record the steps and open a ticket to help with the diagnostic process.
All you need to do is run a memory plan anywhere near the end of a plan, and in my case it doesn’t even need to be that plan, it can be any plan and it will do the near one in reverse. It is obvious the software is bad.