Support for Ubuntu 24.04#9478
Draft
berndgassmann wants to merge 45 commits intocarla-simulator:ue4-devfrom
Draft
Support for Ubuntu 24.04#9478berndgassmann wants to merge 45 commits intocarla-simulator:ue4-devfrom
berndgassmann wants to merge 45 commits intocarla-simulator:ue4-devfrom
Conversation
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.
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
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
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
adea437 to
7a5dbfa
Compare
Instead of /carla/map /carla/world_info is published as was done in original ROS bridge since quite some time. Ensure, that the map data is quieried within ProcessMessages() Limit history size to 1
Make publisher transient local
Because it's too large AND incorrect for animated vehicles. Would require more sophisticated handling to make it proper published in a separate topic. Ensure vehicle telemetry publisher publishes updates. Add carla_version to CarlaWorldInfo. Add trigger_volume to TrafficLightPublisher and fix publishing of wrong entry in TrafficLightsPublisher
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
7a5dbfa to
b9a86d8
Compare
This reverts commit c9087a7.
Fix: Always publish TFs of sensors Previously TFs of sensors were only published if subscribers were connected, because TF publishing for sensors relied on active sensor streams. Moved sensor handling code from ROS2 class to UeWorldPublisher to be able to publish TFs of sensors while updating the actors when required. Fix: Consider rotation on ROS2 SpawnObject calls Fix: Ensure topics (i.e. rarely updated with transient local) are actually published at DDS level, even if no subscribers are connected at publishing time Fix: Publish also the sensor data with transient local to be most compatible with any receiver configuration. I.e. ensure receivers are able to apply a history size to prevent from frame drops on high system loads. Fix: Internal order on object publishing: first update the object data, then publish (previously data of the last frame were published) Fix: Consider ros_frame_id and ros_publish_tf blueprint parameters Added Verbose Logging and moved logs recurring on every frame to verbose Added publishing of EnvironmentObjects. Allow more flexible Object publishing to support dynamic objects, barely changing dynamic objects (traffic signs, lights) as well as static Environment Objects. Replaced publishing of object data of individual traffic_lights/signs by a grouped object publisher for those (commented the old individual publishing behavior by #ifdef) and removed the covariance object publishing version of these. Expand CarlaActorInfo.msg data to give the user more insights into actor configuration. Expand CarlaEgoVehicleTelemetryData.msg to transport the vehicles light state flags
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
b9a86d8 to
86c2e83
Compare
Already register the sensor-actors when collecting the sensor information to ensure respective parent sensors are already registered at construction time of the actual sensor publisher. This can happen if sensors are nested in some hierarchy. Fix emulated actor name definition of EnvironmentObject that the base_type reflects the type of the object (car, traffic_light, etc.) instead of the object_type. Now it is identical to the other actors.
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
86c2e83 to
f987558
Compare
carla_fastdds library didn't set the server definitions Make foonathan_memory provider compilation more robust (v1.3.2 introduced FOONATHAN_MEMORY_FORCE_VENDORED_BUILD parameter which is not present in v1.3.1). In some cases didn't checkout the sources.
In a previous commit where the Quaternions were introduced to support ROS conversion later on, the Rotator rotations were adapted to perform left-handed rotations to match the behavior of Quaternions in a left-handed system in a mathematical manner. But the original CARLA code from 0.9.16 was totally correct on performing rotations using the Rotator, since Unreal Rotator has a very special definition of rotation directions: performing left-handed rotation for yaw component, but right-handed rotations for the other two axis. This commit reverts the behavior of the Rotator and adapts the Quaternion <-> Rotator conversion: roll and pitch have to be negated when converting Rototar to Quaternion and vice-versa. To ensure geom::Rotator and geom::Quaternion behave exactly as their Unreal counterparts, the unit test have been expanded and the expected results within taken over from Unreal calculation results. The rotation matrix rotations are verified within that test, too.
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
f987558 to
6d1f13f
Compare
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
6d1f13f to
0d10212
Compare
In the previous commit on fixing the Fix Quaternion <-> Rotator conversion within CARLA, on the ROS2 branch one intermediate file slipped in introducing wrong roll conversions. Reverting to the previous state.
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
0d10212 to
9a3d659
Compare
Since in most cases sensor relative transforms are static, these are published to the /tf_static topic to reduce the load on /tf topic.
This enables the service call to wait with the (success) response until the new episode was actually started which finally allows callers to postpone further actions until the game is running as expected.
Transport upper 32 bit of the environment object ID via Object.msg classification_age member to allow alignment with the CarlaActorList actor-id.
Mainly configure writer and reader QoS and keep the topic and publisher QoS to their defaults. On KEEP_ALL_HISTORY_QOS adapt the DDS recource limits instead of the history.depth parameter to have an effect. Services use KEEP_LAST_HISTORY_QOS and volatile durability; the writer pushlishes in sync mode to ensure the service responses are passed immediately to the middleware and have precedence over sensor data. Some smaller fixes.
using fastcdr 2.3 and fastddsgen 3.3.2
Especially publish first TF, then clock followed by the rest. Ensure some publisher write in synchronous mode to prevent from publishing delays because of buffering. Ensure all TF data is published, before the sensor data.
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
9a3d659 to
1939944
Compare
Add missing speed component to the message.
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
1939944 to
c15687d
Compare
Vehicle and Walker publisher publish their odometry-twist in local coordinate frame and cannot just reuse the data from object publisher. Furthermore, the IMU angular velocity is in radians while the actor dynamic state provide it in degrees. Therefore, the ROS2 type support considers such now: - Postpone conversion to ROS values on output side to allow correct rotations within CARLA coordinate frame for realtive values - Explicitly differentiate between absolute and relative ROS values - Explicitly differentiate degree and radian input - Merge Speed/Twist into AcceleratedMovement interface Make vehicle info wheel positions relative, as it's published only once at the startup. Due to the relative nature of this it is good to keep the frame_id to the vehicle-frame (carla_ros_bridge had this set to "map"). Also the acceleration then makes sense to select the relative one (carla_ros_bridge had that one in map-frame). As an exception to this, the orientation is still in respect to the map, otherwise pretty useless being zero.
If the server-queries on additional sensor data is perfomred within the ProcessMessages() step, the simulation did not yet tick, therefore the states from the last frame are quieried. Moving these to the UpdateSensorDataPreAction() step accesses the data after the current physics step was performed.
Synchonize the publishing of UePublisher::Publish() calls to ensure that the data was properly updated before at UpdateSensorDataPostAction() and check after sensor data update if late publishing has to be performed.
Reduce the time CARLA is blocking the rendering thread and locking Unreal resources by moving the calls for streaming the data into a background thread.
CARLA is compiling under Ubunut 24.04 without the need of an Ubuntu based clang installation. CARLA server libraries are compiled with UE4 Toolchain (using clang-10.0 from UE4). CARLA client libraries are compiled with stock g++-13 Fix GCC-13 warnings - remove ; after MSGPACK_DEFINE_ARRAY() triggering a gcc warning - Fix some conversion warnings Remove clang only compile flags from client build. Ensure g++ warnings on PythonAPI build don't trigger errors. Rename some folder and variables to reflect client/server instead of misleading stdlib abreviations Pytorch Build uses Server toolchain file instead of Client one Provide boost in client and server variant Reuse CMAKE toolchain files where possible to ensure compile settings are common for the dependent libraries. Ensure python packages are installed in system path if no virtual environment is used. Build OSM2ODR only if required.
berndgassmann
force-pushed
the
mai/ue4-ubuntu-24.04
branch
from
c15687d to
aceabfa
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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
Fixes #
Where has this been tested?
Possible Drawbacks
Need to wait until PR #9451 is merged since it's built upon that one.
Then will be able to rebase.
This change is