ros-bridge
ros-bridge copied to clipboard
Fill CarlaEgoVehicleControl message header
Fill the message header of CarlaEgoVehicleControl messages with header received from odometry
Some robustness increases:
- make vehicle_pid_controller robust against missing speed/pose input
Hi @berndgassmann!
I believe there is a small issue in how the parameters are handled inside the launch file. To prevent the error described here https://github.com/carla-simulator/ros-bridge/issues/603 (as you pointed out, it isn't related to Carla version at all) you changed the lines
'spawn_point': launch.substitutions.LaunchConfiguration('spawn_point')
To
'spawn_point': str(launch.substitutions.LaunchConfiguration('spawn_point'))
The problem is that the python interpreter tries to convert the object launch.substitutions.LaunchConfiguration
to string, instead of trying to convert the passed parameter to string. So, when I try to execute one of the launch files (e.g. carla_ros_bridge_with_example_ego_vehicle.launch.py), the following warning log appears (it appears along a lot of other info level log messages)
[carla_spawn_objects-2] [WARN] [1657302416.515107942] [carla_spawn_objects]: Invalid spawnpoint '<launch.substitutions.launch_configuration.LaunchConfiguration object at 0x7effb0922cd0>'
[carla_spawn_objects-2] [WARN] [1657302416.515544664] [carla_spawn_objects]: ego_vehicle: Could not use spawn point from parameters, the spawn point from config file will be used.
The value received is the python string description of a generic object <launch.substitutions.launch_configuration.LaunchConfiguration object at 0x7effb0922cd0>
, instead of being the desired value passed to the parameter.
Taking a step behind, this issue is related on how ROS 2 python launch files are built. By the time the python interpreter is running this piece of code, the information of the actual parameter is not available. To treat its value in run time, the use of an OpaqueFunction
is needed (more info on this here)
The test I made was using ROS 2 Foxy