enum schemas and binding to C #526
Conversation
collision/offroad/traffic_light_behavior take "ignore"/"stop"/"remove" instead of raw ints; drive.py maps names to binding constants, the C ini parser rejects anything else, and IGNORE_INFRACTION/STOP_AGENT/REMOVE_AGENT are exported to Python.
OmegaConf structured schema (config_schema.py) validates types, enum names, and unknown keys at load_config time; test_config_schema.py asserts the schema enum ints never drift from the drive.h constants exported by the binding.
| int collision_behavior; // IGNORE_INFRACTION, STOP_AGENT, or REMOVE_AGENT | ||
| int offroad_behavior; // IGNORE_INFRACTION, STOP_AGENT, or REMOVE_AGENT | ||
| int traffic_light_behavior; // IGNORE_INFRACTION, STOP_AGENT, or REMOVE_AGENT | ||
| int use_map_cache; // 0 = each env owns its map copy, 1 = share static geometry across envs |
There was a problem hiding this comment.
These names don't seem consistent with the other documentation?
There was a problem hiding this comment.
It seems risky to me to have multiple variants of a naming scheme floating around
There was a problem hiding this comment.
yeah. this is the minimal change of keeping the names we already had in the C part of the code. We could totally move everything to have the same names across python and C, and even enforce name matching with a test?
There was a problem hiding this comment.
Yeah I just feel like we might as well make that change here if we're going to do this?
There was a problem hiding this comment.
sounds good! I'll look around and ask claude as well if there's any known/good pattern to follow here, otherwise we can just go with the intuition of naming everything the same.
|
converting back to draft while reviewing the proposal |
|
Ok, all relevant config parameters are mapped to an Enum class in the config. Each enum class has a direct name - value matching with the C enum constants. The convention is to have {enum_class_name}_{enum_value} for each class. Example: DynamicsModel.classic -> DYNAMICS_MODEL_CLASSIC The python enum class name has to use the CamelCase convention to ensure we are separate the words, the values have to use PascalCase (underscore separation) (see the 2 examples above). With this convention, we can automatically separate match the python enum to the C enum enforcing the respective integer value match as a test. |
2 participants
This PR introduces the enum schemas and binding to C to make sure of two things:
The first point in particular let us run a validation of the config directly on the login node rather than waiting for run-time errors (we can add this to this pr if needed).
Note: co-authored with claude.