robotecai / o3de-ros2-gem Goto Github PK

Is your feature request related to a problem? Please describe.
o3de should not auto-compute inertia and mass in PhysX rigid body component, since it is provided in URDF:

    <inertial>
      <mass value="50" />
      <origin xyz="0 0 0" />
      <inertia ixx="0.5" ixy="-0.02364" ixz="-0.1197" iyy="1.7386" iyz="-0.001544" izz="2.0296" />
    </inertial>

Describe the solution you'd like
Correctly load inertia parameters from URDF and apply it to rigidBodyConfiguration, with disabled m_computeMass, m_computeInertiaTensor.

Currently, all components are in the Miscellaneous category.

We need to move it to the ROS2, add

->Attribute(AZ::Edit::Attributes::Category, "ROS2")

in the class reflection.

Here:
https://www.o3de.org/docs/user-guide/gems/reference/overview/

Communicate first whether this is desired. Link / do not copy

@piotr-zyskowski-rai please design and fill in the requirements. A starting point:

• Create a camera component
• Acquire frames from a given transform at a determined rate
• Support multiple cameras in the scene
• Investigate performance
• Publish raw image, visible in RViz
• Publish camera info message
• Enable setting of FoV
• Enable setting of resolution

Create visual models for lidar, IMU and camera.

• select a representative type used in robotics.
• either acquire 3D model (only if license is fully permissive) or create one based on specs and images
• prepare mesh and textures
• add a collider (important - this can be skipped for now for a lidar)
• pack into an o3de prefab which is easy to look up.

(For each sensor):

• lidar
• camera
• IMU

Camera preview in rviz2 should not include lidar points visualised in o3de

Is your feature request related to a problem? Please describe.

Users would like to import Robot Definition files into simulations with o3de. Parsing and generating model from URDF is much better than trying to replicate it in supported formats.

Describe the solution you'd like
URDF file can be placed into Asset directory of a Project/Gem. They will be handled by the Asset Processor resulting in models/prefabs which can be added to the scene.

• Importing: .urdf files
• For basic support:
  • geometry
    • primitives
      • box
      • cylinder
      • sphere
    • meshes
  • material
    • color
    • textures
  • colliders
  • joints
    • dependency tree
    • static
    • dynamic
• Advanced support
  • handling scripting such as sensors (TBD)
  • exporting to URDF.
• An example included in the Gem

Old issue: o3de/o3de#8483

Bug description
The problem manifest itself when the user tries to reload URDF and select overwrite.
To Reproduce
Steps to reproduce the behavior:

1. Go to 'Robot importer'
2. Click on 'Load'
3. Select URDF (even on minimal urdf)
4. Optionally remove model from scene
5. Go to 'Robot importer'
6. Click on 'Load'
7. Select the same URDF once again.
8. Editor crashes

Expected behavior
The prefab should be rebuild and model should be changed in the scene.

Test environment

• OS: Ubuntu 22.04
• ROS: Humble
• ROS2 Gem state

Minimal URDF:

<robot name="test">

   <link name="base">
       <inertial>
       <origin xyz="0. 0. 0."/>
       <mass value="1."/>
       <inertia ixx="1." ixy="0." ixz="0." iyy="1." iyz="0." izz="1."/>
       </inertial>
       <visual>
           <origin rpy="0 0 0" xyz="0 0 0"/>
           <geometry>
               <box size="1 1 1"/>
           </geometry>
       </visual>
       <collision>
           <origin rpy="0 0 0" xyz="0 0 0"/>
           <geometry>
               <box size="1 1 1"/>
           </geometry>
       </collision>
   </link>
</robot>

ROS2 publishers are sources of robotic data and are described by topic name and namespace, Quality of Service settings and publishing frequency. Currently, these are not encapsulated but included in SensorConfiguration. This is not ideal since we would like to easily support multiple publishers per sensor (e.g. Camera sensor).

The goal is to create Components and classes to support simulation of movement of diverse types of robot mobile bases. The focus in this task should be narrowed down to the type required by the MS2 demo (a four-wheeled, Ackermann drive type), with only rudimentary analysis of other types to understand what generalizations might be useful for the design.
This task should include the following items:

