![\"ROC](\"https://blog.comma.ai/img/0111_release/dm_phone_gt_rocs.png\")
The LM GT3 model (#37425) improves phone detection and is the first openpilot DM model trained using labels generated by a locally hosted large Vision-Language Model (VLM).
\nIn this model, the driver’s phone-usage ground truth is generated by asking a VLM a YES/NO question and using the output probability of the YES token. The language model is set to predict only one token. The previous approach relied on a custom classifier network trained on a set of hand-labeled driver images.
\nTo evaluate this new pipeline, we hand-labeled a 1k validation set of driver images with drivers either using or not using phones, called the phone_using set. We also curated a smaller set named phone_mounted, consisting of 80 driver images with a phone mounted on the dash but not in use. The phone_mounted set represents difficult negative samples.
\nThe VLM notably reduces False Positives and improves detection of active handheld phone use as True Positives, while keeping all mounted phones as True Negatives.
\n
ROC curves for phone_using on the 1k validation set. phone_mounted not depicted since all are negative samples, whose false positives reduce to 0 when phone_using true positive rate is ~50%.
\nWith the model deployed in the field, we were also able to see its positive effects on safe driving habits when using openpilot. We compared phone usage time, as detected by the improved model, across the same group of devices before and after this model change. We saw a significant drop when openpilot was enabled, and even observed a small drop when it was not enabled, suggesting that drivers did reduce their phone usage overall.
\n![\"Phone](\"https://blog.comma.ai/img/0111_release/dm_phone_distraction.png\")
Phone usage behavior progression on the same sample group of 71 devices running master/nightly/staging: ‘before’ segments sampled from 60-day window before new DM model; ‘after’ segments from 20-day window after. All data re-evaluated offline using the same model.
\nThe two road cameras use a different image processing path on the ISP than the driver camera, and have had better image quality due to some missing pieces on the driver camera processing side. We have now enabled equivalent tone mapping blocks (#37873), as well as moved from on-sensor binning to post-demosaic downscaling (#37876). This means the driver camera will get the same high level of dynamic range and pixel details as the road-facing cameras.
\n![\"Driver](\"https://blog.comma.ai/img/0111_release/dm_camera_samples.png\")
Driver camera pictures old vs new, day and night.
\nAlerts from looking around are reduced during active maneuvers (#37751). When steering through a turn, the head pose yaw tolerance is widened in the direction of the steering angle, so glancing where the car is going no longer triggers an alert.
\n![\"Adaptive](\"https://blog.comma.ai/img/0111_release/dm_yaw_cones.png\")
Adaptive head pose thresholds during turns. This drops ~7% of all alerts. Angles shown are for illustrative purposes only, as these thresholds are also based on the scene and speed.
\nThis PR also extends the standstill exemption for DM alerting, so that an audible alert no longer unnecessarily kicks in the moment the car starts moving.
\nThe driverMonitoringState message has been restructured (#37799) to be both more readable and have a cleaner abstraction boundary. Downstream processes, such as selfdrived, can access top-level states and handle alerts without needing to know about DM policy details. Debugging with the new logs should also become easier.
\nIn the comma four onroad UI, we added a color change to the DM icon to subtly indicate distraction (#37826) before any alert is triggered. It also serves as feedback when the driver gets an audible DM alert and tries to look back at the device.
\nDM icon turns orange as soon as alert countdown starts, and returns to green as attention is restored.
\nThe DM icon is now calibrated to the road instead of showing raw pose from the model (#37149), so the green arc will be at the top of the icon when the driver is looking straight ahead.
\n![\"Comparison](\"https://blog.comma.ai/img/0111_release/dm_icon_straight.png\"){kind=icon}
Comparison of DM icon behavior when driver is looking straight ahead.
\nDirect sunlight on a parked comma four can heat the device above the fixed 75°C onroad threshold, temporarily blocking openpilot from going onroad even though the device would cool down once the car started moving.
\nThis release raises the threshold to 85°C and updates the comma four onroad thermal bands (#37891). Fleet analysis projected that raising the threshold from 75°C to 85°C would reduce affected devices by ~90%.
\n![\"Number](\"https://blog.comma.ai/img/0111_release/thermal_threshold.png\")
Number of comma four devices thermally blocked over the last 30 days. Raising the threshold from 75°C to 85°C reduced affected devices from 125 to 11.
\nThermal blocks were not isolated to a specific region, but occurred wherever solar load could push device temperature above the 75°C threshold. Incidents were concentrated in the US, consistent with fleet distribution, with additional clusters across Europe, the Middle East, and East Asia.
\n![\"Worldwide](\"https://blog.comma.ai/img/0111_release/thermal_map.png\")
Worldwide distribution of comma four devices thermally blocked before the threshold change.
\nThe figure below shows temperature traces from three comma four devices with high average offroad temperatures. The raised 85°C threshold allows these devices to go onroad during most peak-heating conditions.
\n![\"Temperature](\"https://blog.comma.ai/img/0111_release/thermal_dongles.png\")
Temperature traces from three comma four devices. Grey offroad points capture the offroad heating and cooling cycle, while green points show onroad driving. The old and new thresholds are shown as dashed lines.
\nThe original 75°C threshold was set conservatively to keep the SoC well below thermal throttling limits. CPU or GPU throttling can cause openpilot processes to lag and eventually disengage, so the onroad thermal policy must keep the device below throttling limits.
\nThermal throttling is managed by the Limits Management Hardware (LMH), which reduces frequency and voltage when a thermal trip point is reached. The CPU clusters, GPU, and RAM each have independent thermal zones and trip points. Since the RAM package is stacked directly on the SoC, its thermal limit can also trigger CPU throttling.
\nQualcomm’s default trip points (95°C) are designed for passively cooled smartphones, while comma four has active cooling and a larger thermal mass. Because of this, the CPU, GPU, and RAM trip points were increased by 10°C to 105°C (agnos-kernel-sdm845#110).
\nThe comma four was designed to operate like this, with a better heatsink design, a second heatsink on the bottom of the chip, and a very quiet fan. The software was still running a conservative thermal policy. Raising the trip points aligns the software with the hardware’s cooling performance.
\nTo validate the new trip points, a comma four was heat-soaked to 84°C before going onroad while CPU, GPU, and RAM temperatures were logged. Under initial load, CPU and GPU temperatures briefly peaked at 96°C before stabilizing around 68°C once the fan ramped up. RAM stabilized near 60°C.
\n![\"CPU,](\"https://blog.comma.ai/img/0111_release/thermal_curve.png\")
CPU, GPU, and RAM temperatures during ignition after heat-soaking the device at 84°C. The new 105°C throttling threshold is shown in red.
\nThe new threshold was merged into master on April 24, 2026. Since then, no comma four running openpilot master has been thermally blocked from going onroad.
\n![\"Daily](\"https://blog.comma.ai/img/0111_release/thermal_blocks.png\")
Daily count of comma four thermal blocks
\nThe longitudinal maneuver report enabled fast iteration on acceleration and jerk tuning by comparing commanded vs. measured response during scripted maneuvers. This release adds the same concept for lateral control. (#37562)
\nOn a straight, level road at constant speed, openpilot commands a set of lateral acceleration profiles and records the car’s response. Three maneuvers are run at 20 and 30 mph:
\n| Maneuver | \nCommand | \n
|---|---|
| Step right | \n+0.5 m/s² for 1 s, then -0.5 m/s² for 1.5 s | \n
| Step left | \n-0.5 m/s² for 1 s, then +0.5 m/s² for 1.5 s | \n
| Sine 0.5 Hz | \n1.0 m/s² amplitude, 2 s period | \n
Each maneuver repeats three times and only starts after the car has held speed for two seconds. Comparing commanded and measured lateral acceleration exposes rate limits, delays, and tuning issues.
\n![\"Sine](\"https://blog.comma.ai/img/0111_release/lateral_report.png\")
Sine 0.5 Hz maneuver at 30 mph on a Tesla Model Y and Kia EV6. The Tesla tracks the command closely, while the Kia is steering-rate limited.
\nLateral maneuver mode can be enabled in developer settings before going onroad. The maneuvers then execute automatically once conditions are met. The route rlogs need to be uploaded to connect, after which the HTML report can be generated with tools/lateral_maneuvers/generate_report.py route_id.
\nopenpilot is built by comma together with the openpilot community. Get involved in the community to push the driving experience forward.
\n#driving-feedback on DiscordWant to build the next release with us? We’re hiring.
\n", "content_markdown": "## Driver Monitoring [Permalink](https://blog.comma.ai/0111release/#driver-monitoring \"Permalink\")\n\n### New model with good phone detection [Permalink](https://blog.comma.ai/0111release/#new-model-with-good-phone-detection \"Permalink\")\n\nThe LM GT3 model ([#37425](https://github.com/commaai/openpilot/pull/37425)) improves phone detection and is the first openpilot DM model trained using labels generated by a locally hosted large Vision-Language Model (VLM).\n\nIn this model, the driver’s phone-usage ground truth is generated by asking a VLM a YES/NO question and using the output probability of the YES token. The language model is set to predict only one token. The previous approach relied on a custom classifier network trained on a set of hand-labeled driver images.\n\nTo evaluate this new pipeline, we hand-labeled a 1k validation set of driver images with drivers either using or not using phones, called the *phone\\_using* set. We also curated a smaller set named *phone\\_mounted*, consisting of 80 driver images with a phone mounted on the dash but not in use. The *phone\\_mounted* set represents difficult negative samples.\n\nThe VLM notably reduces False Positives and improves detection of active handheld phone use as True Positives, while keeping **all** mounted phones as True Negatives.\n\n\n\nROC curves for *phone\\_using* on the 1k validation set. *phone\\_mounted* not depicted since all are negative samples, whose false positives reduce to 0 when *phone\\_using* true positive rate is ~50%.\n\nWith the model deployed in the field, we were also able to see its positive effects on safe driving habits when using openpilot. We compared phone usage time, as detected by the improved model, across the same group of devices before and after this model change. We saw a significant drop when openpilot was enabled, and even observed a small drop when it was not enabled, suggesting that drivers did reduce their phone usage overall.\n\n\n\nPhone usage behavior progression on the same sample group of 71 devices running master/nightly/staging: ‘before’ segments sampled from 60-day window before new DM model; ‘after’ segments from 20-day window after. All data re-evaluated offline using the same model.\n\n### Improved driver camera image quality [Permalink](https://blog.comma.ai/0111release/#improved-driver-camera-image-quality \"Permalink\")\n\nThe two road cameras use a different image processing path on the ISP than the driver camera, and have had better image quality due to some missing pieces on the driver camera processing side. We have now enabled equivalent tone mapping blocks ([#37873](https://github.com/commaai/openpilot/pull/37873)), as well as moved from on-sensor binning to post-demosaic downscaling ([#37876](https://github.com/commaai/openpilot/pull/37876)). This means the driver camera will get the same high level of dynamic range and pixel details as the road-facing cameras.\n\n\n\nDriver camera pictures old vs new, day and night.\n\n### Fewer alerts where there shouldn’t be [Permalink](https://blog.comma.ai/0111release/#fewer-alerts-where-there-shouldnt-be \"Permalink\")\n\nAlerts from looking around are reduced during active maneuvers ([#37751](https://github.com/commaai/openpilot/pull/37751)). When steering through a turn, the head pose yaw tolerance is widened in the direction of the steering angle, so glancing where the car is going no longer triggers an alert.\n\n\n\nAdaptive head pose thresholds during turns. This drops ~7% of all alerts. Angles shown are for illustrative purposes only, as these thresholds are also based on the scene and speed.\n\nThis PR also extends the standstill exemption for DM alerting, so that an audible alert no longer unnecessarily kicks in the moment the car starts moving.\n\n### Improved system transparency [Permalink](https://blog.comma.ai/0111release/#improved-system-transparency \"Permalink\")\n\nThe driverMonitoringState message has been restructured ([#37799](https://github.com/commaai/openpilot/pull/37799)) to be both more readable and have a cleaner abstraction boundary. Downstream processes, such as *selfdrived*, can access top-level states and handle alerts without needing to know about DM policy details. Debugging with the new logs should also become easier.\n\nIn the comma four onroad UI, we added a color change to the DM icon to subtly indicate distraction ([#37826](https://github.com/commaai/openpilot/pull/37826)) before any alert is triggered. It also serves as feedback when the driver gets an audible DM alert and tries to look back at the device.\n\nDM icon turns orange as soon as alert countdown starts, and returns to green as attention is restored.\n\nThe DM icon is now calibrated to the road instead of showing raw pose from the model ([#37149](https://github.com/commaai/openpilot/pull/37149)), so the green arc will be at the top of the icon when the driver is looking straight ahead.\n\n\n\nComparison of DM icon behavior when driver is looking straight ahead.\n\n## Thermal improvements [Permalink](https://blog.comma.ai/0111release/#thermal-improvements \"Permalink\")\n\n### Reducing thermal onroad blocks [Permalink](https://blog.comma.ai/0111release/#reducing-thermal-onroad-blocks \"Permalink\")\n\nDirect sunlight on a parked comma four can heat the device above the fixed 75°C onroad threshold, temporarily blocking openpilot from going onroad even though the device would cool down once the car started moving.\n\nThis release raises the threshold to 85°C and updates the comma four onroad thermal bands ([#37891](https://github.com/commaai/openpilot/pull/37891)). Fleet analysis projected that raising the threshold from 75°C to 85°C would reduce affected devices by ~90%.\n\n\n\nNumber of comma four devices thermally blocked over the last 30 days. Raising the threshold from 75°C to 85°C reduced affected devices from 125 to 11.\n\n### Field observations [Permalink](https://blog.comma.ai/0111release/#field-observations \"Permalink\")\n\nThermal blocks were not isolated to a specific region, but occurred wherever solar load could push device temperature above the 75°C threshold. Incidents were concentrated in the US, consistent with fleet distribution, with additional clusters across Europe, the Middle East, and East Asia.\n\n\n\nWorldwide distribution of comma four devices thermally blocked before the threshold change.\n\nThe figure below shows temperature traces from three comma four devices with high average offroad temperatures. The raised 85°C threshold allows these devices to go onroad during most peak-heating conditions.\n\n\n\nTemperature traces from three comma four devices. Grey offroad points capture the offroad heating and cooling cycle, while green points show onroad driving. The old and new thresholds are shown as dashed lines.\n\n### Raising the kernel trip points [Permalink](https://blog.comma.ai/0111release/#raising-the-kernel-trip-points \"Permalink\")\n\nThe original 75°C threshold was set conservatively to keep the SoC well below thermal throttling limits. CPU or GPU throttling can cause openpilot processes to lag and eventually disengage, so the onroad thermal policy must keep the device below throttling limits.\n\nThermal throttling is managed by the Limits Management Hardware (LMH), which reduces frequency and voltage when a thermal trip point is reached. The CPU clusters, GPU, and RAM each have independent thermal zones and trip points. Since the RAM package is stacked directly on the SoC, its thermal limit can also trigger CPU throttling.\n\nQualcomm’s default trip points (95°C) are designed for passively cooled smartphones, while comma four has active cooling and a larger thermal mass. Because of this, the CPU, GPU, and RAM trip points were increased by 10°C to 105°C ([agnos-kernel-sdm845#110](https://github.com/commaai/agnos-kernel-sdm845/pull/110)).\n\nThe comma four was designed to operate like this, with a better heatsink design, a second heatsink on the bottom of the chip, and a very quiet fan. The software was still running a conservative thermal policy. Raising the trip points aligns the software with the hardware’s cooling performance.\n\nTo validate the new trip points, a comma four was heat-soaked to 84°C before going onroad while CPU, GPU, and RAM temperatures were logged. Under initial load, CPU and GPU temperatures briefly peaked at 96°C before stabilizing around 68°C once the fan ramped up. RAM stabilized near 60°C.\n\n\n\nCPU, GPU, and RAM temperatures during ignition after heat-soaking the device at 84°C. The new 105°C throttling threshold is shown in red.\n\n### Field results [Permalink](https://blog.comma.ai/0111release/#field-results \"Permalink\")\n\nThe new threshold was merged into master on April 24, 2026. Since then, no comma four running openpilot master has been thermally blocked from going onroad.\n\n\n\nDaily count of comma four thermal blocks\n\n## Lateral maneuver report [Permalink](https://blog.comma.ai/0111release/#lateral-maneuver-report \"Permalink\")\n\nThe longitudinal maneuver report enabled fast iteration on acceleration and jerk tuning by comparing commanded vs. measured response during scripted maneuvers. This release adds the same concept for lateral control. ([#37562](https://github.com/commaai/openpilot/pull/37562))\n\nOn a straight, level road at constant speed, openpilot commands a set of lateral acceleration profiles and records the car’s response. Three maneuvers are run at 20 and 30 mph:\n\n| Maneuver | Command |\n| ----------- | ------------------------------------------- |\n| Step right | +0.5 m/s² for 1 s, then -0.5 m/s² for 1.5 s |\n| Step left | -0.5 m/s² for 1 s, then +0.5 m/s² for 1.5 s |\n| Sine 0.5 Hz | 1.0 m/s² amplitude, 2 s period |\n\nEach maneuver repeats three times and only starts after the car has held speed for two seconds. Comparing commanded and measured lateral acceleration exposes rate limits, delays, and tuning issues.\n\n\n\nSine 0.5 Hz maneuver at 30 mph on a Tesla Model Y and Kia EV6. The Tesla tracks the command closely, while the Kia is steering-rate limited.\n\n### Improve your car [Permalink](https://blog.comma.ai/0111release/#improve-your-car \"Permalink\")\n\nLateral maneuver mode can be enabled in developer settings before going onroad. The maneuvers then execute automatically once conditions are met. The route rlogs need to be uploaded to [connect](https://comma.ai/connect), after which the HTML report can be generated with *tools/lateral\\_maneuvers/generate\\_report.py route\\_id*.\n\n## Cars [Permalink](https://blog.comma.ai/0111release/#cars \"Permalink\")\n\n### Bug fixes [Permalink](https://blog.comma.ai/0111release/#bug-fixes \"Permalink\")\n\n- Hyundai CAN FD: fix Blindspot Collision Warning signal bit ([opendbc#3296](https://github.com/commaai/opendbc/pull/3296))\n- Hyundai: fix erroneous “SCC Conditions Not Met” dash alerts ([opendbc#3305](https://github.com/commaai/opendbc/pull/3305))\n- Toyota: detect invalid wheel speed sensors ([opendbc#3380](https://github.com/commaai/opendbc/pull/3380))\n\n### Enhancements [Permalink](https://blog.comma.ai/0111release/#enhancements \"Permalink\")\n\n- Honda: support all manual transmissions ([opendbc#3245](https://github.com/commaai/opendbc/pull/3245))\n\n### Car Ports [Permalink](https://blog.comma.ai/0111release/#car-ports \"Permalink\")\n\n- Acura MDX 2022-24 support thanks to mvl-boston! ([opendbc#2410](https://github.com/commaai/opendbc/pull/2410))\n- Rivian R1S and R1T 2025 support thanks to lukasloetkolben! ([opendbc#3227](https://github.com/commaai/opendbc/pull/3227))\n\nopenpilot is built by comma together with the openpilot community. Get involved in the community to push the driving experience forward.\n\n- Join the [community Discord](https://discord.comma.ai)\n- Post your driving feedback in `#driving-feedback` on Discord\n- Upload your driving data with [Firehose Mode](https://blog.comma.ai/098release#firehose-mode)\n- Get started with [openpilot development](https://github.com/commaai/openpilot#to-start-developing-openpilot)\n\nWant to build the next release with us? We’re [hiring](https://comma.ai/jobs).\n", "dateCreated": "2026-09-19T21:30:23.395188495+00:00", "date_created": "2026-06-05T10:00:00+00:00", "date_modified": "2026-06-05T10:00:00+00:00", "date_published": "2026-06-05T10:00:00+00:00", "description": "Driver MonitoringPermalink New model with good phone detectionPermalink The LM GT3 model (#37425) improves phone detection and is the first openpilot DM model trained using labels generated by a locally hosted large Vision-Language Model…", "external_url": "https://blog.comma.ai/0111release/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/blog-comma-ai/2026/06/2026-06-05-openpilot-0-11-1.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/blog-comma-ai/2026/06/2026-06-05-openpilot-0-11-1.md" }, "id": "urn:aggr:item:1b0e010ada0e4e9b3b0033682c98e22eecb6fb58", "isBasedOn": { "@id": "https://blog.comma.ai/0111release/" }, "mainEntity": { "@id": "https://blog.comma.ai/0111release/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/blog-comma-ai/2026-06-05-openpilot-0-11-1/#webpage" }, "author": [ { "@type": "Person", "name": "openpilot team" } ], "dateModified": "2026-06-05T10:00:00+00:00", "datePublished": "2026-06-05T10:00:00+00:00", "headline": "openpilot 0.11.1", "timeRequired": "PT7M", "url": "https://blog.comma.ai/0111release/", "wordCount": 1570 }, "name": "Archived snapshot: openpilot 0.11.1", "preview": null, "reading_minutes": 7, "replicated_at": null, "source": "blog-comma-ai", "source_name": "comma.ai blog", "summary": "Driver MonitoringPermalink New model with good phone detectionPermalink The LM GT3 model (#37425) improves phone detection and is the first openpilot DM model trained using labels generated by a locally hosted large Vision-Language Model (VLM). In this model, the driver’s …", "tags": [], "temporalCoverage": "2026-09-19T21:30:23.395188495+00:00", "title": "openpilot 0.11.1", "url": "https://aggr.aymericbeaumet.com/items/blog-comma-ai/2026-06-05-openpilot-0-11-1/", "word_count": 1570 }