PointCloud2 for Robotics AI: Point Fields, Row Strides and Input Bytes

Read the layout before counting model inputs

A robotics or perception buyer may receive a point cloud as a sensor message, a stored message sequence or an extracted model input. Those delivery stages need not have the same representation. Calling all of them XYZ data leaves open which values and bytes cross the agreed boundary.

The ROS2 common_interfaces Jazzy definition describes PointCloud2 as a binary data blob with its layout supplied by the fields array. It provides height and width, a per-point byte length point_step, a per-row byte length row_step and a data extent of row_step × height. An unordered cloud uses height = 1; an organized cloud can retain a two-dimensional structure. [R1]

These declarations describe an input representation. They do not establish a sensor's measured range, spatial accuracy, point density in the environment or model quality. The decision here is whether the proposed consumer and its data-volume account match the delivered representation.

References: [R1]

Field widths do not necessarily fill the point record

PointField describes a field name, its byte offset within the point structure, a datatype identifier and an element count. The Jazzy definition includes FLOAT32 and UINT16 among its types. A field's count is the number of elements in that field, not the number of point records in the cloud. [R2]

A layout can place selected values at known offsets while leaving unused bytes between them or at the end of the point record. Adding the selected field widths therefore answers a different question from reading point_step. Likewise, a familiar name such as intensity does not define a physical calibration or unit. The producer's applicable data contract must explain that meaning.

Before treating an input as a dense XYZ matrix, establish which fields the consumer retains, their representations and whether a conversion occurs. A later tensor can omit attributes or padding; its byte count cannot be substituted for the earlier delivered payload without identifying that transformation.

References: [R2]

PC-33: six points occupy 112 delivered data bytes

PC-33 is an original fictional layout, not a sensor capture or a ROS decoder run. Stipulate height = 2, width = 3, point_step = 16 and row_step = 56. Each point has the four nonoverlapping fields below, each with count = 1. The example declares little-endian representation; it supplies no actual encoded sample values.

The three 32-bit coordinates use 3 × 4 = 12 bytes per point, and the 16-bit intensity field adds two. The selected values therefore occupy 14 bytes of each 16-byte point record, leaving two point-padding bytes. Each row contains three such records: 3 × 16 = 48 bytes, followed by eight additional row-padding bytes.

Across two rows, the selected fields occupy 6 × 14 = 84 bytes. Point padding contributes 6 × 2 = 12 bytes; row padding contributes 2 × 8 = 16. The complete data blob is 84 + 12 + 16 = 112 bytes, matching row_step × height = 56 × 2. None of these figures is a network packet size or a GPU-memory measurement.

An address error can survive a correct point count

Use zero-based row and column labels in PC-33. A field starts at row × row_step + column × point_step + field_offset, relative to the beginning of data. This is address arithmetic for the stipulated layout, not an ingestion implementation.

At row 1, column 2, z starts at 1 × 56 + 2 × 16 + 8 = byte 96 and occupies bytes 96–99. The point record starts at 88 and ends at 103; the row's trailing padding occupies 104–111.

A consumer that assumes row_step equals width × point_step would use 48 instead of 56. It would place that z field at 88, eight bytes before its actual position. Both descriptions still contain two rows and three columns. A correct six-point count cannot reveal or repair that addressing mistake.

A second mistake would be to replace point_step = 16 with the 14-byte sum of selected fields. That discards a different padding boundary. Point padding and row padding must be distinguished before a buyer can assess whether an offered conversion preserves the intended values.

Two legitimate output stages can have different byte totals

Suppose an offer describes a six-point export containing only PC-33's four selected fields, packed into 14 bytes per point with no row padding. Under those new, explicit output assumptions, it contains 84 value bytes. Another offer retains the full 112-byte data blob and its original descriptors. A smaller output is not inherently incomplete; the buyer needs to know which representation was purchased and whether its consuming interface agrees.

Returning 84 bytes while retaining PC-33's original row_step = 56 and height = 2 is a different case: the delivered data length contradicts the declared 112-byte extent. Conversely, 112 bytes without the matching field and stride descriptions leaves their interpretation unresolved.

The PyTorch views-and-strides guide addresses an already created tensor's storage and addressing. It does not define how this ROS message is converted into that tensor. Keep the source layout, conversion and destination dtype/shape as distinct stages; no copy-free path, allocation reduction or throughput gain follows from the smaller byte figure alone.

References: [R1]

A point slot is not proof of a valid observed surface

The Jazzy definition also supplies an acquisition-time/coordinate-frame header and an is_dense flag whose true state declares no invalid points. Those fields do not supply an invalid-point count or establish physical scene coverage. [R1]

PC-33's six point records therefore do not establish six valid measurements, six visible objects or an observed rear surface. An organized two-dimensional arrangement is an indexing relationship, not proof that every position contains usable geometry. The actual values, producer semantics and consumer's missing-data policy remain relevant.

This is distinct from purchasing a building point-cloud survey. That decision concerns which surfaces were captured and which model objects were interpreted. Here, the question is how an already supplied message's point fields are represented and retained. Neither a decoded message nor a rendered cloud grants permission to operate a robot or alter a facility.

References: [R1]

Evaluate the promised input at its actual boundary

For a perception-data offer, establish whether the recipient receives original messages, extracted fields or model-ready arrays. Compare one representative layout and value population at that boundary, including additional attributes, invalid-data treatment and any conversion. In PC-33, the useful outcomes are a reconciled 112-byte original representation, a separately specified 84-byte packed export, or an identified length/descriptor contradiction. None is a completed model-accuracy or performance result.

If the selected compute equipment also needs physical installation, Leviathan's rack-and-stack scope covers an agreed physical package such as mounting, IT cabling, labels and installation records. Sensor calibration, robotics software, data conversion and perception-model acceptance stay with their appointed owners. Use the existing service link for that separate installation requirement; this article offers no robotics integration service.

References: [L1]