"Accurate voice prompting' mode to support visually impaired

[NaviMen]

I beg you on behalf of blind users! Make it possible to receive TTS notifications of maneuvers on arrival, as well as notifications of POIs in fact, and not in 50 - 10 meters. For blind people, this opportunity is needed like air! Do not disregard!

[vshcherb]

Для не зрячих попробуйте настройки навигации-> голос -> cообщение о прибытии и выберете там "на последних метрах". Этот коэффициент существенно приближает до 5-10 метров

[NaviMen]

За этот пункт все знают, но 5 - 10 метров, это для незрячего человека большая погрешность! Нужно оповещение "По факту" когда на счётчике до маневра осталось 1 - 0 метров, то есть фактическое оповещение о маневре и о прибытии. Это не моя прихоть, поверьте мне, этого ждет подавляющая часть пользователей, которые абсолютно ничего не видят и навигация для таких людей, это своего рода поводырь.

Пт, 10 квіт. 2020, 13:48 користувач vshcherb notifications@github.com пише:

Для не зрячих попробуйте настройки навигации-> голос -> cообщение о прибытии и выберете там "на последних метрах". Этот коэффициент существенно приближает до 5-10 метров

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/osmandapp/Osmand/issues/8749#issuecomment-611981298, or unsubscribe https://github.com/notifications/unsubscribe-auth/APBFKVRHCP7N76LYQXBXP2LRL32RPANCNFSM4L2XICWA .

[NaviMen]

Идеально бы погрешность свести к нулю. Незрячий понимает подсказки буквально, если прибыл, значит прибыл, если маневр, значит маневр, здесь и сейчас.

[vshcherb]

0-я точность это важно, особенно если скорость небольшая 1 метр в секунду

[NaviMen]

Я не знаю как в профиле для транспорта, но для пешеходного профиля 0-я точность очень важна.

[sonora]

2 thoughts here:

• it does not make sense for bike or car profiles, because it would lengthen the time span the announcements sound, and while in motion this creates no more clarity (because the uncertainty of the moving reference point is greater), only more a accoustic cludder
• so it needs to be an option for the ped profile, or preferably we should even limit it to whenever you are at rest, so the reference point is clear enough. And also to only if the hdop value allows it (i.e. is small enough), because scientifically it would be false to announce something with higher precision than the confidence (reliability of the measurement).

[sonora]

PS: What language do you need?

The quick and dirty way of helping you, and least intrusive to our code, is to simply provide a special edition of a tts voice file where the standard distance rounding block is deactivated. That's not very hard to produce for one lagnuage.

[JonnyTech]

@sonora can I request one for en-gb (English, United Kingdom) for a poor-sighted friend of mine, please.

[NaviMen]

PS: какой язык тебе нужен?

Быстрый и грязный способ помочь вам, и наименее навязчивый к нашему коду, - это просто предоставить специальную версию голосового файла tts, где стандартный блок округления расстояния деактивирован. Это не очень сложно сделать за один язык.

rus and ukr but it would be nice to do this programmatically with the settings in the interface, since not all blind people can work with the file system, move something with auto-replace, it is difficult for such people.

[NaviMen]

@sonora Могу ли я попросить один для en-gb (английский, Великобритания) для моего слабовидящего друга, пожалуйста.

Your friend is not the only one who wants it! This question was already raised in 2015, but no one helped! It would be ideal to make an item in the settings that would deactivate rounding in the language pack, then all the blind could use it.

[sonora]

I just noticed I probably misunderstood your issue, due to the misleading title:

I checked the standard rounding we apply and we have always rounded to the nearest meter for all distances of 17 meters and closer (for TTS voice. Recorded voice even <20m). And since I think this is the range where this high precision matters for your purpose, we should be good?

I guess the issue is not the precision of the announcement, but rather that you request being able to have announcements very close to a turn or the destination? Are you aware that at any point you can trigger an announcemnt by tapping the navigation arrow icon in the top left of the map screen?

[NaviMen]

Я только что заметил, что, возможно, неправильно понял вашу проблему из-за вводящего в заблуждение названия:

