Difficulty implementing end-to-end gradient flow for differentiable drone physics on Genesis platform

[sycamore-yu]

Description

I am trying to migrate the DiffPhysDrone project to Genesis because I would like to use a simulator with native differentiable rigid-body physics instead of maintaining a separate custom differentiable quadrotor model.

While doing this migration, I found conflicting signals about the current status of differentiable rigid-body control support for drone training.

In particular, this discussion states:

"Rigid body simulation is now fully differentiable. Please have to look at tests/test_grad.py as reference. Official documentation will come soon."

References:

• How to use differentiable simulation? #691 (reply in thread)
• https://github.com/Genesis-Embodied-AI/Genesis/blob/main/tests/test_grad.py

However, from the perspective of migrating a differentiable drone project, it is still unclear which control inputs are expected to be differentiable today, and which Genesis version or branch should be used.

To Reproduce

1. Official reference behavior

The official tests/test_grad.py examples seem to validate differentiability for:

• rigid-body state initialization such as position / quaternion
• set_velocity() in the official reference examples
• terminal state losses that backpropagate through the simulator

This suggests that rigid-body differentiability exists at least at the simulator level.

2. Local test with rigid control input

I wrote a minimal rigid-body comparison test to check whether control inputs passed via set_dofs_velocity() can receive gradients from a terminal position loss.

Observed behavior on our current local Genesis 0.4.0 / quadrants-based branch:

• the final rigid-body output tensor did not behave like a differentiable autograd target
• loss.backward() failed with:

RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn

This suggests that, at least on the tested version, set_dofs_velocity() is not yet a reliable end-to-end differentiable rigid-body control interface for training.

3. Drone-specific control path

For drones, the most natural API seems to be:

• DroneEntity.set_propellels_rpm()

This is much closer to real quadrotor control than directly writing DOF velocities.

However, I could not find clear documentation stating whether gradients are expected to propagate from a terminal drone loss back to RPM inputs passed to set_propellels_rpm().

4. Open PR related to rigid differentiability

I also found:

• [FEATURE] WIP: Make rigid body simulation fully differentiable #2078

This PR is still open and appears to contain key work related to differentiable rigid-body control inputs.

Because of that, I am unsure whether:

• released Genesis already supports native end-to-end differentiable rigid-body control for drone training
• or whether this support is still incomplete and under active development

Expected Behavior

For users trying to migrate projects like DiffPhysDrone, it would be very helpful to have explicit clarification on:

1. whether DroneEntity.set_propellels_rpm() is expected to be differentiable today
2. whether the fact that PR #2078 is still open means differentiable rigid-body control is still incomplete
3. which control interface is the recommended best practice for differentiable drone training:
   • set_propellels_rpm()
   • control_dofs_force()
   • control_dofs_velocity()
   • set_dofs_velocity()
4. whether there is already a released / recommended Genesis version for native end-to-end differentiable drone training

Environment

Tested in the following context:

• Genesis 0.4.0 on a local quadrants-based branch
• additional experiments on the open #2078 branch
• GPU hardware available locally, but behavior still unclear for the differentiable drone-control path

Questions

1. Is DroneEntity.set_propellels_rpm() expected to support gradient propagation?

For differentiable quadrotor training, RPM is the most physically meaningful control input because it maps to thrust and torque. If this API is not intended to be differentiable today, it would be very helpful to state that explicitly.

2. Does PR #2078 still being open imply that differentiable rigid-body control is not yet fully supported?

This is the main source of confusion. The discussion suggests rigid-body simulation is fully differentiable, but the open PR seems to indicate that important rigid-control differentiability work is still ongoing.

3. What is the recommended control API for end-to-end differentiable drone training?

My current understanding is:

• RPM is the most natural high-level drone control input
• set_dofs_velocity() looks more like direct state writing than a preferred training interface
• control_dofs_force() seems closer to the intended differentiable rigid-control path

Could maintainers clarify which interface should actually be used?

4. Is native end-to-end differentiable drone training already recommended in Genesis today?

Or is the current practical recommendation still to:

• use Genesis mainly as a fast rigid-body simulator
• keep a separate external differentiable drone dynamics model for training

Additional Context

This clarification matters because native differentiable drone control in Genesis would allow users to combine:

• realistic rigid-body simulation
• batched rollouts
• direct gradient-based policy optimization

Right now it is difficult to tell whether this workflow is already supported, partially supported, or still experimental.

It would be especially helpful if future documentation explicitly separated:

• differentiable rigid-body state initialization / state-query examples
• differentiable rigid-body control-input support
• drone-specific control support such as RPM-based APIs

[duburcqa]

This is not supported for now unfortunately.