Questions about dwEgomotion_addVehicleIOState required signals and timestamps

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.10.0
DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
2.1.0
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Issue Description

Hi everyone,

I have a few detailed questions about the dwEgomotion_addVehicleIOState function and its required inputs. According to the documentation of dwEgomotion_addVehicleIOState :

"When using DW_EGOMOTION_ODOMETRY, the following valid signals in at least one of the structs dwVehicleIOSafetyState, dwVehicleIONonSafetyState or dwVehicleIOActuationFeedback are required:

frontSteeringAngle, frontSteeringTimestamp, wheelSpeed (1), wheelSpeedTimestamp (1), speed (2, 3), speedTimestamp (2, 3), rearWheelAngle (3)

(1) if dwEgomotionParameters.speedMeasurementType == DW_EGOMOTION_REAR_WHEEL_SPEED
(2) if dwEgomotionParameters.speedMeasurementType == DW_EGOMOTION_FRONT_SPEED
(3) if dwEgomotionParameters.speedMeasurementType == DW_EGOMOTION_REAR_SPEED"

Now I’m trying to understand how exactly these fields are meant to be provided, since the struct definitions don’t seem to match the documentation perfectly.

  1. There is no explicit speed field in any of the three structs (dwVehicleIOSafetyState, dwVehicleIONonSafetyState, dwVehicleIOActuationFeedback). The only similar field I can find is speedESC.
    → Is speedESC the value that should be used as “speed” here?

  2. The corresponding timestamp field speedESCTimestamp is marked as FUTURE_IMPLEMENTED_POST_24_06 in the headers.
    → Does that mean it’s not yet usable?
    → If yes, what timestamp should I provide to the Egomotion module instead, since I assume it still requires timing information for proper estimation?

  3. For wheelSpeed, the struct defines wheelSpeed[4] (FL, FR, RL, RR).
    → Should I also provide four timestamps, i.e. wheelSpeedTimestamp[4]?
    → I can’t find any wheelSpeedTimestamp field in any of the structs. How is that supposed to be handled?

  4. My CAN bus provides four individual signals for each wheel speed.
    → Is the following usage correct in that case?

if (strcmp(signalname, "ESP_19.ESP_FL_wheelspeed_02") == 0) {
    m_currVehicleNonSafeState.wheelSpeed[0] = value; // FL wheel, rad/s
    ICantFindThisFieldInStructs.wheelSpeedTimestamp[0] = timestamp; // questions to this see point 3
}

if (strcmp(signalname, "ESP_19.ESP_FR_wheelspeed_02") == 0) {
    m_currVehicleNonSafeState.wheelSpeed[1] = value; // FR wheel
    ICantFindThisFieldInStructs.wheelSpeedTimestamp[1] = timestamp; // questions to this see point 3
}

// ... and so on for RL and RR

Any clarification on how exactly these signals and timestamps should be provided for Egomotion to work correctly would be very helpful

Thanks in advance!

5

Dear @Jis ,
Let me check internally on this and get back to you. Thanks

6

dear @Jis, for this specific timestamping issue, the synchronization is still unclear from NVIDIA @SivaRamaKrishnaNV can you please confirm the concept of sync from this thread as well?

I have had followed SpeedESC, however timestamping and sync is completely on my side when using DW_IMU_ODOMETRY motion model, because of VehicleIO being incomplete and the source code isnt publicly available.

so @Jis the not implimented timestamp fields can be ignored, rather use sensor timestamps in the payload to timestamp_us

7

Also to point out SpeedESC is something that is obtained from a Electronic Stability Control program not the actual vehicle speed, transforming this from actually speed from the CAN bus to this relation is still unclear.

8

Dear @Jis ,

  1. There is no explicit speed field in any of the three structs (dwVehicleIOSafetyState , dwVehicleIONonSafetyState , dwVehicleIOActuationFeedback ). The only similar field I can find is speedESC .
    → Is speedESC the value that should be used as “speed” here?

if move forward, speed is speedESC, if move back, speed is -speedESC.

  1. The corresponding timestamp field speedESCTimestamp is marked as FUTURE_IMPLEMENTED_POST_24_06 in the headers.
    → Does that mean it’s not yet usable?
    → If yes, what timestamp should I provide to the Egomotion module instead, since I assume it still requires timing information for proper estimation?

we can use it. It’s timestamp for speedESC.

  1. For wheelSpeed , the struct defines wheelSpeed[4] (FL, FR, RL, RR).
    → Should I also provide four timestamps, i.e. wheelSpeedTimestamp[4] ?
    → I can’t find any wheelSpeedTimestamp field in any of the structs. How is that supposed to be handled?

wheelSpeedTimestamp was deprecated, use the replacement value wheelTicksTimestamp.

  1. My CAN bus provides four individual signals for each wheel speed.
    → Is the following usage correct in that case?

It is looking good to me

1 Like