I just took my first drive with 0.7.10 (since 0.7.7) tonight and since I don't have DM at night I use wheel touch. However with the changes to wheel touch timings in this commit https://github.com/commaai/openpilot/commit/21d4ac1eebba06769f03edf7220ce84bd6ae154d I find myself not being able to catch the alert fast enough so that it doesn't make noise. If I'm looking straight at the road, as soon as I notice that the alert to touch the wheel has shown, it's just then turning to orange and starts making noise, possibly waking up anyone else in the car (but is also annoying if it's just you).
Is there any way we can either delay this prompt noise, or revert part of that commit to make the time from initial "touch the wheel" alert to making noise alert its original length? It was perfect before, but now makes driving at night much more annoying. Another annoyance is the orange warning alert that makes noise turns on and off repeatedly if the monitoring model is uncertain, since the orange alert resets the hi_std_alert_enabled variable, so it's just in a loop until I touch the wheel, even if I'm looking at the road and the model can see me.
That last thing could be solved by a timeout on how quickly it can show the uncertain alert after orange alert is shown.
Follow up; if this will not be changed, then I'd at least like to know if we can revert the driver monitoring times to their previous values without risking being banned on our own forks. After all, they were good enough until the last commit.
We can make the green alert appear sooner on master, and will be in the next release. (28+2 -> 26+4)
Re: bans on forks, currently it's only an issue if it's being set to something clearly designed to flout driver monitoring, though this will change in the future once we have better models. There's certainly no problem with showing the alert sooner.
Hmm, actually @ZwX1616, can we revert _AWARENESS_PRE_TIME_TILL_TERMINAL and _AWARENESS_PROMPT_TIME_TILL_TERMINAL? I'm not sure why we had to change that.
Or @ShaneSmiskol, without changing _AWARENESS_TIME=35 if you find values for the others two that are better, we'd upstream.
Yeah that sounds about right, I felt like it gave me about 2 seconds before it made noise which wasn't ideal (you end up hearing that warning beep every ~30 seconds or so at night).
I don't have any intention to disable DM or make the timeout obscenely high, but how it is now seems pretty strict considering when it can see your face it takes the scene into account and can make itself more lax or aggressive depending on what kind of road you're on. But with wheel touch it's always a static time, even if there's no one around.
I'll go out and test the original values(/find ones that seem better) as well as try to fix that uncertain alert flickering while the orange "touch wheel" alert is on screen and open a PR for that
(Ah I see how that works now! 7-5=2 seconds for green prompt alert. Yeah that's way too little, everyone I have try openpilot they don't notice the screen quick enough for the older times yet alone 2 seconds lol)
Hmm, actually @ZwX1616, can we revert _AWARENESS_PRE_TIME_TILL_TERMINAL and _AWARENESS_PROMPT_TIME_TILL_TERMINAL? I'm not sure why we had to change that.
Or @ShaneSmiskol, without changing _AWARENESS_TIME=35 if you find values for the others two that are better, we'd upstream.
Yeah we can do that. Something in the middle might be better? But yes I am okay with being more strict with the green while allowing more time to react before orange. The driver is expected to hold the wheel in that situation anyways. It’s just that the system should be less annoying.
I went out to get a video of the second issue I described, you can see the uncertain warning keeps triggering since the orange alert keeps resetting it. I actually didn't expect it to disengage here, I thought since it wasn't showing either alert for a few seconds that it saw me and reset the timer but I guess it didn't.
Edit: Actually I think this might be caused by something else, and not the uncertain alert since it didn't show up this time. Maybe there should be some smoothing between immediately deciding if model is confident or not?
Have any ideas what can be changed to fix the flickering?
Adobe flash player is going to be discontinued in December(the EOL was announced in 2017), so as a result, we're going to have to make things more adaptable to HTML5 and webm devices or programming :-) just saying, that may be the reason for any flickering going on*
what
On Nov 3, 2020, at 8:05 AM, DaveyD233 notifications@github.com wrote:
—
Have any ideas what can be changed to fix the flickering?
A counter can be added to avoid throwing multiple alerts within a short amount of time, but it's kind of hacky tbh. When it says "Check Driver Visibility", check driver visibility. If driver visibility can't be achieved, vision DM will not work as desired. I would just touch the wheel to reset.
That being said, you are welcome to find a comfortable green/orange balance and submit a PR for that!
I don't think not changing behavior is a good solution since it's especially confusing to know what the state of awareness is if it flickers on and off and then goes terminal out of nowhere. It was completely unexpected for me since it seemed like it picked up my face and was happy, but then gave me less than a second to react before disengaging.
As someone who can't afford to buy a C2 for just nighttime DM, I don't think DM's current state is good enough for EON users. Even if I touch the wheel when it prompts me too, there is still the alert that says to "CHECK DRIVER FACE VISIBILITY" every 35 seconds which gets annoying and can even be distracting as I find myself taking my eyes off the road to glance at what it's alerting me of. Though maybe the longer green alert will be enough, I still think that alert should only show at most 3 times per drive, I already know it can't see me well.
I'll make a PR for updating the times though soon, I just need time to experiment