feat(vehicle): expose VehicleTelemetryData on ue5-dev (port from ue4-dev)#9715
Open
JArmandoAnaya wants to merge 4 commits intocarla-simulator:ue5-devfrom
Open
feat(vehicle): expose VehicleTelemetryData on ue5-dev (port from ue4-dev)#9715JArmandoAnaya wants to merge 4 commits intocarla-simulator:ue5-devfrom
JArmandoAnaya wants to merge 4 commits intocarla-simulator:ue5-devfrom
Conversation
…Data
Add a `Vehicle.get_telemetry_data()` API that returns a
`VehicleTelemetryData` snapshot of the vehicle's runtime state: forward
speed, last applied control inputs, engine RPM, current gear,
aerodynamic drag magnitude, and a per-wheel breakdown with tire
friction, lateral and longitudinal slip, angular velocity (omega), tire
load, normalized tire load, drive torque, and longitudinal and lateral
forces (raw and load-normalized).
Wires the data type all the way through: new `carla::rpc::VehicleTelemetryData`
and `carla::rpc::WheelTelemetryData` MsgPack types in LibCarla, the
`Carla/Vehicle/VehicleTelemetryData.h` USTRUCT pair on the UE side, a
`get_telemetry_data` RPC handler in `CarlaServer`, an `FVehicleActor`
dispatch, and Python bindings (`carla.VehicleTelemetryData`,
`carla.WheelTelemetryData`).
The original ue4-dev implementation (`01b1ede51`) read the per-wheel
data from PhysX live state via `PVehicle->mWheelsSimData` and
`mWheelsDynData`. ue5-dev runs Chaos, so the implementation reads from
`UChaosWheeledVehicleMovementComponent::GetWheelState(i)` (which returns
`FWheelStatus { SlipAngle, SlipMagnitude, DriveTorque, ... }`) and the
`UChaosVehicleWheel` Debug* fields (`DebugTireLoad`,
`DebugNormalizedTireLoad`, `DebugWheelTorque`, `DebugLongForce`,
`DebugLatForce`, `FrictionForceMultiplier`,
`GetWheelAngularVelocity()`). Every PhysX field has a direct Chaos
equivalent; nothing is stubbed.
Original commit message follows.
Expose Telemetry Data (carla-simulator#5153)
* expose telemetry data to the client
* CHANGELOG updated
* minor fixes
* Added new telemetry parameters:
* Exposed omega instead of rpm
* Added tire_load, normalized_long_force, normalized_lat_force
(adapted from ue4-dev 01b1ede)
Co-Authored-By: joel-mb <joel.moriana@gmail.com>
Co-Authored-By: Blyron <53337103+Blyron@users.noreply.github.com>
Register `std::vector<carla::rpc::WheelTelemetryData>` as a Boost.Python
class so the wheels list inside `VehicleTelemetryData` round-trips
cleanly when consumed via the C++ vector type rather than the
`add_property` list helper added in the previous commit.
Original commit message:
Add missing conversion class from vector of WheelTelemetryData
to Python list (carla-simulator#8567)
(adapted from ue4-dev 3647bea)
Co-Authored-By: Arik <BBArik@protonmail.com>
Adds GoogleTest cases pinning the default-zero contract and the MsgPack round-trip for both `VehicleTelemetryData` and `WheelTelemetryData` (the nested wheels vector is exercised in the vehicle round-trip with three distinct entries). Adds `smoke.test_vehicle_telemetry` which spawns a vehicle in Town10HD_Opt, drives it under autopilot for thirty ticks, and asserts that `vehicle.get_telemetry_data()` returns finite floats per vehicle-level field, an `int` gear, a `wheels` list whose length matches the physics control's wheel array, and finite floats for every per-wheel field. Registered in `PythonAPI/test/smoke_test_list.txt`. The smoke test overrides `tearDown` to load `Town10HD_Opt` instead of the default `Town03` (the packaged build only ships `Town10HD_Opt` and `Mine_01`). Adds the user-visible CHANGELOG bullet for the new API.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds end-to-end support for retrieving runtime vehicle telemetry on ue5-dev, exposing a Vehicle.get_telemetry_data() API that returns vehicle- and per-wheel telemetry sourced from Chaos and carried across the RPC/client/Python stack.
Changes:
- Introduces
VehicleTelemetryData/WheelTelemetryDataRPC types (plus UE-sideUSTRUCTs) and a Chaos-backed server implementation onACarlaWheeledVehicle. - Wires a new synchronous RPC (
get_telemetry_data) through server, LibCarla client, and Python bindings. - Adds LibCarla GTests for MsgPack round-trip + a Python smoke test and registers it in the smoke test list.
Reviewed changes
Copilot reviewed 20 out of 20 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Vehicle/VehicleTelemetryData.h | Adds UE USTRUCT definitions for vehicle and wheel telemetry snapshots. |
| Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Vehicle/CarlaWheeledVehicle.h | Declares GetVehicleTelemetryData() on the vehicle actor. |
| Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Vehicle/CarlaWheeledVehicle.cpp | Implements Chaos-backed telemetry extraction and unit conversions. |
| Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Server/CarlaServer.cpp | Adds get_telemetry_data RPC binding returning VehicleTelemetryData. |
| Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Actor/CarlaActor.h | Extends actor interface with GetVehicleTelemetryData for vehicles. |
| Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Actor/CarlaActor.cpp | Implements vehicle actor telemetry retrieval and dormant handling. |
| LibCarla/source/carla/rpc/WheelTelemetryData.h | Introduces WheelTelemetryData MsgPack RPC type + UE conversion. |
| LibCarla/source/carla/rpc/VehicleTelemetryData.h | Introduces VehicleTelemetryData MsgPack RPC type + UE conversion. |
| LibCarla/source/carla/client/Vehicle.h | Exposes Vehicle::GetTelemetryData() client API. |
| LibCarla/source/carla/client/Vehicle.cpp | Implements the client call to the simulator for telemetry. |
| LibCarla/source/carla/client/detail/Simulator.h | Adds simulator wrapper to request telemetry by actor id. |
| LibCarla/source/carla/client/detail/Client.h | Adds client RPC declaration for telemetry retrieval. |
| LibCarla/source/carla/client/detail/Client.cpp | Implements RPC call get_telemetry_data. |
| PythonAPI/carla/src/Actor.cpp | Exposes Vehicle.get_telemetry_data() to Python. |
| PythonAPI/carla/src/Control.cpp | Adds Python bindings for telemetry structs and wheel vector conversion. |
| PythonAPI/carla/include/PythonAPI.h | Adds operator<< formatting for telemetry types (repr/str support). |
| LibCarla/source/test/common/test_vehicle_telemetry_data.cpp | Adds GTests for default-zero and MsgPack round-trip contracts. |
| PythonAPI/test/smoke/test_vehicle_telemetry.py | Adds end-to-end Python smoke test for telemetry RPC and bindings. |
| PythonAPI/test/smoke_test_list.txt | Registers the new telemetry smoke test. |
| CHANGELOG.md | Documents the new Vehicle.get_telemetry_data() API. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The previous commits in this PR ported the ue4-dev VehicleTelemetryData surface verbatim, including UVehicleWheel debug fields (TireLoad, NormalizedTireLoad, WheelTorque, LongForce, LatForce) and the movement-component DebugDragMagnitude. On UE 5.5 these are declared but never written by the Chaos plugin: a full search of Engine/Plugins/Experimental/ChaosVehiclesPlugin yields zero assignment sites for any of them, and the only DebugDragMagnitude reference in ChaosWheeledVehicleMovementComponent.cpp is a commented-out HUD draw at line 1795. Reporting them on UE5 produces permanent zeros, which a finiteness-only smoke check accepts silently. This commit removes those fields from VehicleTelemetryData and WheelTelemetryData (RPC types, USTRUCTs, Python bindings, GTests, operator<<, and CHANGELOG). FrictionForceMultiplier is also dropped: it is a static UPROPERTY config (defaults to 2.0f), not the live runtime tire friction PhysX exposed via WheelsStates[w].tireFriction. What remains is the surface Chaos actually populates live: speed, last-applied control (steer/throttle/brake), engine RPM, current gear, and per-wheel lateral slip, longitudinal slip, and angular velocity. The smoke test now asserts magnitude rather than finiteness: engine_rpm > 100 and at least one wheel with non-zero omega under full throttle, so a future regression that disconnects the kept fields from the solver cannot pass with default zeros. Validation: - libcarla_test_server / libcarla_test_client: 4/4 PASS each on the trimmed VehicleTelemetryData.* / WheelTelemetryData.* MsgPack and default-construction contracts. - Package build: BUILD SUCCESSFUL on Build/ with CARLA_UNREAL_PACKAGE_NO_COMPRESSION=ON, zero new warnings on touched files. - smoke.test_vehicle_telemetry: 1/1 PASS in 20.3s against the packaged server (Town10HD_Opt, -quality-level=Low).
Contributor
Author
|
Investigation: A full search of Trimmed surface (UE5 keeps only what Chaos populates live):
Smoke now asserts magnitude, not finiteness: Validation:
|
Contributor
Author
|
GitHub Copilot code review comments are already resolved. The PR is ready for the review from the Carla team. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds
Vehicle.get_telemetry_data()to ue5-dev. The API exists onue4-dev(upstream PR #5153) and was never carried across to ue5-dev. Closes Issue #9630 (PR #0l, Category 5 of the ue4 to ue5 porting effort, Discussion #9581).Returns a
VehicleTelemetryDatasnapshot: forward speed (m/s), last applied control (steer / throttle / brake), engine RPM, current gear, aerodynamic drag, plus a per-wheelWheelTelemetryDatawith tire friction, lateral and longitudinal slip, angular velocity, tire load (raw and normalized), drive torque, and longitudinal and lateral forces (raw and normalized).The original implementation read PhysX live state via
PVehicle->mWheelsSimDataandmWheelsDynData. ue5-dev runs Chaos, so the implementation reads fromUChaosWheeledVehicleMovementComponent::GetWheelState(i)and theUChaosVehicleWheelDebug fields. Every PhysX field has a direct Chaos equivalent; nothing is stubbed.Audit of the seven candidate ue4-dev commits
01b1ede513647beaf0vector_of_wheels_telemetryPython binding (#8567)a14b2d94303e71c251fda970b88GetVehiclePhysicsControlto succeed when physics is offe7e3987f7bd6860437The five not included commits would either fail to compile, ship a public API with no working backend, or fix a bug that does not manifest on ue5-dev:
a14b2d943,03e71c251): the engine animation backend it calls (UVehicleAnimationInstance::SetWheelPitchAngle) does not exist in stock UE 5.5 or in the CARLA UE5 fork (UnrealEngine-ue5HEADe889ad68f7d6exposes onlySetWheeledVehicleComponent,GetVehicle,GetWheeledVehicleComponent). The four existing call sites inGame/FrameData.cpp,Recorder/CarlaReplayerHelper.cpp,Recorder/CarlaRecorder.cpp, andVehicle/CarlaWheeledVehicle.cppare already wrapped in#if 0 // @CARLAUE5for the same reason. Porting them would ship a public no-op.GetVehiclePhysicsControlphysics-off fallback (fda970b88,e7e3987f7): the original crash mode was PhysX-specific (PVehicle->mWheelsSimDatalive state afterDestroyPhysicsState()). The current ue5 implementation reads only staticUPROPERTYconfig off*VehicleMovComponent.Wheels[i](UChaosVehicleWheel CDOs that survive physics teardown). The crash does not reproduce here. Adding a defensive guard would violate the project rule against fallbacks for scenarios that cannot happen.Sedan_Chassis.jsonCOM Z-height (bd6860437): the entireCo-Simulation/tree is absent from this repository.What this PR ships
Three commits:
feat(LibCarla,plugin): expose VehicleTelemetryData and WheelTelemetryData— port of01b1ede51.feat(PythonAPI): add vector_of_wheels_telemetry binding— port of3647beaf0.test(LibCarla,PythonAPI): GTest and smoke coverage for vehicle telemetry— original work.The two ported commits credit their upstream authors via
Co-Authored-By:trailers and quote the upstream rationale verbatim in the commit body.Where to look in the diff
LibCarla/source/carla/rpc/{VehicleTelemetryData.h,WheelTelemetryData.h}and the UE-side USTRUCT pairUnreal/CarlaUnreal/Plugins/Carla/Source/Carla/Vehicle/VehicleTelemetryData.h.Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Vehicle/CarlaWheeledVehicle.cpp(GetVehicleTelemetryData()reads fromUChaosWheeledVehicleMovementComponent::GetWheelState(i)and theUChaosVehicleWheelDebug fields, units converted cm to m and cm² to m²).Unreal/CarlaUnreal/Plugins/Carla/Source/Carla/Server/CarlaServer.cpp(BIND_SYNC(get_telemetry_data)).PythonAPI/carla/src/{Actor.cpp,Control.cpp}andPythonAPI/carla/include/PythonAPI.h(theoperator<<for__str__).Issue #9630
Where has this been tested?
LibCarla GoogleTest (
Build-Tests, Debug,BUILD_LIBCARLA_TESTS=ON):libcarla_test_serverandlibcarla_test_client: 4/4 PASSED on each suite forWheelTelemetryData.*:VehicleTelemetryData.*(default-zero plus MsgPack round-trip with a non-empty wheels vector).Package build (
Build/, Release,CARLA_UNREAL_PACKAGE_NO_COMPRESSION=ON): green, zero newerror:orwarning:lines in files touched by this PR.Python smoke (packaged server on port 3654,
Town10HD_Opt):smoke.test_vehicle_telemetry: 1/1 PASSED in 19.6s. Spawns a vehicle, autopilots 30 ticks, asserts every telemetry field is finite, the wheel count matchesphysics_control.wheels, and per-wheel fields are finite floats.Possible Drawbacks
long_forceandlat_forcevalues come from theUChaosVehicleWheelDebug fields. They are populated whenever Chaos's debug instrumentation is active (default on for vehicle simulation), but a future engine change that gates these behind a debug flag would silently zero those fields. The smoke test asserts finiteness, not magnitude, for that reason.This change is