• Domain research, including available open-source solution (PhysX vehicle Gem, others) and solutions in other simulators.
• Design of components and classes. How would a developer use the feature?

Outcomes:

• Document capturing useful knowledge of how this feature is designed in existing solutions, comparison of major advantages and weaknesses.
• First design document
• Accepted design document, after a review.
• Finally, a set of issues capturing implementation of the proposed design (some issues can be outside of MS2).

Bug description
URDF revolute joint has its rotation axis around 'Z' axis of parent body.
ROS2 Gem URDF importer creates PhysX hinge joint with rotation axis pointing into wrong direction.

To Reproduce
Steps to reproduce the behavior:

1. Import URDF to Gazebo and from 'View' tick 'Joints'
2. Import UDRF to o3de Editor and select entity with hinge joint
   Expected behavior
   The rotation axis should point into the same directions.
   Limits should be applied in the same place.

Screenshots / videos
o3de:

Gazebo:

Here is shown URDF.

Test environment

• OS: Ubuntu 20.04
• ROS: Galactic

Introduced in #26

To reproduce, add a Lidar component, save, close and open the Editor again. There will be 4 publishers in the collection instead of one.

After changing any of QoS settings in Lidar Sensor component, saving and closing the Editor, running it Again - QoS settings are restored to defaults.

All the "build" things could be moved out of the class to a separate one, to encapsulate this behavior.

likely we could do away with m_colliders being a shared_ptr if we do that.

Originally posted by @adamdbrw in #142 (comment)

Bug description
We try to import URDF with some error (e.g. that attached).
The editor crahes

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Robot Importer'
2. Click on 'Load'
3. Choose the URDF with error (e.g. joint with the same name)'
4. Message box appears saying 'Failed to parse ....'
5. After clicking OK the Editor shuts down

Expected behavior
It would be nice to inform user about problem with some GUI message, this crash is not beneficial.

Screenshots / videos

Module: Success!

Error:   joint 'ups_again' is not unique.
         at line 194 in /home/michal/ros2_ws/src/urdfdom/urdf_parser/src/model.cpp

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

Test environment

• OS: Ubuntu 22.04
• ROS: Humble

Additional context
The URDF used to trigger this behavior
https://gist.github.com/michalpelka/53daa7300c9fe5efaffca96b61590aae

Currently, only one publisher per sensor is enabled. We would like to support multiple publishers per sensor. As a prerequisite to this task, #14 is required.

The goal is to verify the O3DE’s ability to simulate the physics required by a mobile robot and describe the issues encountered.

The task includes the following items:

• A simple proof of concept project
• Description containing the list of encountered issues and workarounds

Outcomes:

• The proof of concept project can be found in this repository (ask for access).
• The list of encountered issues and workarounds can be found in this document (ask for access).

Dynamic transforms are used to inform robotic system about relationship between two or more frames which change position and orientation in relationship to each other. For example, a moving robot will move it's base frame (base_link) in relationship to global frame ("world" or "map). Similarly, a mobile robotic arm will have a dynamic transform in relationship to robot / arm base.

Currently, only static transforms are published. Unlike static transforms, dynamic transforms need to be published each frame (each time they change). Also, they use a different topic "tf" (as opposed to "tf_static") and different publisher entity. The behavior can be captured in TransformPublisher, which already contains logic to compute the transformation, but only does so once and for static transform broadcaster.

The task is to extend this logic and also add a boolean m_publishTransform field to ROS2FrameComponent to control whether transforms where this frame is a child frame are published.

The goal is to verify the O3DE’s ability to simulate the physics required by a manipulator and describe the issues encountered.

The task includes following items:

• A simple proof of concept project
• Description containing the list of encountered issues and workarounds

Outcomes:

• The proof of concept project can be found in this repository (ask for access).
• The list of encountered issues and workarounds can be found in this document (ask for access).

The ROS2 Frame of dynamic entities with namespaced frame name are not published correctly for non-topLevel entities.

Expected Behavior

Dynamic transform between root frame odom and frame base_link2 in Default namespace for non-topLevel entity with name Robot should be set up as geometry_msgs::msg::TransformStamped with

t.header.frame_id = "odom";
t.child_frame_id = "Robot//base_link2";

Actual Behavior

