Describe the bug
Navigation::GetRandomLocation builds its default filter from a single area
flag:
// LibCarla/source/carla/nav/Navigation.cpp:1074
filter2.setIncludeFlags(CARLA_TYPE_SIDEWALK);
filter2.setExcludeFlags(CARLA_TYPE_NONE);
while the walkers themselves navigate on three of the four. Crowd filter 0 —
the default every walker gets, since _probability_crossing is 0 unless
set_pedestrians_cross_factor raises it — includes CARLA_TYPE_WALKABLE but
then excludes road (lines 221-222):
_crowd->getEditableFilter(0)->setIncludeFlags(CARLA_TYPE_WALKABLE);
_crowd->getEditableFilter(0)->setExcludeFlags(CARLA_TYPE_ROAD);
so a default walker moves on SIDEWALK | CROSSWALK | GRASS. Only crossing
walkers use filter 1, which allows road.
So a navmesh built from an OpenDRIVE file with no type="sidewalk" lanes is
perfectly valid, has hundreds of tiles, and supports walkers happily once they
are placed — but cannot place any, because there is not one polygon the spawn
filter will accept. Not all OpenDRIVE files carry sidewalk lanes; one exported
from a lane-graph description (Epic's ZoneGraph, in our case) carries driving
lanes and crosswalk objects only.
The area comes from the usemtl name in the OBJ
(RecastBuilder/Source/MeshLoaderObj.cpp:218), and CarlaEpisode.cpp meshes
RoadMesh + CrosswalksMesh — so CARLA's own generated-world path would hit
this too for such a file.
Expected
Either fall back to CARLA_TYPE_WALKABLE when no sidewalk polygon can be
found, or log that the navmesh contains no sidewalk areas. As it stands the
call just returns None forever and there is nothing to go on.
Suggested fix
if (!TryRandomLocation(location, CARLA_TYPE_SIDEWALK)) {
// A navmesh with no sidewalk areas is valid - not every OpenDRIVE file has
// sidewalk lanes. Fall back to the areas the DEFAULT crowd filter accepts,
// which is filter 0's include set minus its exclude set - not
// CARLA_TYPE_WALKABLE, which would put spawn points on road polygons the
// walker's own filter then refuses to path from.
log_warning("no sidewalk polygons in the navmesh; "
"sampling sidewalk|crosswalk|grass instead");
return TryRandomLocation(location,
CARLA_TYPE_SIDEWALK | CARLA_TYPE_CROSSWALK | CARLA_TYPE_GRASS);
}
Environment
- CARLA
ue58-dev-carla @ de3f38e64, running Epic's City Sample
Describe the bug
Navigation::GetRandomLocationbuilds its default filter from a single areaflag:
while the walkers themselves navigate on three of the four. Crowd filter 0 —
the default every walker gets, since
_probability_crossingis 0 unlessset_pedestrians_cross_factorraises it — includesCARLA_TYPE_WALKABLEbutthen excludes road (lines 221-222):
so a default walker moves on SIDEWALK | CROSSWALK | GRASS. Only crossing
walkers use filter 1, which allows road.
So a navmesh built from an OpenDRIVE file with no
type="sidewalk"lanes isperfectly valid, has hundreds of tiles, and supports walkers happily once they
are placed — but cannot place any, because there is not one polygon the spawn
filter will accept. Not all OpenDRIVE files carry sidewalk lanes; one exported
from a lane-graph description (Epic's ZoneGraph, in our case) carries driving
lanes and crosswalk objects only.
The area comes from the
usemtlname in the OBJ(
RecastBuilder/Source/MeshLoaderObj.cpp:218), andCarlaEpisode.cppmeshesRoadMesh + CrosswalksMesh— so CARLA's own generated-world path would hitthis too for such a file.
Expected
Either fall back to
CARLA_TYPE_WALKABLEwhen no sidewalk polygon can befound, or log that the navmesh contains no sidewalk areas. As it stands the
call just returns
Noneforever and there is nothing to go on.Suggested fix
Environment
ue58-dev-carla@de3f38e64, running Epic's City Sample