Requiring a specific path to move between areas is ideal for some circumstances, but is problematic for others. Consider this result, just a week or two into the mowing season -
A suggested navigation enhancement for all attachment types (M1 being highest priority, SAM, B1, naked core being medium, S1 would be low priority.) - “Navigable Perimeter”.
When Yarbo is navigating from one area to another, the user is presently required to make at least one specific pathway to join the two areas.
The S1 has a UI feature where the user can indicate the direction to aim the snow chute. The user does this by highlighting portions of a perimeter.
Add a similar feature to indicate navigation between overlapped areas, where the user can indicate that one or more sections of an area’s perimeter are navigable, e.g. valid entry-points into that area.
- When Yarbo is in one area, pathing its way to a second area, Yarbo will consider itself to be in that second area if it crosses into that area along one of those perimeter sections.
From a user’s perspective, the creation of a navigable section would be EXACTLY the same as how the user indicates the S1’s throw-direction on a perimeter. User will drag and highlight one or more sections of an area’s perimeter to indicate it is available for pathing INTO that area.
These selections enable pathing one-way, INTO an area, only. User is expected to make one or more selections for each area, and these selections are expected to overlap any area that the Yarbo might be coming from. The pathing solver, obviously would only be able to solve for selections that have overlap.
In the event that a navigable section is within the overlap of several areas, all overlapped areas would be allowed to utilize it for pathing across that perimeter. Any area that overlaps a navigable section of a perimeter can use it for navigating into that perimeter’s area.
Navigable sections that are not in an overlap would be legal for the user to create, but would simply never be considered by the pathing solver.
When solving the path from one area to another, the solver would create the shortest route as it presently does, but would now prefer navigable perimeters over pathways.
The present implementation of the solver will cross an area, heading toward a selected pathway. In the new implementation, when a navigable perimeter is chosen by the solver, the solver will pick a random location along that navigable section within the overlap as the crossing point. This randomization would help reduce or prevent the mud-tracking that is currently present with the pathway solutions. Additionally, Yarbo currently needs to line up exactly with the start-point of a pathway, which destroys the grass. The new implementation with navigable perimeters would not care about specific orientation; the Yarbo would simply head for a random point on the navigable section and cross it at whatever angle it reaches it at, and THEN head toward the next waypoint. Pathways are strict; Navigable perimeters would be “whatever happens”.
An intended side effect of the one-way nature of navigable perimeters is that a user can specify a return path from an area that is vastly different from the pathway to an area.
In this mockup, navigable sections are indicated in green. User dragged their finger over those perimeter sections while configuring them, just as the S1 throwing directions are selected.
The green section at A shows B’s perimeter being navigable from ANY area that overlaps that perimeter section. When traversing from area A to B, the pathing solver would pick a random location on that green section of area B’s perimeter and use that as a crossing point. Once crossed, the solver would consider itself in area B. Note that in this example, that green section would not be used to traverse back into A, since that section belongs to the B perimeter.
A valid return path would be that green section of A’s perimeter, just under the no-go zone.
The uppermost navigable section of C indicates a deliberate one-way entry into an area. C is a steep sloped area, with the top-left being the highest point. A user might want Yarbo to enter at the top of that slope to navigate downward, but never try to navigate up. Therefore, Area B’s perimeter is selected elsewhere.
The remainder of this sample map shows what would be more typical, where the user would select both perimeters along an overlapped section. Crossing points between areas would be sufficiently randomized that track-damage would be minimized.
Do note that this feature would dovetail nicely with the “only travel along the perimeter” option that others have requested.
EDIT: This navigation method would also allow Yarbo to fully utilize ALL existing obstacle detection and collision avoidance that is available, as the Yarbo would not be trapped on a strictly enforced pathway.
I apologize in advance if clarifications are needed. Please do not hesitate to ask, if so.
Cheers