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.
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.