Conversation
ratheron
force-pushed
the
feature.availability_methods
branch
from
September 19, 2026 13:06
68bcac8 to
2d4f39e
Compare
ratheron
marked this pull request as ready for review
September 19, 2026 13:55
amacati
reviewed
Sep 19, 2026
| --> | ||
|
|
||
| All drone configurations are bundled with `crazyflow.dynamics`. Available configurations: `cf2x_L250`, `cf2x_P250`, `cf2x_T350`, `cf21B_500`, and any drone returned by `crazyflow.available_drones`. | ||
| All drone configurations are bundled with `crazyflow.dynamics`. Available configurations: `cf2x_L250`, `cf2x_P250`, `cf2x_T350`, `cf21B_500`, and any member of `crazyflow.Drone`. |
Collaborator
There was a problem hiding this comment.
Why are we listing four explicit models and then the generic one?
Collaborator
Author
There was a problem hiding this comment.
We should just say that all members of crazyflow.Drone are available and link the docs.
Comment on lines
+51
to
+52
| from crazyflow.dynamics import available_dynamics, supported_drones | ||
|
|
Comment on lines
+62
to
+64
| from crazyflow.drones import Drone | ||
| from crazyflow.dynamics import supported_dynamics | ||
|
|
Comment on lines
+54
to
+56
| `crazyflow/dynamics/<model>/params.toml` has a complete section for it; the commented example at the | ||
| top of each file lists the keys. `supported_drones` and `supported_dynamics` report the pairs, and the | ||
| tests only run those. Only `gravity_vec` is global, in `crazyflow/dynamics/params.toml`. |
Collaborator
There was a problem hiding this comment.
Suggested change
| `crazyflow/dynamics/<model>/params.toml` has a complete section for it; the commented example at the | |
| top of each file lists the keys. `supported_drones` and `supported_dynamics` report the pairs, and the | |
| tests only run those. Only `gravity_vec` is global, in `crazyflow/dynamics/params.toml`. | |
| `crazyflow/dynamics/<model>/params.toml` has a section for it. The commented example at the | |
| top of each file lists the keys. `supported_drones` and `supported_dynamics` report the pairs, and the | |
| tests only run those. Only `gravity_vec` is global, in `crazyflow/dynamics/params.toml`. |
Comment on lines
+163
to
+165
|
|
||
| Raises: | ||
| ValueError: If ``dynamics`` is not a known model. |
Collaborator
There was a problem hiding this comment.
Suggested change
| Raises: | |
| ValueError: If ``dynamics`` is not a known model. |
I think we don't have to mention that here, especially since we don't raise ourselves
Comment on lines
+182
to
+184
|
|
||
| Raises: | ||
| ValueError: If ``drone`` is not a known drone. |
Collaborator
There was a problem hiding this comment.
Suggested change
| Raises: | |
| ValueError: If ``drone`` is not a known drone. |
| @@ -0,0 +1,43 @@ | |||
| # Adding a drone | |||
|
|
|||
| A drone is a member of the `Drone` enum in `crazyflow/drones/__init__.py` with a matching MJCF file in `crazyflow/drones`. The package asserts on import that the two agree. A dynamics model or controller supports a drone when its own `params.toml` has a section for it, so adding a platform means adding one enum member, the MJCF file, and parameter sections. | |||
Collaborator
There was a problem hiding this comment.
Suggested change
| A drone is a member of the `Drone` enum in `crazyflow/drones/__init__.py` with a matching MJCF file in `crazyflow/drones`. The package asserts on import that the two agree. A dynamics model or controller supports a drone when its own `params.toml` has a section for it, so adding a platform means adding one enum member, the MJCF file, and parameter sections. | |
| A drone is a member of the `Drone` enum in `crazyflow/drones/__init__.py` with a matching MJCF file in `crazyflow/drones`. We check on import that the two agree. A dynamics model or controller supports a drone when its own `params.toml` has a section for it, so adding a platform means adding one enum member, the MJCF file, and parameter sections. |
| - `first_principles` additionally needs the hardware constants: arm length, thrust and torque curves and mixing matrix. The remaining keys have to be set but not identified: `rotor_dyn_coef = [1/tau, 0.0, 1/tau, 0.0]` is a symmetric first order rotor model with time constant `tau`, a zero `drag_matrix` disables drag, and a zero `prop_inertia` drops the gyroscopic torque of the propellers. | ||
| - The fitted `so_rpy`, `so_rpy_rotor` and `so_rpy_rotor_drag` models need identified coefficients. Use the [system identification pipeline](dynamics/system-identification.md) to obtain them from flight data. | ||
|
|
||
| Gravity is global and lives in `crazyflow/dynamics/params.toml`. A model without a section is simply not offered for that drone. [`supported_dynamics`][crazyflow.dynamics.supported_dynamics] and [`supported_drones`][crazyflow.dynamics.supported_drones] report the available pairs, and `Sim` raises `KeyError` for any other combination. |
Collaborator
There was a problem hiding this comment.
Suggested change
| Gravity is global and lives in `crazyflow/dynamics/params.toml`. A model without a section is simply not offered for that drone. [`supported_dynamics`][crazyflow.dynamics.supported_dynamics] and [`supported_drones`][crazyflow.dynamics.supported_drones] report the available pairs, and `Sim` raises `KeyError` for any other combination. | |
| Global environment constants like `gravity` are stored in `crazyflow/dynamics/params.toml`. A model without a section is simply not offered for that drone. [`supported_dynamics`][crazyflow.dynamics.supported_dynamics] and [`supported_drones`][crazyflow.dynamics.supported_drones] report the available pairs, and `Sim` raises `KeyError` for any other combination. |
|
|
||
| ## 5. Run the tests | ||
|
|
||
| The test suite parametrizes over `Drone` and over the supported drone-dynamics pairs, so the new drone is tested without any changes to the tests. In particular, `tests/integration/test_models.py` constructs a `Sim` for every supported pair, which loads the MJCF, the dynamics parameters and the controller parameters together. |
Collaborator
There was a problem hiding this comment.
Suggested change
| The test suite parametrizes over `Drone` and over the supported drone-dynamics pairs, so the new drone is tested without any changes to the tests. In particular, `tests/integration/test_models.py` constructs a `Sim` for every supported pair, which loads the MJCF, the dynamics parameters and the controller parameters together. | |
| The test suite parametrizes over `Drone` and over the supported drone-dynamics pairs, so the new drone is tested without any changes to the tests. |
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
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.
We currently hard code what drones are available. Also, there is no way to check what models are available for which dynamics and vice-versa (will be relevant for tests once #115 is done). Implemented both.
Additionally, there is a short section in the docs on how to add your own model.
Waiting for #119 to finish this