Describe the bug
There is an issue with light passing through the materials. When light is displayed in editor it can be seen at incorrect places with jagged edge. In right eye of VR it’s also displayed like that but for left eye the image is different which causes discomfort for the user. The issue occurs in both editor and when running level natively on Quest 2. Please refer to the attached video for more information.

Steps to reproduce
Steps to reproduce the behavior:

1. Build and launch OpenXRTest project.
2. Launch XR_Office level.
3. Look around the room at the line of connection between walls and ceiling.

Expected behavior
Light falling on a texture looks similar for both eyes.

Actual behavior
Light artifact is displayed on a wall when looking at connection line, the artifact looks different for left and right eye which causes discomfort for the viewer.

Video

Found in Branch
o3de:
Development (ba92844)
Development (5234076)
o3de-extras:
Development (3dee66e)

Desktop/Device:

• Device: PC
• OS: Windows
• Version: 10 Pro
• CPU: Intel Core i7 11700F
• GPU: Nvidia RTX 3070 LHR
• Memory: 32GB
• Oculus Quest 2

Is your feature request related to a problem? Please describe.
Multiplayer Template is currently using a custom built network player spawner.
Multiplayer Template should leverage the vanilla MP Gem as much as possible in order to avoid maintaining custom logic and make it an easier demo for users to start with and learn from.

Describe the solution you'd like
Replace the current custom MP Spawner with the built-in Multiplayer gem SimplePlayerSpawner component

Is your feature request related to a problem? Please describe.
It should be clear for the user how Robot Importer widget works and what are current limitations.

Describe the solution you'd like
A guide on how to import a robot.

Additional context
https://github.com/RobotecAI/o3de-ros2-gem/issues/163 work should reflect in this task.

URDF allows changing the origin of the rigid body using affine transformation (translation and rotation).
Currently, this is not applied during URDF import.

Describe the solution you'd like
I would like to have inertia applied correctly. It will need some research on PhysX gem, PhysX, and rigid body theory.
Test impact of the link transformation.

Describe alternatives you've considered
It seems that a simple matrix equation can be applied to rotate the inertia matrix, but it needs deeper research.

Additional context
https://physics.stackexchange.com/questions/637421/inertia-tensor-of-rotated-object

Bug description
TF Frame translation values are invalid when the chain of FrameComponents is broken within the single hierarchy.

If there is a prefab inside another prefab, and both of them contain a FrameComponents, the virtual container object between them breaks the translation between the components.

For example, if the robot prefab has the base_link frame and the sensor prefab inside the robot got sensor frame and is located in some (x,y,z) position, then the returned base_link -> sensor tf frame is (0,0,0) rather than (x,y,z).

To Reproduce
Steps to reproduce the behavior:

1. Create an empty prefab, lets call it vehicle
2. Add FrameComponent to that prefab - set the frame_id to base_link
3. Create another empty prefab, lets call it sensor
4. Add FrameComponent to the sensor prefab, set frame id to sensor
5. Insert sensor prefab into vehicle prefab
6. Add a local translation for sensor prefab, ie (1,0,0)
7. Run the scene
8. See the TF tree

Expected behavior
Tf sensor->base_link is (1,0,0).

Actual behavior
Tf sensor->base_link is (0,0,0).

Additional context
It is possible to hack and fix it by adding FrameComponent to the virtual container object - but that should not be possible anyway.

Validate if the name is compliant with o3de and ros2 standards.

The Multiplayer Template should be updated to support the client-server split.
See MultiplayerSample PR for reference: https://github.com/o3de/o3de-multiplayersample/pull/200/files#diff-11a483356bd054679e98c48ce32a764111e117cfa769b8a3abafd0044a142e73

Projection - so user knows where it is pointing.

1. Translucent square + rays
2. Preview window (optional, if it makes sense)

Bug description
All old static TF's are being published even if the scene is stopped or the name has changed

To Reproduce
Steps to reproduce the behavior:

