1 # Copyright (c) 2019-2020 NVIDIA CORPORATION. All rights reserved.
3 @page rigconfiguration_usecase0 Rig File Format
5 @note SW Release Applicability: This tutorial is applicable to modules in both **NVIDIA DriveWorks** and **NVIDIA DRIVE Software** releases.
7 A rig file contains two major fields to define sensors and vehicles, that is,
11 "sensors": [ { sensor I }, { sensor II }, ... ],
12 "vehicle": { vehicle }
19 Each sensor field provides information on each sensor and can be categorized into two types: camera field and non-camera field.
23 Each camera field is an array that describes each specific camera in the sensor suite. The following code snippet shows how the camera field is structured,
26 "name": "camera:front:center:60fov",
27 "nominalSensor2Rig": {
40 "parameter": "camera-type=ar0231-rccb-bae-sf3325,camera-group=a,camera-count=1,camera-mask=0001,siblingIndex=0,output-format=raw+yuv,fifo-size=1,warn-per-frame=0",
43 "bw-poly": "0.0 0.000545421498827636 -1.6216719633103e-10 -4.64720492990289e-12 2.85224527762934e-16",
48 "car-mask": "camera:front:center:60fov.pgm"
50 "protocol": "camera.gmsl",
65 "data/rle16-base64": "//8BjoABAQAA3QEBBQAA2gEBBwAA2AEBC...",
72 **name**: *camera* : *front* | *rear* : *left* | *center* | *right* : *60fov* | *120fov*
74 **parameter**: [camera parameters](@ref dwx_sensor_enum_sample)
76 **properties**: Properties are stored in name=value pairs and implement properties which are specific for a certain sensor in a generic way. A camera can specify calibration parameters, e.g. the intrinsic parameters, in here.
78 **properties->Model**: *ftheta* | *ocam* | *pinhole*
80 This determines the supported optical camera models, which defines the mapping between optical rays and pixel coordinates. Each model has a separate set of parameters `dwFThetaCameraConfig`, `dwOCamCameraConfig`, `dwPinholeCameraConfig`.
82 **car-mask**: The `car-mask` *property* specifies a (optional) binary image file (currently `.pgm` images are supported) representing a binary mask of the ego-car in the camera image, separating it from the scene. Also, (optional) serialized car mask images are supported, which are represented by a serialization of the binary car mask images in the `car-mask` *field*. A `car-mask` image file property will be converted into a `car-mask` field on rig file serialization, and `car-mask` image file properties always have precedence over serialized car masks (to be able to update them). Car masks are important for, e.g., accurate self-calibration of the given camera.
84 **protocol**: For camera sensors, protocol must be *camera.gmsl*
86 <a name="sensor2Rig"></a>
89 This is the sensor to rig transformation for a camera, and can be represented in two forms,
94 "quaternion": [q_x, q_y, q_z, q_w],
102 "roll-pitch-yaw": [roll, pitch, yaw],
106 This transformation relates the camera and the rig coordinate system to each other, i.e. translation in meters and roll-pitch-yaw in degrees. For example, the origin in camera coordinate system is the position of the camera in rig coordinates. The self-calibration might remove this field, and substitute it with *correction_rig_T* and *correction_sensor_R_FLU* transformations after the calibration.
108 <a name="nominalSensor2Rig"></a>
109 **nominalSensor2Rig**:
111 This is the nominal sensor to rig transformation for a camera, and can be represented in two forms,
116 "quaternion": [q_x, q_y, q_z, q_w],
123 "roll-pitch-yaw": [roll, pitch, yaw],
127 This transformation differs from *sensor2rig* transformation in that it represents a static reference transformation from factory calibration and/or mechanical drawings, whereas *sensor2rig* can change over time.
129 <a name="correction_rig_T"></a>
130 **correction_rig_T**:
132 This shows the corrections in the translation with respect to the *nominalSensor2Rig* transformation, which is estimated and added to the rig file by the self-calibration. The self-calibration saves the translation updates only as,
138 <a name="correction_sensor_R_FLU"></a>
139 **correction_sensor_R_FLU**:
141 This shows the corrections in the rotation with respect to the *nominalSensor2Rig* transformation, which is estimated and added to the rig file by the self-calibration. The self-calibration saves the rotation updates only as,
144 "roll-pitch-yaw": [roll, pitch, yaw],
147 <a name="nominalSensor2Rig_FLU"></a>
148 **nominalSensor2Rig_FLU**:
150 During the self-calibration, *nominalSensor2Rig* transformation is renamed and saved as *nominalSensor2Rig_FLU* without any change in the values as,
153 "roll-pitch-yaw": [roll, pitch, yaw],
157 @note To summarize the self-calibration changes in the rig files,
158 - Rig files before self-calibration: *sensor2Rig* + *nominalSensor2Rig*
159 - Rig files after self-calibration: *correction_sensor_R_FLU* + *correction_rig_T* + *nominalSensor2Rig_FLU*
161 ## 2. Non-Camera Field
163 NVIDIA<sup>®</sup> DriveWorks currently supports the following non-camera sensors:
170 The following code snippet shows an example for the IMU sensor field,
174 "nominalSensor2Rig": {
187 "parameter": "device=/dev/ttyUSBXSENS,baudrate=230400,time-smoothing=true",
189 "protocol": "imu.xsens",
205 The following code snippet shows an example for the GPS sensor field,
209 "correction_rig_T": [
214 "correction_sensor_R_FLU": {
221 "nominalSensor2Rig_FLU": {
233 "parameter": "file=device=/dev/ttyUSBXSENS,baudrate=230400",
235 "protocol": "gps.xsens"
238 **name**: *can* | *gps* | *imu* | *lidar* | *radar*
240 **parameter**: [sensor parameters](@ref dwx_sensor_enum_sample)
244 Properties are stored in name=value pairs and implement properties which are specific for a certain sensor in a generic way. For example, an IMU might store bias values there, etc.
248 - CAN: *can.socket* | *can.aurix*
249 - GPS: *gps.uart* | *gps.xsens*
250 - IMU: *imu.uart* | *imu.xsens*
251 - Lidar: *lidar.socket*
252 - Radar: *radar.socket*
254 **sensor2Rig**: [sensor2Rig transformation](#sensor2Rig)
256 **nominalSensor2Rig**: [nominalSensor2Rig transformation](#nominalSensor2Rig)
258 **correction_rig_T**: [correction_rig_T transformation](#correction_rig_T)
260 **correction_sensor_R_FLU**: [correction_sensor_R_FLU transformation](#correction_sensor_R_FLU)
262 **nominalSensor2Rig_FLU**: [nominalSensor2Rig_FLU transformation](#nominalSensor2Rig_FLU)
266 The following rig snippet shows the vehicle field structure,
273 "corneringStiffness": 0.0,
276 "wheelRadiusLeft": 0.0,
277 "wheelRadiusRight": 0.0
280 "corneringStiffness": 0.0,
283 "wheelRadiusLeft": 0.0,
284 "wheelRadiusRight": 0.0
287 "boundingBoxPosition": [0.0, 0.0, 0.0],
288 "centerOfMass": [0.0, 0.0, 0.0],
290 "inertia": [0.0, 0.0, 0.0],
296 "brakeActuatorTimeConstant": 0.0,
297 "effectiveMass": 0.0,
298 "throttleActuatorTimeConstant": 0.0,
300 "throttlePedalInput": "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
301 "throttleSpeedInput": "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
302 "throttleTorqueOutput": [
303 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
304 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
305 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
306 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
307 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
308 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
309 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
310 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
311 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
312 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
313 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
314 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
315 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
316 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
317 "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0"
319 "brakePedalInput": "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0",
320 "brakeTorqueOutput": "0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0"
324 "driveByWireTimeConstant": 0.0,
325 "driveByWireTimeDelay": 0.0,
326 "maxSteeringWheelAngle": 0.0,
327 "steeringWheelToSteeringMap": [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
330 "pitchDampingRatio": 0.0,
331 "pitchNaturalFrequency": 0.0
339 For the full implementation refer to `dwVehicleGeneric`
343 Vehicle IO field describes Drive-By-Wire interface of a vehicle.
348 "parent-sensor": "can:vehicle",
349 "dbc-file": "AutonomousVehicleCANSignals.dbc"
354 "name": "can:vehicle",
355 "parameter": "device=can0",
356 "protocol": "can.socket",
358 "nominalSensor2Rig": { "quaternion": [ 0.0, 0.0, 0.0, 1.0 ], "t": [ 0.0, 0.0, 0.0 ] },
359 "sensor2Rig": { "quaternion": [ 0.0, 0.0, 0.0, 1.0 ], "t": [ 0.0, 0.0, 0.0 ] }
363 **type**: [Type of a Drive-By-Wire interface.](@ref vehicleio_mainsection)
365 **parent-sensor**: Name of a sensor that is used to communicate with Drive-By-Wire hardware.
367 **dbc-file**: A DBC file for Vehicle IO drivers that require one.
369 For more information, please refer to
370 [Vehicle IO Documentation](@ref vehicleio_mainsection),
371 [Vehicle IO Sample](@ref dwx_vehicleio_sample), and
372 [Vehicle IO Plugin sample](@ref dwx_vehicleio_plugin_sample).