Я проверил стандартное округление, которое мы применяем, и мы всегда округляли до ближайшего метра для всех расстояний 17 метров и ближе (для голоса TTS. Записанный голос даже <20 м). И так как я думаю, что это диапазон, где эта высокая точность важна для вашей цели, мы должны быть хорошими?

Я предполагаю, что проблема не в точности объявления, а в том, что вы запрашиваете возможность иметь объявления очень близко к повороту или месту назначения? Знаете ли вы, что в любой момент вы можете запустить оповещение, нажав значок стрелки навигации в левом верхнем углу экрана карты?

Everyone knows about this opportunity, but imagine only this situation! There is a blind man, with a cane in one hand, and a bag in the other, and here he needs to take out the phone each time and see how much is left before the maneuver ??? This is absolutely uncomfortable! It is necessary to reduce to zero the error in notifications of arrival and maneuvers.

[sonora]

What I was suggesting is: I could provide a special voice, which you would simply have to download and select one time, which would e.g. speak all announcements with 1 meter precision, not just below 20 meters distance, as our standard voices do.

But I now understand our standard voices are just fine for your purpose, what you need to have is more frequent, automatic announcements as you approach something, right?

[NaviMen]

Я предложил следующее: я мог бы предоставить специальный голос, который вам нужно было бы просто загрузить и выбрать один раз, например, который будет произносить все объявления с точностью до 1 метра, а не чуть ниже 20 метров, как это делают наши стандартные голоса.

Но теперь я понимаю, что наши стандартные голоса вполне подходят для ваших целей, то, что вам нужно, это делать чаще, автоматические объявления, когда вы приближаетесь к чему-то, верно?

It is necessary that the application becomes a kind of guide for the blind and if the blind need to make a maneuver along the route, then let the application give prompts not 20 meters before the turn or arrival, but at that moment when you really need to turn. There is nothing wrong with the fact that the application gives hints automatically along the route, which is even good! But when 5-10 meters are left before the maneuver or arrival, and the application gives a notification that you already need to turn or say that you have arrived, although before arrival at least 5-10 meters is not normal.

[NaviMen]

What is needed is not “Frequent” but “Accurate” notifications!

[sonora]

As I said - we have up to 1 meter accuracy already, that's all there is. :)

[NaviMen]

Как я уже сказал - у нас уже есть точность до 1 метра, вот и все. :)

You want to say that notifications will come when not 5 meters, but 1 will remain before the maneuver? And notifications of arrival will be for 1 meter, and not 10?

[vshcherb]

@sonora do we have precise notification, I was not aware of it. As I see TURN_DISTANCE = 15; for pedestrian and it is not 0. It is mentionned to be 7,5sec with speed 6 kmh

[vshcherb]

@NaviMen probably lowering default speed will help though I don't see we use it for now.

@sonora I think we can start using default speed for pedestrian profile or make them even parameterised.

[NaviMen]

@NaviMen, вероятно, поможет снижение скорости по умолчанию, хотя я не вижу, чтобы мы использовали ее сейчас.

@sonora Я думаю, мы можем начать использовать скорость по умолчанию для профиля пешехода или сделать их даже параметризованными.

My actions? Eager to test! :)

[vshcherb]

Related commit - https://github.com/osmandapp/Osmand/commit/413092310e34bf58677e89c99997b3a4a7e2f0b3.

In general we can achieve 1 meter accuracy probably though we need to make GPS_ERROR configurable as I see. Cause for majority of cases pedestrian or whatever vehicle should hear announcement earlier than 10m due to GPS inaccuracy. Important to hear announcement "Turn now" earlier than later. Of course there are devices with 1m precision and OsmAnd maps maintain 1-3 meter precision on average. Though it doesn't make sense to make announcement distance lower than 10m (with GPS_ERROR=10m) and 1m with GPS_ERROR = 0m.

Now I put GPS_ERROR = 0m but I'm going to introduce it somehow. Probably we can put that setting hidden in Development @sonora .

[NaviMen]

Related commit - 4130923.