1. Add FrameComponent with some namespace (namespace#1)
2. Hit play scene
3. Exit play mode
4. Change FrameComponent Namespace (namespace#2)
5. Hit play mode
6. Exit play mode

Expected behavior
No static tf's in ROS 2 environment

Current behavior
Both tf's with namespace#1 and 'namespace#2` are visible. Editor restart is required to get rid of them.

Global map handler would act as a singleton (another SystemComponent) and have several connected features and responsibilities:

1. Be configurable by user easily from the Editor (as for next points)
2. Hold map translation / rotation and placement in global frame (for example, GPS coordinates of origin)
3. Hold the name of global frame.
4. If odom frame is used with ground truth, remember first robot position and set it as odom.
5. To be discussed: hold static tf broadcaster (without knowledge of transforms, just exposing the publish interface). This is currently in ROS2SystemComponent.

Is your feature request related to a problem? Please describe.
Currently, ROS2SensorComponent (and thus, all sensors) uses AZ::TickBus::Handler for sensor behavior. This is sufficient for some sensors such as LIDAR and camera, but some sensors need to operate at higher frequencies (in kHz).

An important consideration is whether we are able to make measurement with such frequency, but we would like to enable such sensors if the user chooses to implement their behavior on top / aside of O3DE physics (compute with higher frequency than physics step).

New projects that are created using the MultiplayerTemplate won't have the prefab/NetworkRigidBodyCube.prefab.

Repro Steps

1. Open ProjectMananger
2. Create a new project using the Multiplayer Template
3. Open the new project folder in Windows and browse to the prefab folder
4. Notice what's included...

Expected Results
Project folder contains the NetworkRigidBodyCube.prefab

Actual Results
Project folder is missing NetworkRigidBodyCube.prefab
This is because NetworkRigidBodyCube.prefab is missing from template.json.

The vulkan glad lib in o3de was updated to use a multi-context version (o3de/o3de#10118) and functions gladLoadVulkanUserPtr, vkGetInstanceProcAddr, vkGetPhysicalDeviceFeatures and vkDestroyInstance don't exist in the glad vulkan header anymore. Since they are used by OpenXRVk it fails to compile.

Is your feature request related to a problem? Please describe.
Robot stacks often publish robot description, which is a configured and parsed URDF. This could be a basis for creating a necessary prefab, or using an existing one but applying the particular configuration. It would be good to support this since we otherwise have 2 independent sources of robot definition (imported URDF and published one).

Describe the solution you'd like
Add subscription to ROS 2 Spawner or System Component, which would create models for robot description packages (provided paths are visible). These would reuse code of urdf_importer.

Add noise to lidar sensor

Is your feature request related to a problem? Please describe.
The reflection is only rudimentary at the moment. We would like components to feel and look good.

Describe the solution you'd like

1. Make sure labels are correct and necessary (remove some noise). Set what should be collapsed by default.
2. Set a better layout for pid configuration.
3. Set ranges for input parameters.
4. Add some icons.

Describe alternatives you've considered
Creating dedicated Editor components for more custom behavior - but it is more work.

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

This feature was previously implemented using the interface Register(), but did cause errors

When NetworkPlayerMovement processes input to send across the network, the data is lost because the MouseAxis is in the range of [-1. 1] even though the user will move the mouse more than 1 or -1 pixels on screen during the game tick. This causes aiming to not be tied to how much I move the mouse, which is very confusing to players.

Please provide in the README:

• A clear description to the point of the repository
• How folks add gems or content here? Who owns accepting work on behalf of O3DE, whats the criteria etc?

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

The ROS2FrameComponent allows users to either specify namespace directly or to have it computed from entity name. In either case, the resulting namespace will be a compound of namespaces in the hierarchy. It would be useful if the user could see what the namespace will be, effectively, for each given Frame component. A read-only field with a correct update logic would be the best.

Validate fields in sensor configuration (such as frequency) - determine range and apply it

Is your feature request related to a problem? Please describe.
To improve user experience, it would be best to create Vehicle Dynamics components during URDF import. The vehicle would be driveable right after the import.

Describe the solution you'd like
Create Vehicle Dynamics components on import. These components should allow the vehicle to move around. Even if the movement is not perfect, it should be serviceable without additional intervention.

Describe alternatives you've considered
Not providing vehicle dynamics automatically. Either extending the Importer into a wizard (where the user follows the steps to create components) or just leaving it to the user.

Additional context
Vehicle Dynamics design RobotecAI/o3de-ros2-gem#144

Improve UX of ROS2 components in Editor. As a part of this issue, design & propose behavior first.

(also includes ROS2FrameComponent)

Currently, the lidar ignores layer by index.

Note: This work falls under improving lidar API

Is your feature request related to a problem? Please describe.
Currently, no targets would be built in the following scenario:

1. The user sourced ROS 2 Galactic.
2. The project was built with the Gem
3. The user sourced ROS 2 Humble
4. Built command is ran.

The ENV variable ROS_DISTRO is not considered a dependency, but it should.

Describe the bug
OpenXRTest project cannot be opened in Editor with -rhi=vulkan -openxr=enable flags and Oculus link established, as mentioned in https://github.com/o3de/o3de-extras/wiki/Build-and-Run-OpenXR-in-O3DE. Editor Launching screen is present in Oculus before a crash occurs. The issue originally was occurring on two machines DxDiag1.txt, DxDiag2.txt but after processing the assets before starting the project, it was fixed on one of them DxDiag1.txt. The issue did not occur on another machine at all DxDiag3.txt.

Additional details
Latest updates Windows 11 and latest Nvidia drivers are used. Testing performed with Oculus Link via both cable and air. XR gems have been registered and enabled in OpenXRTest\Registry\OpenXR.setreg.

Logs:
Editor.log
error.log
error.zip

Steps to reproduce

1. Complete O3DE system requirements. (https://www.o3de.org/docs/welcome-guide/requirements/)
2. Setup O3DE from Github (https://www.o3de.org/docs/welcome-guide/setup/setup-from-github/)
3. Complete Open XR setup (https://github.com/o3de/o3de-extras/wiki/Build-and-Run-OpenXR-in-O3DE)
4. Add and build the OpenXRTest project.
5. Enable OpenXR in OpenXRTest\Registry\OpenXR.setreg.
6. Establish Oculus link.
7. Attempt to launch the Editor with -rhi=vulkan -openxr=enable flags as mentioned in https://github.com/o3de/o3de-extras/wiki/Build-and-Run-OpenXR-in-O3DE.

Expected behavior
Editor launches with Oculus.

Actual behavior
Editor crashes after assets are processed.

Call Stack Trace:
25) 00007FFB7E2702E7 (KERNELBASE) : UnhandledExceptionFilter
24) 00007FFB7D94D6D8 (InProcessClient64) : (function-name not available)
23) 00007FFB7D94D321 (InProcessClient64) : (function-name not available)
22) 00007FFB806F5530 (ntdll) : memset
21) 00007FFB806DC876 (ntdll) : _C_specific_handler
20) 00007FFB806F241F (ntdll) : _chkstk
19) 00007FFB806A14A4 (ntdll) : RtlRaiseException
18) 00007FFB806F0F4E (ntdll) : KiUserExceptionDispatcher
17) C:\o3de-extras\Gems\XR\Code\Source\XRSystem.cpp (188) : XR::System::GetNumViews
16) C:\o3de\Gems\Atom\RPI\Code\Source\RPI.Public\WindowContext.cpp (208) : AZ::RPI::WindowContext::CreateSwapChains
15) C:\o3de\Gems\Atom\RPI\Code\Source\RPI.Public\ViewportContext.cpp (27) : AZ::RPI::ViewportContext::ViewportContext
14) C:\o3de\Gems\Atom\RPI\Code\Source\RPI.Public\ViewportContextManager.cpp (152) : AZ::RPI::ViewportContextManager::CreateViewportContext
13) C:\o3de\Gems\Atom\Tools\AtomToolsFramework\Code\Source\Viewport\RenderViewportWidget.cpp (66) : AtomToolsFramework::RenderViewportWidget::InitializeViewportContext
12) C:\o3de\Code\Editor\EditorViewportWidget.cpp (829) : EditorViewportWidget::SetViewportId
11) C:\o3de\Code\Editor\ViewPane.cpp (304) : CLayoutViewPane::AttachViewport
10) C:\o3de\Code\Editor\ViewPane.cpp (220) : CLayoutViewPane::SetViewClass
9) C:\o3de\Code\Editor\LayoutWnd.cpp (205) : CLayoutWnd::MaximizeViewport
8) C:\o3de\Code\Editor\LayoutWnd.cpp (515) : CLayoutWnd::LoadConfig
7) C:\o3de\Code\Editor\MainWindow.cpp (445) : MainWindow::InitCentralWidget
6) C:\o3de\Code\Editor\MainWindow.cpp (470) : MainWindow::Initialize
5) C:\o3de\Code\Editor\CryEdit.cpp (1740) : CCryEditApp::InitInstance
4) C:\o3de\Code\Editor\CryEdit.cpp (4006) : CryEditMain
3) C:\o3de\Code\Editor\main.cpp (32) : main
2) D:\github\3p-package-source\package-system\Qt\temp\src\qtbase\src\winmain\qtmain_win.cpp (97) : WinMain

