Refactor ROS2 support #2
Open
Conversation
This file contains 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
ROS2: - Make use of base classes to remove duplicated code - ros2 UEPublisher classes for sensors access directly the data stream already prepared for the TCP-Clients - Introduced additional publishers for traffic-signs/lights/v2xsensor/actor_list, etc. - Introduced a basic set of ros2 service calls to control Carla CarlaServer uses rpc::RpcServerInterface to communicate with TCP-Clients as well with the (integrated) DDS-Client EnableForRos: - Dynamic switching on ROS visibility is possible for all actors now - Default startup behavior is selectable by ROS2TopicVisibility parameter in DefaultGame.ini: If true, then all and every topic that is currently offered by the implementation is visible from the beginning. If false, then only the sensors/actors created via the Client- or ROS-Interface are visible by defaults. Others can be activated via EnableForRos() calls Introduced fine grained ServerSynchronization mechanism, where each client has the possibility to interact with the synchronization of the carla-server on their own. Especially the ROS interface provides means of a time window, the server is allowed to run. Like this, every client can prevent the carla-server to run too fast depending on their individual speed. There is no sync-master anymore. Every client decides for its own if it requires synchronization or not. Drawback of this change: some existing code might have to be changed (see removal of synchronous_master in generate_traffic.py).
and adapt SpawnObject() with blueprint msg data type
and adapt spawn_object_service response to old error behavior in returning -1.
the frame_id's must not start with "\"
And fix LoadMapService response
…sPublisher Adapt SynchronizationWindow naming to allow interpretation of CarlaSynchronizationWindowParticipantState content. Fix sychronization mechanism.
CarlaActorListPublisher publishes transient local since the updates are not regular. Ensured that Objects publishers also publish empty object lists if there are no objects at all.
This provides the pseudo.speedometer and pseudo.odom sensors for better backward compatibility and usability.
Such information was missing since ever in CARLA interface to the outside.
... because reuse of role name for that purpose is not a good idea.
berndgassmann
force-pushed
the
berndgassmann/rework_ros2_step_3_refactor_ros2_support
branch
from
ac49792 to
2aa0a6c
Compare
- qos history kind eprosima::fastdds::dds::KEEP_ALL_HISTORY_QOS - qos reliablility kind eprosima::fastdds::dds::RELIABLE_RELIABILITY_QOS - qos durability kind eprosima::fastdds::dds::TRANSIENT_LOCAL_DURABILITY_QOS for reader, writer, topic
berndgassmann
force-pushed
the
berndgassmann/rework_ros2_step_3_refactor_ros2_support
branch
from
2aa0a6c to
77b13d8
Compare
.. that it happes AFTER the sensor data was processed.
... instead of std::string to support binary data blobs.
V2X: - *V2XSensor: Using the actor object of the sensor itself to ensure the position offset of the sensor is used instead of some magical fixed vehicle height offset AND to allow sensors without an owner if these are palced within the infrastructure (V2I communication) as not every sensor will be attached to a vehicle! - Fix the ordering of V2X sensor actions in conjunction with ROS2 to allow clearing of the messages at the right point in time. - Fix UeV2XCustomSubscriber: take every message instead of every second SpawnObjectService: up to 5 retries on spawning of vehicles at random positions before giving up
... and fix endless loop in ROS2NameRegistry...
and remove not required vehicle and walker sync_subscriber, because every connecting publisher is treated independen at /carla/world/control/synchronization_window
… berndgassmann/rework_ros2_step_3_refactor_ros2_support
including enabling V2X Sensor within infrastructure without other actor required.
and make sensor publisher reliable by default to support more compatible reliable transport
…_prepare_libcarla' into berndgassmann/rework_ros2_step_3_refactor_ros2_support
… berndgassmann/rework_ros2_step_3_refactor_ros2_support
…_ros2_step_3_refactor_ros2_support
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.
ROS2:
CarlaServer uses rpc::RpcServerInterface to communicate with TCP-Clients as well with the (integrated) DDS-Client
EnableForRos:
Introduced fine grained ServerSynchronization mechanism, where each client has the possibility to interact with the synchronization of the carla-server on their own. Especially the ROS interface provides means of a time window, the server is allowed to run. Like this, every client can prevent the carla-server to run too fast depending on their individual speed.
There is no sync-master anymore. Every client decides for its own if it requires synchronization or not.
Drawback of this change: some existing code might have to be changed (see removal of synchronous_master in generate_traffic.py).
Description
Fixes #
Where has this been tested?
Possible Drawbacks
Drawback of this change: some existing code might have to be changed (see removal of synchronous_master in generate_traffic.py). But in the end it is getting much easier to work with multiple synchronization clients.
Also noted in the Changelog.