In general we can achieve 1 meter accuracy probably though we need to make GPS_ERROR configurable as I see. Cause for majority of cases pedestrian or whatever vehicle should hear announcement earlier than 10m due to GPS inaccuracy. Important to hear announcement "Turn now" earlier than later. Of course there are devices with 1m precision and OsmAnd maps maintain 1-3 meter precision on average. Though it doesn't make sense to make announcement distance lower than 10m (with GPS_ERROR=10m) and 1m with GPS_ERROR = 0m.

Now I put GPS_ERROR = 0m but I'm going to introduce it somehow. Probably we can put that setting hidden in Development @sonora .

How complicated it is! Transfer the settings to the plug-in Accessibility, and about 10 meters, I say again, 10 meters or even 5 meters, this is nothing! All this is very easy to experience on yourself, just cover your eyes and go from point A to point B using the tips and you will understand what the blind want. People have been waiting for this functionality since 2015, and if everything works out, you will help many!

[vshcherb]

This is not that easy, we don't want to break all other users just by making mistake in the middle. Right now I've consolidated code for all situations to have good understanding what's going on. It is not that easy to change one number to another cause it breaks everything and we don't want to take out cause they nobody will maintain and nobody will remember what was behind these numbers. So it needs to be clear for all perspective.

So current situation:

1. Distance for Turn Now is dependent on default speed. If default speed is 1 kmh, 'Turn now' distance is 3.5 seconds i.e. 1 m. So, 1 meter precision always corresponds to 3 seconds if you are not moving faster than 1 kmh.
2. If you are moving faster than "Turn now" will be pronounced earlier to correlate with 3 seconds.

@sonora may be we can correct somehow these difference between 7/2 = 3.5 seconds for Turn Now speed.

[NaviMen]

Это не так просто, мы не хотим ломать всех других пользователей, просто делая ошибку в середине. Прямо сейчас я собрал код для всех ситуаций, чтобы хорошо понимать, что происходит. Нелегко поменять один номер на другой, потому что он ломает все, и мы не хотим вынимать, потому что они никто не будет поддерживать, и никто не вспомнит, что стояло за этими номерами. Так что это должно быть ясно для всех точек зрения.

Итак, текущая ситуация:

1. Расстояние до поворота сейчас зависит от скорости по умолчанию . Если скорость по умолчанию составляет 1 км / ч, расстояние «Повернуть сейчас» составляет 3,5 секунды, т.е. 1 м . Таким образом, точность в 1 метр всегда соответствует 3 секундам, если вы не двигаетесь быстрее 1 км / ч.
2. Если вы двигаетесь быстрее, чем «Turn now» будет объявлено раньше, чтобы соотнести с 3 секундами.

@sonora может быть, мы можем как-то исправить эту разницу между 7/2 = 3,5 секунды для скорости Turn Now.

When will it be possible to test?

[sonora]

Let's clarify a bit: the issue has at least 3 dimensions which became a bit convoluted in the thread above:

• [x] The precision announced in our voice prompts: We round to the nearest meter for close-up turns, so our code should be fine here.
• [ ] The timing of when prompts sound: I had tweaked that code to regular walking speed a long time ago, then documented it and have not looked at it ever since. We consider a mix of time-based rules, distance-based rules, and filter in GPS accuracy as a constant (as observed in many devices years ago). We should be able to create a 'vision impaired' parametrisation of this ped ruleset, to be activated as an alternative. Can take a look when I find time. Please note that, independent of the tricky issue of measurement accuracy, very precise announcements will only help you when you stand still. The faster you are moving the more you smear out the reference point for any distance announced.
• [ ] Frequency of prompting: Are you simply requesting the final prompt to be delayed until the device thinks you are right where the turn is? Or would you not need more frequent announcements as you approach, either based on some rule or to be triggered on demand?

[vshcherb]

@sonora, I commit few lines to consolidated solution for Turn distance but that needs to be checked. It almost didn't change for bicycle and car but it changed for pedestrian. Obviously most of this code is from 2015 where GPS precision was 10 m and now it is much more precise and obviously we could use some code there. I know that relying on magic formula is bad but we need to rely on 1 parameter cause we have too many different vehicles to configure and we need to make it dependent on speed at least.