Dynamic transform between root frame odom and frame base_link2 in Default namespace for non-topLevel entity with name Robot is set up as geometry_msgs::msg::TransformStamped with

t.header.frame_id = "odom";
t.child_frame_id = "base_link2";

Example

• way to filter out ray-cast data and pass a filter Entity
• a good default behavior
• a combo box to select "This entity (self)", "No filter" or "Custom entity".

Populate with:

• User Guide
• Doxygen generated documentation
• Useful links

Only a subset of possible strings is valid for ros2 names for topics, frames and namespaces. Currently, when invalid names are inputted, we get no warning, but a runtime exception occurs when creating ros2 entities (e.g. publisher with invalid topic). We would like to improve this by lifting ros2 validation up to when the user inputs names.

We want to validate following values:

• Namespaces
• Topic names
• Frame names

Is your feature request related to a problem? Please describe.
We would like to have components, communication buses and algorithms to realize vehicle dynamic in a four wheeled vehicle.

Describe the solution you'd like
The ROS2RobotControlComponent handles subscription of control messages. It should abstract out handlers of these messages, which are controllers, translating ROS 2 command into a set of inputs to the vehicle model.

Describe alternatives you've considered
Restoring and extending PhysX vehicle Gem. This remains a valid solution since the implementation will modular and easy to reuse / replace.

Additional context
Follows the design

In case there are multiple robots spawned in a simulation subscribing to different motion control topics if the movement control command is send to one of them, all the robots will move if the addressed robot ROS2 Robot Control module has "Broadcast bus mode" enabled.

To Reproduce

1. Run Ros2WarehouseDemo Editor
2. Instantiate second "Robot.prefab" in the level tree
3. Detach one of the prefabs
4. Change the name of "/cmd_vel" topic of the entity created by detaching prefab in ROS2 Robot Control configuration
5. Enable "Broadcast bus mode" in ROS2 Robot control module of one of the robots
6. Start simulation
7. Using "rqt robot steering" send command message to the topic subscribed by the robot with "Broadcast bus mode" enabled
8. Notice how both robots are moving
9. If the message is send to the topic subscribed by the robot with "Broadcast bus mode" disabled only this robot moves.

Expected behavior
Only the robot subscribing to the topic to which the message is send moves even if "Broadcast bus mode" is enabled.

Use Doxygen configuration for o3de.

Mobilize the robot

To be detailed

Transforms cause conflict on message types with RViz2. TransformBroadcaster should be used instead of a publisher.
Also, child frame is empty (this was caused by an untested change to std::move and C&P).

A convenient, generic way to spawn robots in a specified place.

Update: task is now in Milestone 2, as this is needed to show scaling up.

However, please implement only minimal feature set focused on the demo - and create General Backlog issues for the remaining work.

Bug description
The problem show itself when the user load URDF (minimal example) and tries to change level in o3de Editor.

To Reproduce
Steps to reproduce the behavior:

1. Import minimal URDF
2. Click File >> Open Level >> choose different level. In dialog click Close without saving
3. Observe o3de Editor crashes.

Expected behavior
Swift change to other level

Test environment

• OS: Ubuntu 22.04
• ROS: Galactic

Additional context
The problem is persistent in its nature. The Editor crashes with such scenario:

1. Import minimal URDF
2. Click File >> Open Level >> choose different level. In dialog click Close without saving
3. Save scene and close
4. Open editor, choose level with imported robot.
5. Click File >> Open Level >> choose different level. In dialog click Close without saving
6. Observe o3de Editor crashes

This issue can be linked with #164 .
Minimal URDF:

<?xml version="1.0"?>
<robot name="myfirst">
  <link name="base_link">
    <visual>
      <geometry>
        <cylinder length="0.6" radius="0.2"/>
      </geometry>
    </visual>
  </link>
</robot>

Bug description
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Checkout urdf_importer
2. Try to build a Editor of a project that has ros2-gem activated.
3. See error:

