Egomotion status 19 (NOT READY) with custom VehicleIO, which dwvehicleio fields are required?

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

DRIVE OS Version: 6.0.10

DRIVEWORKS SDK Version: 5.20

Platform: DRIVE AGX (custom drive‑by‑wire kit)

Issue Description:

We feed egomotion via a custom CAN parser (no dwVehicleIO driver). dwEgomotion_addVehicleIOState(safety, nonSafety, actuation, egomotion) returns DW_SUCCESS, and we also feed IMU/GPS successfully, but dwEgomotion_getEstimation() stays status 19 (NOT READY) and validFlags remain 0. We need to know which VehicleIO fields egomotion actually requires and what to use for signals we don’t have.

**Signals we SET vs LEAVE default/0
**
dwVehicleIOSafetyState

size -  sizeof(dwVehicleIOSafetyState) 

steeringWheelAngle - From SAS11 CAN, rad 

timestamp_us - Steering CAN timestamp 

sequenceId -  Monotonic increasing

validityInfo - set as  zeroed  memset 0 

rearWheelAngle - set as 0 No rear steer 

rearWheelAngleFactor - set as 0

steeringWheelAngleQuality  - set as 0 Header says : FUTURE_IMPLEMENTED_POST_24_06 |

rearWheelAngleQuality  - set as 0 Header says : FUTURE_IMPLEMENTED_POST_24_06 |

rearWheelAngleTimestamp -  set as 0 Header says : FUTURE_IMPLEMENTED_POST_24_06 |

steeringWheelAngleSpeed - set as 0 Header says : FUTURE_IMPLEMENTED_POST_24_06 |

dwVehicleIONonSafetyState

size - set as sizeof(dwVehicleIONonSafetyState)

drivePositionStatus - D/N/P/R from CAN TCU11 

timestamp_us - Latest of speed/steering/wheel ts 

speedESC - m/s from CAN CLU11 

speedDirectionESC -  From gear 

 speedESCTimestamp - Speed CAN ts 

speedQualityESC - DW_VIO_SPEED_QUALITY_E_S_C_SIG_DEF 

frontSteeringAngle - From CAN steering wheel / ratio, rad 

frontSteeringTimestamp - Steering CAN ts 

 frontSteeringAngleQuality - DW_VIO_FRONT_STEERING_ANGLE_QUALITY_INIT 

 wheelSpeed[0..3] - rad/s from WHL_SPD11 

wheelTicksTimestamp[0..3] - Wheel CAN ts 

 wheelTicksDirection[0..3] - From speedDirectionESC 

 wheelSpeedQuality[0..3] - DW_VIO_WHEEL_SPEED_QUALITY_SIG_DEF 

 vehicleStopped - From speedESC < 0.1 

 sequenceId - Monotoic increasing

 validityInfo - set as 0 

 kickdownStatus, latCtrlCurvatureActual, holdStatus, throttleValue, driverBrakePedal  - 0/default

 gearStatus, gearTarget, drivePositionTarget - 0/default

 hazardFlasherStatus, turnSignalStatus, brakePedalStatus, longCtrlEcoAssistStatus - 0/default

 handsoffDetectedFiltered, ESCOperationalState - 0/default

 headlightState, outsideTemperature, wetness*, rain*, light*, microSiren*, buckle*, door*, trunk*, hood*, trailer*, ignition* -  0/default

 speedMin, speedMax, speedIndicated -  0  Header says: FUTURE_IMPLEMENTED for min/max/indicated |

 wheelTicks[4], wheelTicksQuality[4], wheelTicksTimestampQuality[4] - set as 0/default 

 frontSteeringAngleOffset, frontSteeringTimestampQuality, frontSteeringAngleHigh, etc.  set as - 0/default

all other non-safety fields in struct) - set as 0/default

dwVehicleIOActuationFeedback

size - set as sizeof(dwVehicleIOActuationFeedback) 

timestamp_us - Synced timestamp

speedESC, speedDirectionESC, speedESCTimestamp, speedQualityESC  - From nonSafety 

steeringWheelAngle, frontSteeringAngle, frontSteeringTimestamp  - From safety/nonSafety 

wheelSpeed[0..3], wheelTicksTimestamp[0..3] - From nonSafety 

drivePositionStatus, vehicleStopped  - filled

sequenceId - Same as safety 

validityInfo  - set as 0

latCtrlCurvatureActual, rearWheelAngle, rearWheelAngleFactor - set as 0

 steeringWheelTorque, steeringWheelAngleQuality, holdStatus - set as 0/default

throttleValue, driverBrakePedal, gearStatus, gearTarget, drivePositionTarget - set as 0/default

driverOverrideThrottle, latCtrlCurvCapMin/Max[10], latCtrlEPSLimitStatus, latCtrlLoopStatus - set as 0/default

longCtrlEstimatedStopDistance, longCtrlFrictionRangeEstimation, longCtrlStatus, longCtrlFaultStatus - set as 0/default

(all other ActuationFeedback fields) - set as  0/default

Questions:

1. Minimal required set

For DW_EGOMOTION_IMU_ODOMETRY + DW_EGOMOTION_REAR_WHEEL_SPEED, which of the above must be non-zero/valid for egomotion to leave status 19? Is our set sufficient, or are we missing something (e.g. rearWheelAngle, validityInfo, wheelTicks)?
**
2. FUTURE_IMPLEMENTED_POST_24_06**

Can we leave all fields marked “FUTURE_IMPLEMENTED_POST_24_06” at 0 for egomotion in 5.20 (e.g. rearWheelAngleQuality, steeringWheelAngleQuality, rearWheelAngleTimestamp, steeringWheelAngleSpeed)?

