open-rmf / open-rmf/next_gen_prototype

What should traffic safety parameters look like?

Open
#3 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
10
Forks
9
Avg merge
3d 8h
Merged PRs (30d)
2

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by reviewing the proposed footprint levels and behavioral parameters, then clarify the intended representation and rules with maintainers. Done would be an agreed specification for the safety parameters and their required behavior.

Written by the indexing model from the issue text.

Assessment

Domain
robotics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.