In file included from /home/michal/github/o3de-ros2-gem/Code/Source/RobotImporter/URDF/CollidersMaker.cpp:9:
In file included from /home/michal/github/o3de-ros2-gem/Code/Source/RobotImporter/URDF/CollidersMaker.h:11:
In file included from /home/michal/github/o3de-ros2-gem/Code/Source/RobotImporter/URDF/UrdfParser.h:12:
/opt/ros/humble/lib/x86_64-linux-gnu/urdfdom/cmake/../../../../include/urdfdom/urdf_parser/urdf_parser.h:87:7: error: cannot use 'throw' with exceptions disabled
      throw std::runtime_error("The version attribute should be in the form 'x.y'");

Issue is caused by 3rd party changes here:
https://github.com/ros/urdfdom/blob/humble/urdf_parser/include/urdf_parser/urdf_parser.h where expection were use for assertion.

Test environment

• OS: Ubuntu 22.04
• ROS: Humble

Crash occurs with Lidar component in the scene. It has been pinpointed to the AZStd::map member serialization. The issue occurs when there is at least one publisher, and only when the publisher is held as a AZStd::shared_ptr as opposed to by value.

To replicate:
Run a test project, add a Lidar Component to the scene. Play the simulation. Press escape key. The simulation crashes instead of stopping.

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f926b9e3859 in __GI_abort () at abort.c:79
#2  0x00007f926ba4e29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f926bb78298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007f926ba5632c in malloc_printerr (str=str@entry=0x7f926bb764c1 "free(): invalid pointer") at malloc.c:5347
#4  0x00007f926ba57b5c in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4173
#5  0x00007f9174096eb1 in deFileComponentELb1ELb0EEE () from /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/Ros2WarehouseDemo/build/linux/bin/profile/libROS2.Editor.so
#6  0x242b6b81b99dff00 in ?? ()
#7  0x00007f91685614e0 in ?? ()
#8  0x0000560e46144fd0 in ?? ()
#9  0x00007f917407a149 in orComponentIdELb1ELb0EEE () from /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/Ros2WarehouseDemo/build/linux/bin/profile/libROS2.Editor.so
#10 0x0000560e46144f78 in ?? ()
#11 0x0000560e3b9cf9a0 in ?? ()
#12 0x0000560e43495800 in ?? ()
#13 0x0000560e46144fd0 in ?? ()
#14 0x0000560e460d3ea0 in ?? ()
#15 0x0000560e3a3cb5c8 in ?? ()
#16 0x00007f91740b4be2 in 4EXadL_ZNS1_28CreateFromColumnMajorFloat16EPKfEEXadL_ZNKS1_25StoreToColumnMajorFloat16EPfEEXadL_ZNS_19GetTransformEpsilonEvEELm16EE4LoadEPvRNS_2IO13GenericStreamEjb ()
   from /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/Ros2WarehouseDemo/build/linux/bin/profile/libROS2.Editor.so
#17 0x242b6b81b99dff00 in ?? ()
#18 0x0000560e46144f78 in ?? ()
#19 0x0000560e43495800 in ?? ()
#20 0x00007f91740b4c5b in xclusionList14DoesPassFilterERKNS_12InputChannelE () from /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/Ros2WarehouseDemo/build/linux/bin/profile/libROS2.Editor.so
#21 0x242b6b81b99dff00 in ?? ()
#22 0x242b6b81b99dff00 in ?? ()
#23 0x0000560e399a9700 in ?? ()
#24 0x00007f92673d9908 in AZ::Entity::Reset (this=0x560e46144ff8) at /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/o3de/Code/Framework/AzCore/AzCore/Component/Entity.cpp:122
#25 0x00007f92673d99c5 in AZ::Entity::~Entity (this=0x560e460d3ea0) at /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/o3de/Code/Framework/AzCore/AzCore/Component/Entity.cpp:97
#26 AZ::Entity::~Entity (this=0x560e460d3ea0) at /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/o3de/Code/Framework/AzCore/AzCore/Component/Entity.cpp:96
#27 0x00007f92692b453e in std::default_delete<AZ::Entity>::operator() (this=<optimized out>, __ptr=0x2) at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:85
#28 std::unique_ptr<AZ::Entity, std::default_delete<AZ::Entity> >::~unique_ptr (this=0x560e3a3cb5c0) at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/unique_ptr.h:361
#29 AZStd::Internal::destroy<std::unique_ptr<AZ::Entity, std::default_delete<AZ::Entity> >*, std::unique_ptr<AZ::Entity, std::default_delete<AZ::Entity> >, false>::range (first=0x560e3a3cb5c0, 
    last=0x242b6b81b99dff00) at /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/o3de/Code/Framework/AzCore/./AzCore/std/createdestroy.h:61