Important: we have 2 parameters based on which we announce turn, distance (if distance is less it is announced) and time (if time is less based on current speed it is announced). Here we talk how to introduce 1 meter & 1 second precision "Turn now" which is good for slow speed vehicles.

Here some results from formula:

Speed	Time	Distance	Vehicle
1 km/h	1 sec	1 m	Custom
4 km/h	2 sec	4 m	Pedestrian
10 km/h	3.5 sec	10 m	Bicycle
15 km/h	4 sec	15 m	Custom Bicycle
25 km/h	5 sec	25 m	Custom Bicycle
50 km/h	7 sec	50 m	Car

@NaviMen it is possible to test with nightly builds already though it is not clear if it works with combination RoutingHelper - updateCurrentRouteStatus, I wouldn't change code there if it works already

[vshcherb]

Frequency of prompting - should not be a main problem, I think if you click on the big widget turn left then you hear exactly how many meters left to the turn

[vshcherb]

Please not that majority of current devices have GPS frequency of 1 second, so it doesn't make sense to go under 1 second no matter what is precision. Though it is worth to mention that if device keeps tracking your speed precision could be < 3 m but if you have too many high buildings around precision will be worth than > 20 m

[vshcherb]

I've tested last version myself bicycle / pedestrian (default settings) and unfortunately "Turn now" doesn't work for such low precision even default.

Speed	Time	Distance	Vehicle
1 km/h	1 sec	12 m	Custom
4 km/h	2 sec	15 m	Pedestrian
10 km/h	3.5 sec	20 m	Bicycle
15 km/h	4 sec	23 m	Custom Bicycle
25 km/h	5 sec	30 m	Custom Bicycle
50 km/h	7 sec	50 m	Car

So I recommend to try the latest version with these parameters at least it should work with 1 km/h. And then proceed with changes if they are needed. I've figured out myself that on average it works really strange cause the road could be pretty wide like 5-7 m which already gives an error + there is no good micro mapping in my area and overall. For example, sidewalk=true is mapped to highway, so in reality it is 10 meters away. So I think it is worth to try latest version with setting "1 km/h" which gives 2x precision comparing to previous release and give feedback.

@sonora I think it is a bug that proceeding a node in RoutingHelper skips voice annoucement . I think at RoutingHelper:610 we should call voiceRouter.updateStatus(... 1m);

[NaviMen]

The readings given above for a blind user are about nothing! It makes no sense then even to change something! Understand one thing, when 5 meters is left before arrival, and the navigator reports that you have arrived, this is not good.

[vshcherb]

"Finish" announcement is different then "Turn now", actually I forgot there is a special setting for Finish announcement and I aligned it now with speed and with setting ARRIVAL_DISTANCE_FACTOR. I think it is safe to use that setting cause it is mostly not used by user and it is safe to change voice announcement meters / seconds using that setting. Cause before release it is also important to maintain backward compatibility for default values.

@NaviMen I tested myself, I had almost perfect location 2 meters radius and if you are walking with speed > 0, you should hear in advance because of delays and computation and also GPS update frequency. I think current setup of 1 km/h and "Late meters" will be overkill and you will miss a turn. The situation I tested and I turned immediately was "4 kmh/h" and "Normal" and it was good for my walking speed. Overkill will result missing turn points and recomputing the route constantly .

I think it is only possible to test these parameters and again lowest possible setup Speed = 1 kmh and "Late meters" (should be nearly 1-2 m precision), which are not default and default are 10x higher resulting to 10 m.

[NaviMen]

Объявление «Готово» отличается от «Повернуть сейчас», на самом деле я забыл, что есть специальная настройка для объявления «Завершить», и теперь я настроил его по скорости и настройке ARRIVAL_DISTANCE_FACTOR. Я думаю, что использовать эту настройку безопасно, потому что она в основном не используется пользователем, и безопасно изменять метры / секунды голосового объявления, используя эту настройку. Причина до выпуска также важно поддерживать обратную совместимость для значений по умолчанию.

