It's got buttons. Lots of buttons. It has no touch screen(s).
Some of the buttons include: Multi-tap button to change HVAC vent configuration manually. Dedicated, separate buttons for front and rear defrost (with an LED on the button for each).
And the PWM control for the fan loves slow ramping, apparently as a design intent, which is dumb: It could provide immediate audible feedback to input but instead tends to just loaf around in response to user inputs.
But! It has an automatic mode that really does work pretty well almost always, maintaining comfort for different zones based on a temperature setting for each. So usually, I don't mess with it at all. When that doesn't work optimally (too hot? too cold?), the temperature is adjusted by knobs.
And it also accepts voice commands. Which sounds silly, and perhaps is silly, and I certainly do feel silly using that.
But when the front window starts fogging a bit on the inside on a cold night, I can tap the voice command button on the steering wheel (which is easy to find by feel) and say a command like "Climate control defrost and floor" and it switches to that mode.
I very seldom look at the stupid LCD screen, with its small and nearly-inscrutable blue-backlit hieroglyphs. I change modes with my voice, and I give the temperature knob a twist using muscle memory (though I could use voice commands for that, instead).
It's still perhaps not ideal (and I do have ideas for hacking on the CAN-B network for some hands-off automations to make it work better with even less user input), but it's pretty good.
And if Honda could use voice commands starting ~15 years ago, then any automaker should be able to do so today. The physical parts (the microphone, the CPU grunt, the CAN controls) are broadly already in-place; the rest is just software that can be copied infinitely as new cars roll off the line.
I’m optimistic that the latest progress in AI will fix this when the technology matures in cars. I reckon this is still a decade away though.
And that one voice command is easy-enough to remember, and the resulting manually-selected mode is easy-enough to cancel with the Auto button (which is the entire middle of the temperature knob -- simple enough).
AI is too easy to get wrong.
For example: At home when my hands are full and I'm headed to/from the basement, I might bark out the command "Alexa! Basement lights!"
This command sometimes results turning the lights on or off. But sometimes, it results in entering a conversation about the basement lights, when all anyone really wants from such simple diction is for the lights to toggle state -- like interacting with a regular light switch just toggles state.
I simply want computers to follow instructions. I am very particularly disinterested in ever having conversation -- a negotiation -- with a computer in my car.
But I can see plenty of merit to adding some context-aware tolerance for ambiguity to the accepted commands. Different people sometimes (quite rightly) use different words to describe the end result they want.
That doesn't take an LLM to accomplish, I don't think. After all, a car has a limited number of functions. It should be mostly a matter of broadening the voice recognition dictionary and expanding the fixed logic to deal with that breadth.
I reckon that this should have happened 5 years ago. :)
I think the most effective way to get this accurate and effective is to give an LLM the user’s voice prompt and current context and ask to convert the user’s request into an API call. The user wouldn’t be chatting with the LLM directly.
The point is that it doesn’t require a static dictionary to already have your exact phrasing and will just work with plain English.
Maybe some day.
Right now, when we do have substantial on-board computing systems, they're trying to drive the car -- not change the temperature. Adding in an additional computational timeslot for LLM voice commands seems both foolhardy and expensive.
Meanwhile: Broader dictionaries and static flows with greater breadth for voice recognition? We can do that right now.
(We can even use LLMs to help generate the static flows, along with people to evaluate and test them. Once implemented, they become cheap to run.
This is in-keeping with a fairly common theme here on HN: Don't use the bot to process the data. Instead, use the bot to write the data processor.)
In contrast, stuff like "airflow toward torso" versus "airflow towards feed" or "both" is stuff where you can either wait to feel it or else glance at the settings during a safer moment. This assumes, of course, they don't do something stupid like have the "current setting" vanish from the screen on a short timer...
Nowadays screens are being used as a cost cutting measure. It stands to reason that if an automaker reintroduces more costly physical controls it’s going to be to address the issue of cumbersome controls. Hopefully, anyway.