|
| 1 | +ifndef::include-only-once[] |
| 2 | +:root-path: ../ |
| 3 | +include::{root-path}_config.adoc[] |
| 4 | +endif::[] |
1 | 5 | = MCAP Format |
2 | 6 |
|
3 | 7 | == General Requirements |
|
14 | 18 | == Channel |
15 | 19 | - `message_encoding` field: Must be "protobuf" |
16 | 20 | - `metadata` field: |
17 | | - - Must include an `osi_version` key, specifying the OSI SemVer version of the message contained within the channel |
18 | | - - Should include a `description` key explaining the data's origin and purpose |
| 21 | + - Must include an `osi_version` key, specifying the OSI SemVer version of the OSI top-level message contained within the channel |
| 22 | + - Must include a `protobuf` key, specifying the protobuf SemVer version used to create the OSI top-level message contained within the channel |
| 23 | + - Should include a `description` key, explaining the data's origin and purpose in natural language. |
| 24 | + |
19 | 25 |
|
20 | 26 | == Message |
21 | 27 | - `publish_time` field: |
22 | | - - Must reflect the timestamp of the stored OSI top-level message if it contains a timestamp field |
| 28 | + - Must reflect the timestamp of the stored OSI top-level message |
23 | 29 | - Must be in nanoseconds |
24 | 30 | - `log_time` field: Must reflect the time when the message was enqueued for MCAP file addition |
25 | | - - Must reflect the time when the top-level OSI message was enqueued for addition to the MCAP file |
26 | | - - Zero time doesn't need to coincide with the Unix epoch, but it is recommended |
| 31 | + - Must reflect the timestamp of the stored OSI top-level message |
27 | 32 | - Must be in nanoseconds |
28 | 33 |
|
| 34 | + |
29 | 35 | == Metadata |
30 | 36 | - Must include metadata with the name `versions` containing at least the following key-value pairs: |
31 | 37 | * `osi`: SemVer version of the minimum required OSI version |
32 | | - * `protobuf`: SemVer version of protobuf library |
33 | 38 | - Must include metadata with the name `creation_date` containing at least the following key-value pairs: |
34 | 39 | * `timestamp`: ISO 8601 formatted creation time |
35 | 40 | - Must include metadata with the name `description` containing at least the following key-value pairs: |
36 | 41 | * `text`: Scenario description |
37 | 42 | - Additional custom metadata may be added |
38 | 43 |
|
39 | 44 | == Compression |
40 | | -- OSI-compliant tooling must support compression types: `none`, `lz4`, and `zstd` |
| 45 | +- OSI-compliant tooling must support compression types: `none`, `lz4`, and `zstd` |
| 46 | + |
| 47 | + |
| 48 | +== Naming Convention |
| 49 | +.mcap files must follow this naming convention: |
| 50 | + |
| 51 | + |
| 52 | +---- |
| 53 | +<opt. prefix>_<opt. timestamp>_<type>_<opt. suffix>.cap |
| 54 | +---- |
| 55 | + |
| 56 | +When not using an optional field, the corresponding `_` delimiter must be omitted so that no double `_` is present. |
| 57 | + |
| 58 | +[#tab-MCAP-file-naming-convention] |
| 59 | +.MCAP file naming convention |
| 60 | +[cols="1,1"] |
| 61 | +|=== |
| 62 | +|Field |Explanation |
| 63 | + |
| 64 | +|opt. prefix |
| 65 | +|An optional prefix which may be used to specify the type of scenario (e.g. `cut-in`) or uniqueness of the setup (e.g. `target-5m`). May not contain any `_` characters. |
| 66 | + |
| 67 | +|opt. timestamp |
| 68 | +|Defines the absolute start time for a scenario or recording. If following the recommended zero time for the timestamps of the top-level message, this time must represent the zero time. The format must adhere to ISO 8601 [cite:iso8601]. |
| 69 | + |
| 70 | + |
| 71 | +|type |
| 72 | +| Specifies contained the top-level message(s) and must be one of the following values: |
| 73 | + |
| 74 | +`sv` file contains only `SensorView` messages. + |
| 75 | +`gt` file contains only `GroundTruth` messages. + |
| 76 | +`hvd` file contains only `HostVehicleData` messages. + |
| 77 | +`sd` file contains only SensorData` messages. + |
| 78 | +`tc` file contains only `TrafficCommand` messages.+ |
| 79 | +`tcu` file contains only `TrafficCommandUpdate` messages. |
| 80 | +`tu` file contains only `TrafficUpdate` messages. |
| 81 | +`mr` file contains only `MotionRequest` messages. |
| 82 | +`su` file contains only `StreamingUpdate` messages. |
| 83 | +`multi` file contains multiple, different types of of top-level messages (not including different channels of the same type). |
| 84 | + |
| 85 | +|opt. suffix |
| 86 | +|An optional suffix which may be used the same way like the optional prefix or be used to specify further details like the minimum required OSI version. May not contain any `_` characters. |
| 87 | + |
| 88 | + |
| 89 | +|=== |
| 90 | + |
| 91 | + |
| 92 | +**Example** |
| 93 | + |
| 94 | +The following list shows examples of valid OSI MCAP file names: |
| 95 | +- `20210818T150542Z_highway_sv.mcap` |
| 96 | +- `20210818T150542Z_highway_sv_run-1.mcap` |
| 97 | +- `20210818T150542Z_highway_gt_OSI-3-7.mcap` |
| 98 | +- `Highway_sd_version-1.mcap` |
| 99 | +- `Highway-cut-in-no-collision_sd.mcap` |
| 100 | +- `Target-5m_sd_resimulated-measurement.mcap` |
| 101 | + |
| 102 | +NOTE: This naming convention does not apply to .osi and .txt files, they should follow the naming convention described in their section. |
0 commit comments