@NaviMen Я проверил себя, у меня было почти идеальное местоположение с радиусом 2 метра, и если вы идете со скоростью> 0, вы должны услышать заранее из-за задержек и вычислений, а также частоты обновления GPS. Я думаю, что текущая настройка 1 км / ч и «поздние метры» будут излишними, и вы пропустите поворот. Ситуация, которую я проверял и сразу поворачивал, была "4 км / ч" и "Нормальная", и это было хорошо для моей скорости ходьбы. Overkill приведет к отсутствию точек поворота и постоянному пересчету маршрута.

Я думаю, что это возможно только для тестирования этих параметров и снова минимально возможной настройки Speed ​​= 1 км / ч и «поздних метров» (должна быть точность почти 1-2 м), которые не являются значениями по умолчанию и по умолчанию в 10 раз выше, что приводит к 10 м.

Good! Now I will check. My actions? Download the nightly build and enable the option in the settings for developers?

[vshcherb]

Нет, эти настройки уже были - Выставляете скорость для профиля и выставляете когда оповещать об изменениях (На последних метрах). Я еще не тестировал все, поэтому если не работает, возможно надо поменять настройку, лучше посмотреть сначала настройки по умолчанию, а потом эти.

[vshcherb]

Build - https://download.osmand.net/latest-night-build/OsmAnd-nightly.apk

[NaviMen]

Нет, эти настройки уже были - Выставляете скорость для профиля и выставляете когда оповещать об изменениях (На последних метрах). Я еще не тестировал все, поэтому если не работает, возможно надо поменять настройку, лучше посмотреть сначала настройки по умолчанию, а потом эти.

Я так понимаю просто сначала запустить маршрут по умолчанию без настроек, а потом если не работает попробовать настроить?

[NaviMen]

Сборка - https://download.osmand.net/latest-night-build/OsmAnd-nightly.apk

Проверил сборку и так скажу! Разницы незаметно никакой! Как получал оповещения за 5 метров, так и получаю.

[sonora]

Welcome to the world of testing all this ... ;) I feel like back in 2015, five years younger, and spending weeks to finetune it all.

A lot of this is not exact science, there is a decent degree of overlapping uncertainty. Becoming overly ambitious with respect to pushing accuracy to the limit can finally defy the purpose: You may create too many real life situations where the output becomes just useless.

@vshcherb Regarding a potential bug in RoutingHelper:610 Not sure. I remember that jumps in processing the nodes occur quite often,by GPS reflections, bridges, etc. Have you tried not skipping? I would assume we would create a backlog of outdated prompts then?

[sonora]

PS: This can get a little tricky, it maybe a good practice to work in a separate branch?

[sonora]

PS: This is my documentation of 2015 or so: Section 6 "Lead distances (lead time)" under http://osmand.net/help-online/technical-articles#Voice_Routing_-_Current_Status_.28by_Hardy.29

I guess that these values have somehow proven useful over the years, so we should sort of stick in that neighborhood for 'regular use' while trying to add 'special' support as needed.

[vshcherb]

Well I don't plan to do much changes at least in this release anymore (except obvious flows), also I did change how. Critical parts right now: 1) All numbers for car kept saved and exactly the same 2) Timings for Bicycle navigation are slightly adjusted (lowered) but they can be returned to orignal values if you change Default Speed from 10 km/h -> 20 km/h 3) All numbers are replaced with continuous formula based on Default speed, so we don't need to deal any more with different profiles which could be erroneous. I think it is very important change cause Speed is configurable parameter and others were hidden and non-controlable actually. 4) Right now there are 2 settings Default Speed and ARRIVAL_DISTANCE_FACTOR . Most of the changes actually are done with ARRIVAL_DISTANCE_FACTOR, so now it actually impacts 4 places instead of 1.

I do like current setup and I think all key points are already in place and of course user can change Default Speed and also we could adjust internal values for ARRIVAL_DISTANCE_FACTOR. I don't know yet how to test 1 meter precision, well it could be tricky and I don't how to setup test-environment. Probably precise track recorded could help.

[NaviMen]

Ну, я больше не планирую делать много изменений, по крайней мере, в этом выпуске (кроме очевидных потоков), также я изменил как. Критические части прямо сейчас:

