Plausible Object Rotation

Plausible Object Rotation is a sanity check that detects abrupt or physically unrealistic changes in cuboid orientation between consecutive frames. Three rotation axes are monitored independently - yaw, pitch, and roll, each with a configurable per-class threshold. When any axis exceeds its limit, a visual cue is shown.

Yaw, pitch, and roll are evaluated independently. A cuboid can violate one axis threshold while remaining within bounds on the others - each axis generates its own violation entry in the track list.

---

Use Case

Rotational continuity is critical for object orientation models, heading prediction, and downstream tasks such as path planning. A single frame where a vehicle's yaw jumps by 90° - even if it is corrected in the next frame - introduces a spurious rotation event that can degrade model performance. These errors are subtle during fast annotation because the overall track appearance remains plausible when viewed at normal speed.

Plausible Object Rotation addresses this by:

• Monitoring per-axis (yaw, pitch, roll) angular change between every consecutive frame pair for all tracked cuboids

• Triggering a visual cue when any axis exceeds its configured class threshold

Common scenarios include:

• A vehicle cuboid whose heading is accidentally flipped by 180° in a single frame during fast annotation

• Keyframe interpolation creating an intermediate frame where the rotation overshoots the final orientation

• A pedestrian cuboid that rotates unrealistically due to interpolation across a frames gap where the object was occluded

---

Benefits

For Annotators

• Per-Axis Precision - Separate thresholds for yaw, pitch, and roll give annotators precise feedback about which aspect of the orientation is unrealistic.

• Track-Level Violation List - All rotation violations for a given track ID are grouped together, enabling efficient batch correction of an entire object's trajectory.

• Non-Blocking Warnings - Annotators can continue working and resolve violations at any point without being forced to fix issues before progressing.

---

Reference Rotation Axes Thresholds

The check monitors the change in each of the three Euler rotation angles between frame N and frame N+1. The table below describes each axis, its physical meaning, and the default threshold used as an iMerit starting recommendation.

Rotation Axis	Description	Typical Motion	Default Threshold	Applies To
Yaw	Rotation about vertical (Z) axis	Vehicle turning, pedestrian changing direction	20°	All classes
Pitch	Rotation about lateral (Y) axis	Vehicle climbing / descending a slope	5°	All classes
Roll	Rotation about longitudinal (X) axis	Vehicle tipping, banking on a curve	5°	All classes

Default values assume a typical LiDAR frame rate of approximately 10 Hz. For faster capture rates, thresholds should be proportionally reduced. For slower rates, they may be relaxed. All values are configurable in the project workflow.

---

Steps to Use

1

Configure Rotation Thresholds in the Project

• Navigate to your project's recipe settings (category schema).

• Locate and enable the Sanity Checks section.

• For each object class, configure the maximum permitted per-frame change for:

  • Yaw (rotation about the vertical axis)

  • Pitch (rotation about the lateral axis)

  • Roll (rotation about the longitudinal axis)

• Save and publish the recipe. Thresholds apply immediately to all active tasks on reload.

2

Annotate as Usual

• Open the task in the 3D Multi-Sensor Fusion Labeling Editor.

• Annotate and track objects using your standard cuboid guidelines.

• The system computes the per-axis angular change for every tracked cuboid between consecutive frames in real time.

3

Respond to the Visual Cue

• When any rotation axis exceeds its class threshold, a visual cue appears on and adjacent to all the affected cuboids on the timeline.

• The cue indicates which axis is in violation (yaw / pitch / roll) and the frames where the violation was detected.

• Determine whether the orientation was set incorrectly (correct the cuboid heading) or whether the object is in an exceptional state.

• The cue clears automatically once all axes are within the permitted range.

4

Complete the Task

• Violations are non-blocking - you may submit the task with active rotation warnings.

• Unresolved violations remain visible to QA reviewers, providing context for improbably object rotation.

---

Best Practices

• Treat Yaw and Pitch/Roll Separately - Yaw changes are expected and frequent (turning objects); pitch and roll changes are rare and usually indicate errors. Set yaw thresholds significantly higher than pitch and roll.

• Define Exception States Up Front - Identify all object states in the dataset that legitimately involve large rotation changes before annotation begins, and add them to the ontology. Retroactive additions require re-review of completed tasks.

• Use the Violation List Before Submission - Encourage annotators to review the full rotation violation list at the end of each sequence rather than responding to individual cues mid-annotation, which is more disruptive.

• Cross-Reference with Motion Violations - A frame that has both a motion violation and a rotation violation is very likely to be a misplaced cuboid. Prioritise these frames during correction.

• Account for Occluded Frames - Objects that are occluded for several frames and then reappear may have large apparent rotation changes due to interpolation gaps. Consider using shorter interpolation spans or manual keyframes across occlusion boundaries.

• Document Threshold Rationale - Record why each threshold value was chosen in the project guidelines, including the frame rate assumption and the physical rotation rate it corresponds to. This helps future projects reuse calibrated values.