1. d:\a01_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl (288) : __scrt_common_main_seh

Found in Branch
O3DE Development (522b935)
o3de-extras (3dee66e)

Desktop/Device:

• Device: PC
• OS: Windows
• Version 11
• CPU Intel i7-11700F
• GPU Nvidia GeForce RTX 3070
• Memory 32GB

RigidBodyTwistControlComponent is a very easy-to-use component that applies torque and forces to the robot body to simulate its locomotion.
It is a crude, but effective solution, however current locomotion entities (e.g. wheel) are stationary w.r.t. robot body.

Describe the solution you'd like
I would like to propose an extension to RigidBodyTwistControlComponent (e.g. in form of another component) that allows us to animate wheels. It will only affect the visual part of the simulation.
I think a solution would be beneficial for locomotion methods:

• simplified skid steering,
• simulate omnidirectional locomotion platforms (mecanum wheels)

The proposed component should observe the effective velocity of the robot. The main rigid body velocity should be fed through the linearized inverse kinematic model to obtain the rotation wheel. We should consider introducing inheritance here, where the base class can have an arbitrary Jacobian matrix (or other linearization), and there will be the implementation that will provide Jacobians for every supported locomotion scheme and expose its parameters (e.g. wheelbase)

ROS2Spawner responses with success without checking if the spawn was actually successful. It would be profitable to check it in some way. Probably using the m_completionCallback.