1. Все номера для машины сохранены и точно так же
2. Сроки для велосипедной навигации немного скорректированы (уменьшены), но их можно вернуть к исходным значениям, если вы измените скорость по умолчанию с 10 км / ч -> 20 км / ч.
3. Все числа заменяются непрерывной формулой, основанной на скорости по умолчанию, поэтому нам больше не нужно иметь дело с различными профилями, которые могут быть ошибочными. Я думаю, что это очень важное изменение, потому что скорость является настраиваемым параметром, а другие были скрытыми и фактически неуправляемыми.
4. Прямо сейчас есть 2 настройки скорости по умолчанию и ARRIVAL_DISTANCE_FACTOR. Большинство изменений на самом деле сделано с ARRIVAL_DISTANCE_FACTOR, так что теперь это фактически влияет на 4 места вместо 1.

Мне действительно нравится текущая настройка, и я думаю, что все ключевые точки уже на месте, и, конечно, пользователь может изменить скорость по умолчанию, а также мы можем настроить внутренние значения для ARRIVAL_DISTANCE_FACTOR. Я пока не знаю, как проверить точность в 1 метр, может быть, это сложно, и я не знаю, как настроить тестовую среду. Вероятно, может помочь точный записанный трек.

Хорошо! С этой темой закрыли тему! Тогда такой вопрос, возможно ли сделать оповещение точек POI избранных и GPX не как сейчас, а метров за 5?

[sonora]

Victor, I have now briefly reviewed all changes and like it! I think you've done a good job in simplifying what we've had for years now, without much risk. I will put it to some practical tests, but do not foresee much risk, though I've had my share of surprises with this... :)

[vshcherb]

I've tested yesterday, it looks like that default settings have no change even for pedestrian which is good and it keeps working as expected everything pronounced but 10-15 earlier which gives probably 4-6 seconds delay.

Then I lowered speed to 1 kmh and put to announce "Very late" and it looks like it works and it should announce at last meters "Turn now" but it doesn't have a chance. So in all my tests 4 out of 5 it failed and skipped to say "Turn now" basically it was omit completely.

So the issue is still there - RoutingHelper:610 we should call voiceRouter.updateStatus(... 1m). So this change is not that safe cause there are some situations when person already made a turn and 2nd "Turn now" could bring a lot of confusion. So this is the only change pending I feel for now, but it needs to be thought through to avoid situation with announcing same turn "twice" (actually once but late & confusing). I'm thinking now to introduce a threshold of 10 meters and it would be safe for default car/bicycle cause "Turn now" happens for these vehicles much earlier than 10 m.

[sonora]

Yes, my thoughts exactly. If we change RoutingHelper:610 as you suggest, and at the same time try to produce a "Turn now" type prompt extremely close to the turning point itself, we run the risk of hearing already obsolete prompts. Currently not sure how to mitigate that other than moving the prompt up by a reasonably tolerance interval - which may make them useless for the purpose intended.

Maybe a proper strategy for visual impairment assistance is more something like a continuously modulated sound (like is being used for blind biathletes shooting), it would facilitate more tolerance testing by moving back an forth, rather than a discrete one time "turn now" announcement which may bluntly mislead you at the wrong point in time.

[NaviMen]

Yes, my thoughts exactly. If we change RoutingHelper:610 as you suggest, and at the same time try to produce a "Turn now" type prompt extremely close to the turning point itself, we run the risk of hearing already obsolete prompts. Currently not sure how to mitigate that other than moving the prompt up by a reasonably tolerance interval - which may make them useless for the purpose intended.

Maybe a proper strategy for visual impairment assistance is more something like a continuously modulated sound (like is being used for blind biathletes shooting), it would facilitate more tolerance testing by moving back an forth, rather than a discrete one time "turn now" announcement which may bluntly mislead you at the wrong point in time.

What you offer does not fit! Okay, but can I cut down to 5 meters passing POI favorites and GPX points?

[vshcherb]

I think now we have solution unified and actually you could see / check now the distance for voice prompts for each turn. https://github.com/osmandapp/OsmAnd/issues/10386. For instant prompt - 0-5 m is selectable