Conversation
Process replay diff reportReplays driving segments through this PR and compares the behavior to master. ✅ 0 changed, 66 passed, 0 errors |
|
|
||
| def main() -> None: | ||
| try: | ||
| subprocess.run(["udevadm", "settle"], check=True) |
There was a problem hiding this comment.
does this mess with other things like the modem that's also on USB? what does this do?
There was a problem hiding this comment.
any reason not to do this in modeld? i think it's a bit cleaner
| if model_name == "smallModelV2": | ||
| config_realtime_process([0, 1, 2, 3], 54) |
There was a problem hiding this comment.
both don't fit on a single core? this changes the runtime of the small model....
|
|
||
| PythonProcess("modeld", "openpilot.selfdrive.modeld.modeld", only_onroad), | ||
| PythonProcess("bigmodeld", "openpilot.selfdrive.modeld.bigmodeld", bigmodeld), | ||
| PythonProcess("modelrouterd", "openpilot.selfdrive.modeld.modelrouterd", usbgpu), |
There was a problem hiding this comment.
let’s always route? keeps both codepaths closer, avoids extra logic in modeld
| @@ -129,5 +129,7 @@ inline static std::unordered_map<std::string, ParamKeyAttributes> keys = { | |||
| {"UptimeOnroad", {PERSISTENT, FLOAT, "0.0"}}, | |||
| {"UsbGpuPresent", {CLEAR_ON_MANAGER_START | CLEAR_ON_OFFROAD_TRANSITION, BOOL}}, | |||
There was a problem hiding this comment.
can we use the chestnutPresent message here instead?
|
|
||
|
|
||
| def main(demo=False): | ||
| def main(demo=False, model_name="modelV2"): |
There was a problem hiding this comment.
splitting on model_name to publish without routing when no usbgpu is confusing to read
it'd be nicer to always route and to have the publishing logic in a single place, it doesn't depend on the usbgpu being present
| params.put_bool("UsbGpuPresent", _present) | ||
| params.put_bool("UsbGpuCompiled", _compiled) | ||
| if model_name == "modelV2": | ||
| _present = usbgpu_present() |
There was a problem hiding this comment.
slightly confusing that small modeld does the detection for big modeld
could we move the detection logic elsewhere and always pass big/small to modeld?
|
having to disengage then reengage to switch from small to big is going to be super confusing. |
4 participants
big model fallback logic
Startup: load small model and big model in separate processes, ready to engage small model instantly
Big model loaded: next user disengage switches to big model to prevent abrupt shifts in model outputs
Big model failed: soft disengage, switches to small model, next user engage drives on small model