Skip to content

What should traffic safety parameters look like? #3

@mxgrey

Description

@mxgrey

There are many different approaches to parameterizing safety metrics, especially as it pertains to how robot traffic should behave.

Footprint

A straightforward way to account for robot safety is to declare a "footprint" for each robot, i.e. a local area of space that a robot occupies. However there are many ways to represent a robot footprint:

  • Circle
    • Pro: Extremely efficient to use for collision checking
    • Con: Does not account for longitudinal vs lateral differences in robot shape
  • Rectangle
    • Pro: Can somewhat account for longitudinal vs lateral differences
    • Con: Still might not represent the robot shape accurately, e.g. if corners are rounded or some parts stick out
  • Convex Polygon
    • Pro: Accounts for more kinds of shapes than a rectangle while still being reasonable to use for collision checking
    • Con: Cannot account for protruding parts without overestimating shape
  • Polygon
    • Pro: Can account for essentially any footprint
    • Con: The most expensive to compute collisions for. Sample-based collision detection is prone to clipping. Convex decomposition is needed for continuous collision detection.

Considering all these trade-offs, there does not seem to be an obvious choice of which footprint representation to use in all cases. Therefore we might consider the following rules:

  • Vendors can provide up to any level of detail, but must provide all levels of detail beneath their highest.
  • Planners can use up to whichever level of detail suits their needs but must at least be able to work with a circle.

Note that the circle is the lowest "level of detail" while the polygon is the highest. For all levels of detail, vendors are expected to provide a geometry that gives an outer bound for the actual shape of the robot.

Behavioral Parameters

Footprint data is useful for motion planning in extremely close proximity to obstacles and other agents, but most often real-world deployments will want buffer space between robots to ensure some amount of slack to account for sudden stops or path changes.

For this I would suggest a set of "behavioral" parameters that aren't necessarily related to a robot's physical characteristics but rather describe what kind of constraints should be applied to the relative robot motions:

  • Follow distance: Minimum distance that should be kept from another robot that is moving in front of this one
  • Pass distance: Smallest lateral distance needed to safely pass another robot
  • Rotation distance: Smallest distance needed to safely rotate

We generally expect the pass distance to be smaller than the follow distance to allow robots to pass each other in narrow corridors.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions