open-rmf / open-rmf/next_gen_prototype
What should traffic safety parameters look like?
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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