#30 AZStd::vector<std::unique_ptr<AZ::Entity, std::default_delete<AZ::Entity> >, AZStd::allocator>::~vector (this=0x560e434958b0)
    at /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/o3de/Code/Framework/AzCore/./AzCore/std/containers/vector.h:341
#31 AzFramework::Spawnable::~Spawnable (this=0x560e43495800) at /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/o3de/Code/Framework/AzFramework/./AzFramework/Spawnable/Spawnable.h:183
#32 0x00007f92692b473b in AzFramework::Spawnable::~Spawnable (this=0x560e43495800)
    at /home/pjaroszek/projects/robotec/tasks/o3de/ros-gem/o3de/Code/Framework/AzFramework/./AzFramework/Spawnable/Spawnable.h:183

Similar to Gazebo features (OpenCV might be helpful)

Currently the user can see Lidar Sensor Component visualization only if they run rviz2 alongside. We would like to visualize point cloud in the simulation itself for quick debugging, sensor positioning, etc.

Subtask:

• Enable toggling of sensor visualization through SensorConfiguration

RobotControl should add a topic namespace similarly to sensors - like ROS2LidarSensorComponent.

However, sensors add namespace by inheriting from ROS2SensorComponent which is not applicable to RobotControl to say the least.

A more appropriate solution should be compiled here.

If possible and justified, remove the ROS2 prefix in the class names.

Is your feature request related to a problem? Please describe.
Correct creation of joints from URDF.

Describe the solution you'd like
Colliders should be created for all entities that has joints.
Colliders should be created with EditorShapeColliderComponent instead of EditorColliderComponent

We would like to be able to toggle publishing for selected sensors. By default they should be publishing.

Currently, the field of "Publishing Enabled" of SensorConfiguration is not respected. The implementation would handle it respecting the Activate() and Deactivate() design.

Following work in o3de/o3de#8481, the improvements are needed for realism and flexibility:

• Introduce a choice of implementation for each model (available implementations as Combo box)
• Implement one realistic Lidar model (with correct distribution and ray directions, frequency and firing range)
• Customized settings such as starting points for rays, distance from reference point, simulating rotating mirror etc.
• Add query for supported field (for selected implementation) to the API

For development branch to start:

• Job: generate documentation
• Run some code checks - linters (clang-format), copyright
• Job: compilation

To be detailed

To be done after the Gem completed in Milestone 1 is tested & validated.

Excerpt for slack conversation (thanks to @AMZN-alexpete):

• Add or update the origin_uri field of gem.json with the final direct download url for the gem
• Zip up the Gem
• Generate the sha256 for the gem .zip and add it to the sha256 field in a copy of the gem.json file
• Add the URI for the folder where the gem.json is to be uploaded to repo.json file in the gems list e.g. if destination of gem.json is https://example.com/gem.json use https://example.com/
• Upload the repo.json, gem.json and gem .zip

Here's an example:
PopcornFX repo url (what a user adds to Project Manager): https://downloads.popcornfx.com/o3de-repo
PopcornFX repo.json location (obtained by appending repo.json to the above url): https://downloads.popcornfx.com/o3de-repo/repo.json

{
    "repo_name":"PopcornFX",
    "origin":"Persistant Studios",
    "repo_uri": "https://downloads.popcornfx.com/o3de-repo",
    "summary": "Persistant Studios Repository for the PopcornFX Gem.",
    "additional_info": "",
    "last_updated": "2022-04-14",
    "gems": [
        "https://downloads.popcornfx.com/o3de-repo/PopcornFX-2.9",
        "https://downloads.popcornfx.com/o3de-repo/PopcornFX-2.12"
    ]
}

Two gems are listed inside the repo and by appending gem.json to each url we get URL to each gem's gem.json file.
e.g. for https://downloads.popcornfx.com/o3de-repo/PopcornFX-2.12 you get https://downloads.popcornfx.com/o3de-repo/PopcornFX-2.12/gem.json

