Refactor CARLA Operator

[pschafhalter]

Refactors the CARLA operator by creating drivers for pose, ground truth information, and HD maps. The CarlaOperator will continue to write on vehicle_id_stream once the ego-vehicle is set up.

Changes

Driver Operators

Tested via the MatchesOperator on synchronous and pseudo-async mode.

• CarlaPoseDriverOperator. Implements pose_stream and pose_stream_for_control.
• CarlaTrafficLightsDriverOperator. Implements ground_traffic_lights_stream.
• CarlaObstaclesDriverOperator. Implements ground_obstacles_stream.
• CarlaSpeedLimitSignsDriverOperator. Implements ground_speed_limit_signs_stream.
• CarlaStopSignsDriverOperator. Implements ground_stop_signs_stream.
• CarlaOpenDriveDriverOperator. Implements open_drive_stream.

Other Changes

• Implement __eq__ for Pose for testing.
• Update CarlaOperator
• Deprecate global_trajectory_stream from the CarlaOperator. Replace with an IngestStream as it only sends a top watermark.
• Remove MatchesOperator once all drivers are tested.

[sukritkalra]

I haven't looked over the entire PR yet, but it would be helpful for me to get the answers to the following questions to understand the migration architecture.

[sukritkalra]

Suggested change

	if isinstance(other, Pose):
	return (self.transform == other.transform
	and self.forward_speed == other.forward_speed
	and self.velocity_vector == other.velocity_vector)
	if isinstance(other, Pose):
	return (self.transform == other.transform
	and self.forward_speed == other.forward_speed
	and self.velocity_vector == other.velocity_vector)
	return NotImplemented

[sukritkalra]

Is this for shadow testing and will be removed once the PR is approved?

[pschafhalter]

Yeah, this is to check that the messages sent and received are the same.

[sukritkalra]

Why were these operators subclassed from a BaseGNSSDriverOperator? They don't seem to be using the gnss_msg exposed in the process_gnss method and retrieve different data from the simulator.

[pschafhalter]

My thought process is the following:

1. The original CARLA operator performs complicated logic to send data from the simulator (e.g. pose, ground obstacles, etc) at multiple frequencies (localization and control). This logic is coupled with how the operator ticks the simulator.
2. Sensors can define tick frequencies independently. Therefore, we can set up a lightweight sensor such as GNSS which calls the logic for sending arbitrary information at arbitrary frequencies.
3. The logic for setting up the GNSS sensor is identical across several operators, so I moved the shared logic to BaseGNSSDriverOperator. I could also move it to a helper method or rename process_gnss, if you think that's cleaner.

I checked if any other actors can invoke callbacks at configurable frequencies, but it appears that this is limited to sensors.

[sukritkalra]

So the GNSS sensor is being used as a timestamping mechanism? Why not just have a base operator that sends its downstream operators a watermark message to retrieve and release data?

[pschafhalter]

That works too, but it would still share logic with the GNSS sensor operator, and we'd still need to instantiate one for each downstream operator frequency. So the question is whether the data release mechanism should be a standalone operator or a coupled with the driver operators.

Personally, I think it makes sense to put the logic in the driver operator so that the API reflects the other driver operators and simplifies pipeline architecture.

[sukritkalra]

Does this mean that a new GNSS will be installed for every operator?

[pschafhalter]

Yes