3. validityInfo

We set all validityInfo to 0. Does egomotion treat 0 as valid, invalid, or unknown? Should we set explicit validity for the signals we fill (e.g. DW_SIGNAL_VALIDITY_VALID) and leave others INVALID/NOT_AVAILABLE?

4. Status 19 cause

Is there any doc or debug option that describes what internal check keeps egomotion in NOT READY when addVehicleIOState returns DW_SUCCESS?

5

Dear @atharv.sharma ,

Validflags field of dwEgomotion_getEstimation() result ?

8

under the header file EgomotionTypes.h in driveworks-5.20/targets/x86_64-Linux/include/dw/egomotion/base/EgomotionTypes.h

dwEgomotionResultQuality

typedef struct dwEgomotionResult

{
dwQuaternionf rotation;           //!< Attitude represented as quaternion.

dwTime_t timestamp;               //!< Timestamp of state estimate [us].

float32_t linearVelocity[3];      //!< Linear velocity in body frame [m/s].

float32_t angularVelocity[3];     //!< Angular velocity in body frame [rad/s].

float32_t linearAcceleration[3];  //!< Linear acceleration in body frame [m/s^2].

float32_t angularAcceleration[3]; //!< Angular acceleration in body frame [rad/s^2].

dwEgomotionResultQuality quality; //!< Signal validities and their error bounds.

int32_t validFlags;               // <---- This One 

} dwEgomotionResult;

When we log this value we get it as 0x00000000

9

@SivaRamaKrishnaNV any updates about it? Egomotion and pose estimation are the main blockers for us right now.

10

@SivaRamaKrishnaNV any updates about it?

11

Regarding question 3:

validityInfo is not a number like int, it is a struct (see
struct dwVehicleIOSafetyCommandValidityInfo) filled with signal validity statuses (see dwSignalValidity) . And thos statuses contain again different statuses for the value, the time and the E2E2Status.

To set the validity to valid like you need to set those statuses to DW_SIGNAL_STATUS_INIT.

Example:

void setSignalValid(dwSignalValidity* validity) 
    {
        dwStatus status = dwSignal_encodeSignalValidity(
            validity,
            DW_SIGNAL_STATUS_LAST_VALID,   // value  valid(Signal contains the last valid value that was set.)
            DW_SIGNAL_TIMEOUT_NONE,        // no tmeout
            DW_SIGNAL_E2E_NO_ERROR         // no E2E-error
        );
    }

You can use it like: setSignalValid(&m_vioSafety.validityInfo.steeringWheelAngle);

Hope this helps you :)

1 Like
12

ah got it!! thanks for pointing it out. We will test it out with these fixes. cheers!

13

validityInfo = 0 Means INVALID. This is almost certainly your issue.

So all your signals are being treated as invalid, even though you’re populating the actual values.

1. Minimal Required Set for DW_EGOMOTION_IMU_ODOMETRY + DW_EGOMOTION_REAR_WHEEL_SPEED
From /usr/local/driveworks/include/dw/egomotion/base/Egomotion.h (lines 257-278) on docker:
Required signals (must have valid validityInfo):

  • wheelSpeed[DW_VEHICLE_WHEEL_REAR_LEFT] and wheelSpeed[DW_VEHICLE_WHEEL_REAR_RIGHT] — rear wheel speeds in rad/s
  • wheelTicksTimestamp[DW_VEHICLE_WHEEL_REAR_LEFT] and wheelTicksTimestamp[DW_VEHICLE_WHEEL_REAR_RIGHT] — rear wheel tick timestamps
  • frontSteeringAngle — front steering angle in radians
  • frontSteeringTimestamp — timestamp for steering angle

Optional:

  • rearWheelAngle — only if your vehicle has rear-wheel steering (checked via signal presence flag)

Your signal set is sufficient in terms of which fields you’re filling. The problem is the validity flags.

**2. Can we leave all fields marked “FUTURE_IMPLEMENTED_POST_24_06” at 0

Yes, you can keep FUTURE_IMPLEMENTED_POST_24_06 to 0

3. validityInfo Interpretation
validityInfo valueInterpretation
0 INVALID — DW_SIGNAL_STATUS_INIT + DW_SIGNAL_TIMEOUT_NEVER_RECEIVED
5 VALID — DW_SIGNAL_STATUS_LAST_VALID + DW_SIGNAL_TIMEOUT_NONE + DW_SIGNAL_E2E_NO_ERROR
Did you check @Jis suggestion?

4. Status 19 = DW_NOT_READY
From DriveWorks SDK Reference: bazel-out/k8-opt/bin/src/dw/core/base/ErrorDefs.h File Reference
DW_NOT_READY = 19, //!< The processing is not finished or ready
This is returned by dwEgomotion_getEstimation() when hasEstimation() returns false. The conditions that cause NOT_READY

  1. Required measurements are missing — egomotion needs all of:
  • DW_EGOMOTION_MEASUREMENT_STEERING
  • DW_EGOMOTION_MEASUREMENT_LINEAR_GROUND_SPEED
  • DW_EGOMOTION_MEASUREMENT_PROPER_ACCELERATION (from IMU)
  • DW_EGOMOTION_MEASUREMENT_ANGULAR_VELOCITY (from IMU)
14

we ran our implementation again with the fix for the validity flags by @Jis We got egomotion estimation apis working.

15

Dear @Jis Glad to see you could help my colleague @atharv.sharma here. This correlates to our discussions before regarding bypassing the VehicleIO implementation. I have had missed the signal validity part from the structs mentioned.

@SivaRamaKrishnaNV Thanks for the input. Much appreciated!

16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.