{
    "gem_name": "PopcornFX",
    "display_name": "PopcornFX",
    "license": "Community",
    "license_url": "https://www.popcornfx.com/popcornfx-community-license",
    "origin": "Persistant Studios - popcornfx.com",
    "repo_uri": "https://downloads.popcornfx.com/o3de-repo",
    "origin_uri": "https://downloads.popcornfx.com/o3de-repo/PopcornFX-2.12/O3DE_PopcornFXGem_v2.12.1_Win64_Linux64_Mac64.zip",
    "sha256": "03dc2586a366fa3aa96a95b31774359c6bd3d51a8bab91df3e32b34c134d0f24",
    "version": "2.12.1",
    "last_updated": "2022-04-14",
...
}

The origin_uri field points to the location where the gem .zip is: https://downloads.popcornfx.com/o3de-repo/PopcornFX-2.12/O3DE_PopcornFXGem_v2.12.1_Win64_Linux64_Mac64.zip
The sha256 contains the sha256 for that .zip

Currently, namespaces are handled in a very basic way, where user can input namespace to any ROS2 Frame Component. However, they need to meet the following requirements:

• Hierarchical composition (compose also using parent frames for nested namespaces)
• Select either "empty", "generated from entity name" or "custom". Implement Editor behavior and logic accordingly
• "empty" by default, except top-level frame (Frame Component with no parent), which is "generated from entity name"
• Implement generation from entity name, mining adherence to ros2 naming principles (see #7)
• namespace edit text field is only visible to edit when "custom" is selected

Converting URDF to .fbx and delegating it to the Asset Processor, which we were aiming to accomplish, would not be sufficient due several issues:

1. Format domain differences
2. Incompleteness of URDF information
   1. Some user input / decisions are required
   2. tags extend the format and can be partially used, but we still need some choices
   3. Issue with plugins - no clarity on best default behavior

Instead, a solution similar to Isaac Sim URDF importer could be better in terms of UX.

As such, this new task has the following steps:

1. try out Isaac Sim importer, evaluate pros and cons of this approach and how similar solution could be used in O3DE.
2. Create a first version of importer, which does nothing semantically, but:
   1. Adds a menu item which can be selected to
   2. Open a file dialog which allows selection of URDF file
   3. Debug-displays top-level nodes extracted from the file
   4. There is a button which, when clicked, completes the process, and
   5. Creates a prefab containing one entity with a cube. Entity name should be same as in the "robot" tag (e.g. ).

Add QoS to sensor configuration, at least support these values:

• Best Effort / Reliable
• Keep Last Depth History

Default to Best Effort, Keep Last 10. Please note that QoS should be a part of Publisher abstraction that is due to emerge from #14

Related tasks:

• #182
• #181
  Whether this task is required depends on whether it would be easier for us to realize the controller within the ROS 2 stack or in the simulation.

Following https://github.com/o3de/sig-core/blob/main/governance/API-Ref-Guidelines-Update.md.

Is your feature request related to a problem? Please describe.
The user would benefit from easy switching between manual and autonomous mode of control.

Describe the solution you'd like
A certain user input (such as keyboard key "M") would switch between manual and autonomous mode. The vehicle should behave identically with same inputs to the model, regardless of whether they are manual or autonomous system inputs.

The user will, for the first version, use a predefined set of controls (but able to change them using the O3DE standard Input Component and input map)

Describe alternatives you've considered
Switching without a dedicated key - when any input from the user is given. The vehicle would return to autonomous mode after a timeout without any inputs from the user. However, this solution would not be good if the user would like to keep manual control without providing inputs for some time.

Additional context
Following the design #144.

Is your feature request related to a problem? Please describe.
xacro generates absolute path from xacro file:
Xacro :

 <mesh filename="file://$(find my_robot_description)/meshes/base_link.stl" scale="1 1 1"/>

URDF:

<mesh filename="file:///home/michal/ros2_ws/install/my_robot_description/share/my_robot_description/meshes/base_link.stl" scale="1 1 1"/>

Describe the solution you'd like

• I recommended to strip path to relative, since the o3de get assets from manager not from command line
• Or, simply provide the user with concise information that it is not supported.