Fill CarlaEgoVehicleControl message header

[berndgassmann]

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

---

This change is 

[FelipeGdM]

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 #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

[berndgassmann]

Hi @FelipeGdM

You are totally right. My changes only worked at my end, because I am providing the spawnpoint in my scenarios via configuration file. So the start-up didn't explode anymore, but the spawn_point from launch file didn't work. So definitely have to use your solution in this regards, which works fine for me.

Thanks.

Reviewable status: 0 of 5 files reviewed, all discussions resolved (waiting on @joel-mb)