In my system architecture, I have a custom truck which is being spawned with a custom trailer. I spawn my truck with the help of environment control and to register the trailer fully in the environment I had introduced a delay node in the blueprint as well as introduced a world.tick() after the trailer is beign spawned in the environment.
- When Spawned Together (FAIL): When the custom truck and trailer are spawned together dynamically via the Python API in the exact same frame session, the vehicle movement physics permanently freeze immediately upon attachment. Tires exhibit a minor vibration tremor on Frame 0, but the vehicle completely ignores subsequent ROS throttle and torque inputs. I can see that the wheels of the truck are moving very slightly in this environment, but is unable to pull the trailer forward. I tried to debug it by chnaging the wheel settings into kinematic or simulated or default. I also tried to debug it with the help of disabling physics with the trailer, but the prolem persits.
- When Spawned Separately (SUCCESS): If the truck is spawned alone, it moves perfectly. If the trailer is pre-placed in the level map and the truck is spawned alone later, it also works perfectly.
- Blueprint Verification: Comprehensive Blueprint string debugging confirms that runtime logic is flawless. The nodes fire successfully with valid object references, and the assets are constrained properly. The lock is occurring downstream within the physics/movement component layer.
The Immutable Binary & Docker Paradox
To isolate regressions, we ran tests using historical, pre-compiled production binary packages (CARLA/Dist) from 4 months ago. Because these are compiled binaries, no modifications can be made to the internal files or code.
-
Inside Docker Container (PASS): Running these exact unmodifiable binary files inside a containerized Docker environment yields a 100% success rate. The truck and trailer spawn together, couple cleanly, and drive smoothly under continuous ROS control.
-
On Local Host OS (FAIL): Executing the exact same unmodifiable binary packages natively on the host workstation (Ubuntu Linux) results in immediate wheel paralysis. Old packages that worked months ago now reproduce this exact local host freeze.
Why am I seeing this error and how can I resolve it?