Problem statement
Scheduled work plans or user initiated work plans fail to start when the rover has insufficient L2 count and shows GPS disconnected. The user must manually drive the rover to a location with good GPS signal before starting a plan to mitigate.
Background
The charging pad location works fine parking the rover and there are no navigation issues when operating or returning to charge. After parking/charging, the L2 count drops too low (5-9) while total satellite count is over 20 resulting in GPS disconnected condition. The signal will flip from disconnected to strong. Rarely is there a yellow state. The data center is mounted at a roof peak and doesn’t exhibit issues.
When L2 count is at least 9 (is sometimes as low as 7), GPS is Strong and the rover will leave the charging pad without requiring manual operation. L2 satellite count varies by time of day at the charging pad location (puts rear of rover and pad near 2 story building). The charging pad location is not able to move elsewhere.
Feature request
Create a feature that allows the user to define a pathway to navigate from the charging pad to a location with known good GPS signal when GPS signal is low or disconnected
The user defined pathway should drive the rover from the charger to a location with sufficient GPS L2 satellite count. This could be the path connected to the charger or one specific for satellite signal recovery.
The rover should use cameras and sensors to avoid obstacles and stop if anything is blocking the path
Yes, it uses GPS when it is off the dock and magnetic sensors when on the dock in combination with GPS.
VSLAM, VIO, Wheel Odometry, and the IMU should be able to make this happen. The lead engineer and co-founder just shared a video of using vision to dock inside a garage on the FB groups. They are actively working on this.
In the interim, it would be nice if you could just specify to pull straight forward off the dock X number of feet in 0.1 inch increments to stop and acquire signal and then have it start the plan.
I moved my charging station farther away from the house a few weeks back and it cleared my lack of GPS while charging and map drift.
I did see my first Map Drift since moving the charging station today.
Also odd today, Yarbo just suspended the work plan for no reason. I tried resuming and nothing. I “recorded” the issue and opened a ticket.
I did a Restart Yarbo System to resolve the issue.
Yarbo also set for quite a while “adjusting blades”. He was in the shade of a pine tree so I figured he needed a break.
I paused the work plan, and took a look at the blades. There were no blockages. I then raised the blades to 4 inches and dropped them to 1.2 and back to 4. They moved without issue.
I then resumed and Yarbo went on his merry way.
There is some weirdness happening I think .
And I don’t have the new firmware yet. I wonder if they have made some server side changes related to the new firmware that is causing some odd behavior with the older firmware units.
Maybe its changed some timing or something and we’re tripping on some edge cases.
map drift can happen when the GPS hasn’t fully woken from it’s slumber. Usually a reboot can clear this if it doesn’t clear on it’s own when it wakes up.
Thank you for sharing the detailed problem and suggestion.
As Bryan mentioned, Yarbo currently requires a valid GPS signal to undock and follow a pathway. The feature you proposed—allowing the rover to navigate to a known good GPS location even when the signal is weak or disconnected—would involve deeper integration of several other technologies such as VSLAM, VIO, and onboard sensor fusion.
We truly appreciate your input—it plays a valuable role in helping us improve the product.
Mine did this last evening – second time for me, first was the day after the FW update. I am going to add it to an existing ticket I have on “rover just stopped while mowing,” which Support has handed over to the developers (#95381).
Ken they are tracking a fix for an issue where all appears normal and it’s stopped.
But I’ve had an issue with lost GPS. If the rover drifts out of bounds because of this (on the app but not in real life), it’s suspended my plan. When I’ve found it like this and located my rover it’s sitting outside of the area. Talk about pucker factor and can’t smash smart vision button fast enough. Both times it’s been where it paused and completely within bounds. When GPS recovers, it centers and you can resume. Maybe this is what you both have seen too.
Both times mine was stopped in a normal mowing path physically and on the map – not out of boundary or in the woods. One’s under some canopy, but the rover has always been able to get through there no problem. The other spot is pretty open, rover’s been fine. And the rover’s gotten through worse canopy.
I also suspect it’s GPS-related, or the handling of faltering GPS, maybe an issue in (or the thing that calls) the routine that tells the rover to stop and ask to be moved to get better GPS.
Why? With this most recent “stop while working” I noted GPS as being just dandy – good numbers, green. After rebooting the rover, GPS went red, AdjustAngle -1, higher HeadingDop, whatever. The rover didn’t move, and this change was in the time it took to reboot. Hard power cycled the Data Center, still an issue. I had to move the rover to get GPS back. Great before the reboot, bad after, same spot? Is something lying to something, something not coordinating with something?
Yes, satellite movement could explain this very easily. Satellites/L2 went from 18/10 to 18/6 after the reboot, so, sure. But aren’t we seeing a number of users having to reboot the Data Center or reboot the rover kinda often due to Data Center / rover coordination of GPS? Could this “stop during work” be another symptom?
I assume you are on the new firmware @Ken. I’m still on the 3.8.18. Its the first time I’ve seen this in the 7 weeks-ish I’ve been mowing with Yarbo.
@ken.w.gregory - The new firmware is where mine showed up. I hear rumors that Yarbo has stopped rolling it out, but I have not seen it confirmed by Yarbo themselves (I’m a day behind in reading FB posts and don’t have an official e-mail about it).
Why it may happen with both of our FW versions: Yarbo Support told me they made changes on “the servers” to resolve my “Request failed, please check your network” issue, so although your Yarbo functions without the Internet, this implies your Yarbo has more interaction with the Mothership than one might expect. Perhaps a change that’d impact everyone (“the servers”) is what we’re seeing. The other possibility is we’re seeing some kind of latent bug with these “stopped while mowing” issues – a bug escape.
We do know that there are GPS issues that users are resolving with Data Center power cycling and/or rover rebooting. My theory is it’s GPS signal loss somewhere that’s not being handled correctly. Just postulating.
(BTW - even with changes on “the servers,” I’m still seeing the “Request failed” issues and have taken to deleting some things on my insane map, which is not helping.)
@Yarbo-Forum if this is the case some communications would be appreciated. Some of us are leaving Yarbo parked awaiting the firmware update. If the rollout is paused we can go back to mowing.
I worked in software development for decades. I know pausing a rollout is usually not a good thing. With that said, the expectation has been set that the rollout would be complete by the end of last week. (and or the week before) Either way I feel its time to update the user base of the status of the rollout.
Software development sometimes doesn’t go as planned. I understand that, but I’ve found its better to over communicate status when such things happen.
Doing so calibrates expectations and reduces the number of tickets being created for “I didn’t get the firmware update”
Mostly going to Previous Maps, although it sometimes works (and just did on my Android – twice in a row – three times! – wow! – I did delete some stuff of my map, so who knows)
Previous Maps seemed to always work on Bluestacks, not so much my Android phone (which is from, like, this year, Bryan, not 1927)
Seen trying to change Settings on an Area, at which point it messes up what’s in memory, so any changes to that Area you may confirm after that are not going to be right. This is a bad bug IMO, as it’s not saving what the user set, and there’s no error message.
Map calculation slowed, and I was always afraid it would fail, and, in fact, hitting Start on a Work Plan showed the swirly but didn’t do anything a few times, but there was no message. As you can hit the start button again and usually have it go, it “works enough” for me.
Seen when going to Diagnostics, although you can see the diagnostics changing behind the error, so it does go there
…when trying to do various activities around the App, Yarbo stating it’s my busy map (which is crazy AND insane) and they found at least one bugfix for it at least and updated the servers with it. I guess my map is a good test case - if they fix a bug for my stupidity, it’ll help everyone.
