Please consider extending the “No Vision Zone” feature into a more generic “Settings Override Zone” (SOZ). This generalization of the Zone will alleviate or resolve several pending challenges by allowing zone-specific solutions within or between areas.
The intent would be, just as the current No-Vision-Zone does, for selected settings to preempt the current work-plan when the Yarbo is in that zone.
I am unsure how the current software determines the entry or exit of the core from a No-Vision-Zone. The existing solution can be left as-is, but for the sake of the user training, I’d recommend that zone entry/exit be based on the centroid of the core, between the two GPS antennae. That will allow a user to predict behavior regardless of any module that is attached. That is the single reason for that recommendation. If your experience says that a different strategy is better, do that strategy instead.
When creating / editing a SOZ, a list of of settings would be presented to the user. User would be able to select (enable or disable) which settings would be overridden. SOZ Settings that the user did not enable would be ignored.
When creating or editing a SOZ, the user would not be required to enable any setting overrides. A user would be allowed to create or edit a SOZ into a state where no settings are enabled.
When a setting override has been enabled, the user will be able to specify a value for that setting.
When a a user disables a setting override, the override value they’d specified is preserved, even though it will be ignored. When the user later enables that setting override, that override value will remain populated in the value field.
Exactly in the way that a No-Go-Zone can be turned ON and OFF, an SOZ can be turned ON and OFF. When OFF, the zone is completely ignored.
User should be able to rename an SOZ.
When and where multiple SOZs overlap, ALL SOZs should be processed, in the order of oldest to newest. Where multiple SOZs specify conflicting Setting Overrides, the more recent SOZ should win. Basically, follow the Z order.
Many bonus points would be awarded if the ability for a user to change that Z order of objects is created. But that can wait.
If the existing No-Vision-Zones are module-specific (Do NVZs drawn with the M1 get hidden/disabled when the M1 is removed?), then SOZs should be as well. When a module is changed, SOZs would behave as the existing No-Vision-Zones do.
Core settings that should be available for override in a SOZ include
- Moving Speed
- Module Clearance
- Turning Mode
- Obstacle Avoidance Mode (replaces No-Vision. All modes should be available for selection, including Custom if possible.)
- Rollover and Tilt Detection
- Lift Detection
- Speaker Volume
- And a fun one for you - RECHARGE BATTERY LEVEL.
All of these settings are global to the Core. At a later date, perhaps consider module-specific settings as well (mowing height, auger speed, etc). But that can wait. The ones above are all a quick win, and would resolve or mitigate a bunch of suggested changes.
Simple use cases:
- User’s workarea is mostly flat, so zero-turn and u-turns work great for almost the entire area. But there’s one hillside that needs smart-turns to avoid getting stuck.
- The same use-case as the NVZ, but for every avoidance mode. High-sensitivity in some of it, low for the area default, and gentle-touch in others.
- An area that has both thin and thick grass areas would benefit from changing the default moving speed.
- A mostly flat area that includes a steep hillside would benefit from being forced into slow movement speed on that slope, but moderate or fast movement speeds on the flats.
- It rained this morning, so we can turn ON a SOZ to resolve “mud” problems that do not happen when the ground is dry. We can turn the SOZ back OFF once the ground dries out.
Recharge Battery Level use case -
- I’ll never use this, but some users wish that the core will not trigger a 20% recharge cycle while there is 1% of the area remaining. This Override would provide the ability to draw a small zone where the battery could fall down to 15%, or some other value. An example zone would be small a corner where jobs normally end. And to clarify, if the core leaves that zone for any reason below 20%, the global (20%) recharge would immediately be triggered.
- More importantly, some of us are hoping to use Yarbo to some day mow a trail system. A Recharge Battery Level override could be used as a tripwire at the start of that trail system to enforce a minimum charge level before the core can start that section. If we know the core uses 40% of its battery on this trail, we can place a small SOZ at the beginning of the trail with Recharge Level at 60%. If the core is below that threshold, crossing this SOZ would act as a gate to force a recharge before attempting the trail system, preventing issues should the core start a recharge (and try to turn around) at a random location in that trail system.
- Such “tripwire” zones could be placed within a trail system, or on pathways between areas, again to control WHERE the turn-around would take place. A golf course might use this, maybe, to ensure something isn’t half-mowed while a recharge cycle takes place.
- Note that when a recharge is triggered by such a zone override, the recharge is NOT aborted when the core leaves that zone, or enters another zone with a different recharge threshold. When told to dock and recharge, it does so.
You’ll have this done by Tuesday, right? 
Cheers