Describe the bug
Using Developer Runtime Features via Oculus Link causes issues when launching o3de project. The project and Asset Processor close on their own few seconds after splash screen. Oculus Quest2 is connected by a cable provided with the set and Oculus application shows that the headset is connected but not through USB 3.0. The issue occurs the same way when Quest2 is connected through Oculus Air Link (via Wi-Fi). Adding “-rhi=vulkan -openxr=enable” to command line when launching the editor does not impact the issue. Please refer to the attached videos for more information.

Steps to reproduce
Steps to reproduce the behavior:

1. Enter Oculus application.
2. Connect Oculus Quest2 to Oculus application.
3. Click on Settings in menu on the left.
4. In the top row of menu select Beta.
5. Enable Developer Runtime Features.
6. Open o3de Project Manager.
7. Open Editor for selected project.

Expected behavior
Level is rendered in a window on display and in the game mode. It is also rendered on Quest 2 as described here https://github.com/o3de/o3de-extras/wiki/Build-and-Run-OpenXR-in-O3DE#running-openxr-with-the-editor

Actual behavior
The project does not open. Asset Processor is closing a few seconds after splash screen is shown.

Video

Found in Branch
Development (181022c)

Desktop/Device:
• Device: PC
• OS: Windows
• Version: 10 Pro
• CPU: Intel Core i7 11700F
• GPU: Nvidia RTX 3070 LHR
• Memory: 32GB

Describe the bug
Project generation fails with a Gradle 7.0.2 error message related to not being able to compile settings file 'C:\o3de-build\android\settings.gradle' when running generate_android_project.py.

Full log file: GrandleOutput.txt

Steps to reproduce

