Honest, last time I used mine was when I first got the yarbo, and did not have the snowblower yet to map.
Oh wow! Thank goodness you saw the nest and didn’t bump into it!!
rgloverli - thank you for trying.
Note in my case the issue happens for MPs that go from one WA to another WA. For my MPs that start and end in the same WA, as far as I know they always go the proper direction. So if the MPs you are trying start and end in the same WA, maybe it always does it properly.
The easiest way (for me) to recreate is to do a WP with a single WA-to-different-WA MP in it, where the end point of the MP (and probably the ending WA) is closer to the charging station than the start point of the MP. Run the WP, and Yarbo will go to the closer-WA and start the MP backwards from the endpoint - happens for me every time.
I know they took my logs from my core when I sent them the video of the screen with it doing the MP in reverse.
So I watched my video cameras from this morning. Support got it to do the plan in reverse. It looks like it kept stopping for them as is would back into my fence and send a notification They played with it for over 20 minutes. I hope they got good information.
That’s good to hear that support was able to replicate the issue. I hope they understood what they were observing.
I’ll try again to replicate on my side when I get some free time.
So I have an update, since the V3.14.0 my Yarbo hasn’t been doing MPs in reverse - I haven’t caught it,
and it just this morning finished a complicated, MP-and-Trimming-heavy WP from start to finish with no errors, problems, or intervention required ---- it has literally never been able to do that WP before without errors and/or human intervention!
So I don’t know if something in V3.14.0 changed/fixed something,
and/or maybe they changed something about how WorkPlanning works in the cloud,
and/or maybe it was another change they said they made to my Yarbo re another issue,
but in any case I’m keeping my fingers-crossed that this weird episode of MPs-in-reverse is behind me at least.
I can test it on my refurbished core, and my brand new core that I just opened up. I am pretty sure they did not fix it, as just a few days ago they were testing with my old core, like they had never seen this happen before.
Since all the sidewalks/dead ends/memory paths/pathways are all the same programming; once they fix “it”— they all will work.
I’m here for it.
Same text, different programs. It’ll need to be copied/pasted into each module’s codebase.
I didn’t realize there was another thread on the trimmer reversing MPs until just now,
since I have been posting on this one I’ll stay here.
I had setup a one-MP-only WP on Monday that I knew would have this problem - and it did have the problem as expected (on Monday). I used that to open yet another issue with support with lots of documentation, and because my old issue or two had gotten clouded with (stupid) arguing over if it was an issue / happening or not, much like B-Mod’s experience. At one point I was told a MP went a different direction than it (is supposed) to go - I had to send a video showing Yarbo executing it to show which way it went (when it worked / starting the Yarbo right in front of if). If you record an MP that never trims you can’t tell later in the App which way it goes - which is frustrating - but you would think Support would be able to tell which way the MP is supposed to go (if not…maybe therein has lain much of the problem).
That typed, to build on my update for the week and after V3.14.0 —
yesterday was the first time my two big-MP-trimming heavy Workplans ran since V3.14.0, and they both ran successfully for the first time ever. I couldn’t believe it. In one of the two I literally didn’t believe it and I couldn’t believe how quickly the WP finished - I had to go out and examine every bit it of the work to believe it.
It turns out if Yarbo just does the plan as specified instead of needlessly backing-up on MPs it can work successfully (and much faster).
So yesterday evening I ran my Monday test WP and it worked properly this time - Yarbo went to the ‘start’ of the MP like it was supposed and ran the MP the correct way only.
So it is much better for me; I hope it ‘sticks’. Perhaps there was something in V3.14.0 that accidentally fixed something or changed something enough to hide the issue for me. Or perhaps they finally dug-in and found some obvious error in how the work planning works in the cloud and they quietly changed it, more-or-less coincidently with V3.14.0. I will keep monitoring of course; I wish everyone the same ~luck soon.
BHA#@$@agdagfae$&realadf=ekdf@de!!!
Hotfix Firmware V3.14.1 ruined everything! Now my Yarbo inexplicably, insensibly, backing-up on a Memory Path again!
I’m watching it right now, and I checked and I have V3.14.1 on my machine. I hadn’t changed anything else. My Yarbo just error on a plan that worked last week after V3.14.0 and I hadn’t made any changes.
Don’t you just love the updates?
Where was your Yarbo in relation to the memory path when you started it?
It a good question. It originally started the whole Work Plan from the charging station.
But, then it had a “Limit Angle Reached” error, and the WP paused. This error usually happens for me because it is backing the trimmer into something, which usually happens because it is running a forward-only MP in reverse. But truth-be told I have no way of knowing what exactly it was doing at the time.
I did some minor maneuvering and restarted, and it immediately failed again. I did some slightly more aggressive maneuvering, but ensuring it was still on the MP it was doing, and restarted. This time it was able to succeed and resume the WP - but was going backwards. The WP completed successfully, and it appears everything was mowed and trimmed that was supposed to be.
I don’t know - was it going backward before the first error, thus causing the error (and it simply resumed going backwards once we got past it)? Or was it going forward and had a legitimate ‘stuff happens’ situation that caused the error, and it tried to get unstuck, and through the error and pausing-and-maneuvering-and-restarting (in the middle of a MP that starts-and-ends in different WAs) it decided it needed to go backwards on the MP, perhaps with some logic of trying to get back to some ~restore point?
Personally I don’t think it should ever reverse a MP. If in doubt - follow the MP in it is recorded direction, always and only. But obviously it doesn’t do that now, and it does make a difference re root cause, and what we can as users to try to work-around or avoid the situation that causes the error. I wish Yarbo was a bit more chatty as to what it was doing, it would be easier to tell.
Update - this latest incident of going-backwards was the only error I had on WP this morning, which is mostly trimming.
So it still MUCH BETTER than BEFORE V3.140, and I retract my blamery on V3.14.1
I guess the point does remain, despite what I thought last week at this time, there still seems to be occurrences for me where it will travel backwards on a forward-only Memory Path, traveling from the End-Point to the Start-Point of the MP.
AFAIK, this reversing down a MP issue has not been addressed yet. So best to ensure that the core doesn’t end a plan on top of another one and that the rear of the core isn’t closest to the entrance when you start one. Those are the only catalysts we believe to be true for this behavior. There are possibly others.
Or if the front is near the end of one, it will do a 180 and then proceed to do the plan in reverse starting from the end of the plan.
I think this is the main issue that needs to be addressed ASAP.
That said, I think the backwards driving thing happens when someone asks Yarbo to start a plan (of any type) while Yarbo is still sitting on top of a MP or sidewalk or deadend. Yarbo is “forced” by its code to follow the path until it gets to the end.
But follow it forward, not reverse! Where did they ever think this was ok to leave in the code?
Glad to see the latest update has improved your overall experience.
Regarding the Memory Path reversing issue, I’ve shared your feedback with our team again for further investigation.
Thank you for taking the time to share your experience and details with us. We’ll continue following up with the team and provide updates when we have more information.