Extend ROS2 support Step 3: Rework ROS2 handling #9451
Conversation
This file contains hidden or 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
Introduced a fine grained ServerSynchronization mechanism, where each synchonization participant is treated independently and interacts with the synchronization of the carla-server individually. If a client is disconnected (or dies) the synchronization state of all participants registered via that client are dropped, i.e. the server will continue running in case the participants of that client were the only ones demanding synchronous mode. The synchronization interface provides means of a time window, up to which 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).
Update RPC lib version for windows build Ensure tick calls are ignored if sync mode is not active. And prevent client changes of fixed_delta_seconds triggering warning message.
berndgassmann
force-pushed
the
mai/ue4-extend-ros2-step3
branch
from
99dfc13 to
26a6111
Compare
Contributor
Author
|
Rebased to the (hopefully) fixed step2 commit. |
on non synchronous mode
This commit is extending the built-in ROS2 support of CARLA:
- the internal interface is simplified and object oriented to allow
easier ROS2 extensions in future and reduce code duplication
- the sensor/actor stream existing for the TCP counterparts are used
in a shared manner, which results in lower processing overhead and
requires little individual code changes for ROS2 within UE-sensors
- enable Boost and Asio exceptions for FastDDS to ensure properly
- additional service interfaces are provided to control CARLA directly
from ROS2 (Map, Blueprint and Episode handling, Spawn/DestroyObject)
- convenient interfaces previously available via carla_ros_bridge are
provided (e.g. pseudo sensors, object messages, traffic light/sign,
actor/sensor lists)
- new interfaces like e.g. CarlaVehicleTelemetryData, V2X,
SynchronizationWindow,...
- get detailed vehicle meshes as exact ground truth for e.g. LiDAR
perception
- Vehicle publisher implements a variety of individual publishers to
mimick also old ROS-bridge convenient publisher:
+ CarlaVehicleInfo
+ CarlaVehicleControlStatus
+ Speed
+ Odometry
+ Object
+ ObjectWithCovariance
+ VehicleTelemetryData
- Vehicle subscribers:
+ VehicleControlSubscriber
+ AckermannControlSubscriber,
+ SetTransformSubscriber
- use of c++17 to support std::sample() usage
- 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 (this allows for disabling
interfaces e.g. for leaderboard)
- ensure multiple service calls at once are working:
+ 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
- add set_transform() call to RGB Cameras
- add odometry publisher to walkers
- filter out invalid bounding boxes observed on a few traffic signs
using bounding box transmission within object data
berndgassmann
force-pushed
the
mai/ue4-extend-ros2-step3
branch
from
26a6111 to
3de7c09
Compare
Update telemetry data of VehiclePublisher within process messages step This ensures that the vehicle/wheel data in the engine can not be updated while gathering the data Improve object classification to match existing base-class blueprint patterns. Reduce some ROS2 log output severity
Contributor
Author
|
When this is merged, also the updated carla_msgs should be merged into the dev branch Then we should create also dev branch within the ros-bridge repository that we don't mess up the master with the development changes. After the carla_msgs have been merged I can update the ros-bridge PR with the correct carla_msgs commit here: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
Extend ROS2 support Step 3: Rework ROS2 handling
This commit is extending the built-in ROS2 support of CARLA:
easier ROS2 extensions in future and reduce code duplication
in a shared manner, which results in lower processing overhead and
requires little individual code changes for ROS2 within UE-sensors
from ROS2 (Map, Blueprint and Episode handling, Spawn/DestroyObject)
provided (e.g. pseudo sensors, object messages, traffic light/sign,
actor/sensor lists)
SynchronizationWindow,...
perception
mimick also old ROS-bridge convenient publisher:
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 (this allows for disabling
interfaces e.g. for leaderboard)
eprosima::fastdds::dds::RELIABLE_RELIABILITY_QOS
eprosima::fastdds::dds::TRANSIENT_LOCAL_DURABILITY_QOS
for reader, writer, topic
using bounding box transmission within object data
Where has this been tested?
Possible Drawbacks
Some features of the old ros-brigde are still not yet implemented
This change is