1. Set up O3DE source engine. (https://www.o3de.org/docs/welcome-guide/setup/setup-from-github/)
2. Clone o3de-extras.
3. Register XR Gems to the engine. (https://github.com/o3de/o3de-extras/wiki/Build-and-Run-OpenXR-in-O3DE)
4. Add XR_Office project to the Project Manager.
5. Build XR_Office project.
6. Complete requirements for Android project configuration. (https://www.o3de.org/docs/user-guide/platforms/android/generating_android_project_windows/)
7. Open terminal in %Engine_path%\cmake\Tools\Platform\Android.
8. Run generate_android_project.py with appropriate flags.

Additional Details

--oculus-project flag was used for running generate_android_project.py, as Oculus testing was performed when issue was found.

Expected behavior
Command completes without errors.

Actual behavior
Project generation fails with the Gradle error.

Found in Branch
O3DE Development (181022c)
o3de-extras (d83f7f7)

Desktop/Device:

• Device: PC
• OS: Ubuntu
• Version 20.04
• CPU Intel i7-11700F
• GPU Nvidia GeForce RTX 3070
• Memory 32GB

Is your feature request related to a problem? Please describe.
Importer is currently in a very basic state in terms of user experience. We would like to improve user experience when importing robots.

Describe the solution you'd like

• The Importer GUI is neat and does not look like work in progress
• Typical pathways (things existing, missing, some common errors) are handled well, reducing chance of running into unpleasant behavior.
• The user is pointed to the Assets directory when importing
• The robot is spawned in a reasonable place. Consider adding a camera to the robot (overhead) and moving viewport there after the import.
• After import, inform about heuristics-base choices made by the importer and provide checklist for the user to guide them in the process - such as adding sensors, making sure the robot drives in the simulation, checking materials etc.

Describe alternatives you've considered
Importing URDFs automatically. This, however, poses multiple problems since we would like user to be aware of domain mapping issues as well as some heuristic choices we have made during the import (such as deducing drive type and populating vehicle dynamics components based on wheels).

Additional context
Create subtask for each item when starting to work on it with this task as a meta-issue. Create issues also for tasks which will be outside of milestone 2 - they will be handled with lower priority.

Is your feature request related to a problem? Please describe.
The created prefab has simple shapes (like box, cylinder, sphere) created as e.g. EditorSphereShapeComponent.
The created has option "Game view" disabled (see attached screenshot), so it is not visible after hitting CRTL+G.

Describe the solution you'd like
I would like to have properly drawn simple shapes in the game mode. Ideally without opacity.

Additional context
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>

Bug description
I have a scene with a 4-wheels vehicle on a simple box serving as a ground. The vehicle is controlled through Ackermann Controller. I have have two different setup (from now on COMPUTER-A and COMPUTER-B) in which I run the same simulation with the following difference:

COMPUTER-A has Ros2-Gem checked out at de2d1cdfa68310c6c0d885d65c0d62fa972a4a69 commit (1 dec)
COMPUTER-B has Ros2-Gem checked out at ba6a13a0f013f7c58bf5039ea08cca391014f09a commit (10 oct)

With COMPUTER-A when I move the robot (through a custom teleop_twist_keyboard node) it does not look smooth, but it is bouncing on the ground. That is something that does not happen with COMPUTER-B.

Did you modify the way the colliders and/or the Torque actuated on the wheels behave?

Test environment
Both COMPUTER-A and COMPUTER-B:

• OS: Ubuntu 20.04
• ROS: Galactic

COMPUTER-A:

• CPU: Intel Xeon Gold 5218
• GPU: Quadro RTX 5000

COMPUTER-B:

• CPU: 11th Gen Intel Core i9-11900K
• GPU: NVIDIA RTX A5000

According to this website the Xeon CPU has about 36% lower single-thread performance. However, I do not think this justifies the significant observed difference in performance.

The goal is to create Components and classes to support simulation of robot manipulators.
This task should include the following items:

• Domain research and analysis of simulation of manipulators 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).

ROS2 Frame Component represent a ros2 frame of reference and is suitable to handle joint types between different modules / parts of a robot. It currently only supports static transformation which are suitable for rigidly attached components (e.g. lidar box).

The type of transformation should also be decided based on the attached joint component (fixed joint - static, other joints - dynamic).

Is your feature request related to a problem? Please describe.
Currently, ROS2SystemComponent has API for broadcasting of transform, which is used internally through ROS2FrameComponent.
Publishing tf2 frames should be done through a single broadcaster, but it does not need to be a part of the System Component and should be separated out.

• while making the change, it might be useful to retain this API as the user might want to publish a custom transformation to ROS 2 ecosystem.

Running O3DE launcher/editor with openxr enable and no openxr device connected leads to a crash.

Steps:

• Build PC with a project that has XR and OpenXRVk gems enabled
• Without Quest2 connected to PC, run Editor or Launcher with the command line options: -rhi=vulkan -openxr=enable

Expected Result:
Editor/Launcher runs normally as if openxr was disabled.

Actual Result:
Editor/Launcher crashes

It should be checked if what was passed to the spawnable field of the spawner is really a spawnable.

One of the possible improvements to IMU sensor is to provide better accuracy of angular velocity and linear acceleration calculations.
To do that, there all calculations (especially on quaternions) should be done on double-precision representation (currently single-precision is used).

Steps:

• provide Quaternion class on the double with basic operations
• provide basic operations on Vector3 with double precision
• replace existing Quaternion class and operations on Vector3 in the current IMU implementation

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

Currently only specification of default materials with given colors is supported in URDF Importer. Textures are still supported if they are part of meshes.

This task involves implementing texture_filename handling in mesh visual tags of urfdom.

Start with analysing performance in two aspects:

• data acquisition
• data processing / publishing to ROS 2

ROS2 Components use frame and topic names to describe communication parameters. This is abstracted to ROS2 Sensor Component. As things are currently, the user might be confused as to what are the topic / frame names, considering namespaces are added.

To amend this,

• add a non-editable field displaying full name.
• display current namespace in ROS2Frames

Bug description
I've tried to import a robot description from this file :
https://github.com/husky/husky/blob/foxy-devel/husky_description/urdf/husky.urdf.xacro

To Reproduce
Steps to reproduce the behavior:

1. Checkout repository from Clearpath
2. Build ros2 workspace
3. Generate husky.urdf from husky.urdf.xacro with 'xacro'
4. Adjust path in husky.urdf to relative and copy to assets catalog 'mesh'
5. Import URDF
6. Start the simulation

Expected behavior
The robot should be dynamic, it seems to be static.

What happened
The structure of URDF is as follows:

The base_link node does not have a rigid body component. Its child called 'inetrial_link' has it instead. After adding rigid body component with a default config the whole robot becomes dynamic

Test environment

• OS: e.g. Ubuntu 22.04
• ROS: Humble

Additional context
Add any other context about the problem here.

Currently, only VK_FORMAT_B8G8R8A8_UNORM, VK_FORMAT_R8G8B8A8_UNORM is supported, and VK_FORMAT_B8G8R8A8_SRGB, VK_FORMAT_R8G8B8A8_SRGB is not supported. Why?

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

Currently VehicleDynamics does not make use of abstraction for drive model (m_driveModel). It should use abstraction and have a possibility of selection of drive model. This task should be done when another implementation is added.

SDF integration is planned for ROS 2 Iron (The Roadmap).
Importing Robots (and other elements) form SDF could be valuable as the next step after completing URDF support.

Is your feature request related to a problem? Please describe.
It will potentially make simulation smoother and more realistic.

Describe the solution you'd like
Implementation of the abovementioned functions.

The motorized joint component is POC.
It has multiple features :

• gathering measurements (e.g. protrusion of cylinder)
• compute string PID
• apply torque/force
• print debug info
• apply test signals

Describe the solution you'd like
I would like properly designed components. With small, well-defined features.
Example decoupling:

• Encoder Controller
• PID Controller
• Motor Controller
• Manual Controller (with Dear ImGUI interface)
• Switch to Joint PhysX API

Additional points:

• Remove test logic from this class and add a separate ImGUI base component for testing and tuning motorized joint.
• Remove debug draw entity and use EntityDebugDisplayEventBus instead.

Additional context
Design needs to expose an interface to ROS2: RobotecAI/o3de-ros2-gem#226

Is your feature request related to a problem? Please describe.
ROS 2 supports several types of executors. This is relevant to a design choice which is an answer to the following question:
"How do we process ROS 2 subscriptions and other executables (timers, service calls) in O3DE?"
Currently, we only process them in the main thread. This makes some sense but also suggests not to make subscription callbacks heavy (save the callback data, process in worker thread of a sensor, for example).

The task would encompass the following:

• Add information about preference for relatively lightweight subscription callbacks to the user documentation.
• Analyze pros and cons of separate threads (e.g. synchronization with physics and other limitations) for ROS 2 executors.
• If the case for a dedicated thread is supported by analysis, implement the case.
• Submit your argument for whether this should be a default solution.
• Allow the user to configure whether main thread or a dedicated thread should be used for ROS 2 spinning.

Describe the bug
Lighting issue can be seen in the XR_Office level when deployed to Oculus goggles as an APK. This issue also occurs when using GameLauncher, however does not occur when opening the level in the Editor.

Steps to reproduce

1. Complete O3DE system requirements. (https://www.o3de.org/docs/welcome-guide/requirements/)
2. Setup O3DE from Github (https://www.o3de.org/docs/welcome-guide/setup/setup-from-github/)
3. Complete Open XR setup (https://github.com/o3de/o3de-extras/wiki/Build-and-Run-OpenXR-in-O3DE)
4. Add and build the OpenXRTest project.
5. Enable OpenXR in OpenXRTest\Registry\OpenXR.setreg.
6. Deploy the APK to Oculus (https://www.o3de.org/docs/user-guide/platforms/android/generating_android_project_windows/)

Expected behavior
No lighting issues are present when running the APK on Oculus.

Actual behavior
Lighting issue can be seen.

Screenshots/Video

Found in Branch
O3DE Development (daed680)
o3de-extras (a723dd6 )

Desktop/Device:

• Device: PC / Oculus Quest 2
• OS: Windows
• Version 11
• CPU Intel i7-11700F
• GPU Nvidia GeForce RTX 3070
• Memory 32GB