Frequency of navigation hints settings confusion
I have few questions about the settings of the frequency of navigation hints, as manual does not say much.
I am not sure if I can see noticable differences when changing the settings.
Does the setting apply only for Locus generated hints, or for external ones as well - like of BRouter ?
Does that mean amount of hints per given navigation point ?
If applies of Locus hints only, does that mean number of generated nav. points - like turning sensitivity ?
In config file there are values 15,35,300 s for navigation hints. What is their meaning wrt to the hint frequency setting ?
I have noticed Locus is quite talkative with Brouter hints even with low hint Locus frequency, often for long distances, that take 1-few minutes to pass.
In relation to the topic, I have once noticed an issue, related probably to 60s avg of the current speed. I suppose the advance notification distance is calculated from given itime interval and the avg speed. When I was slowly climbing the hill, the avg speed droppped down. When I rode downhill fast on the other hill side, the avg speed could not accommodate quickly. It may counted with too short advance distance to notify me, thinking I was still slow. I was notified almost too late to pull the breaks to slow down and to make a sharp turn, with the first notification some 60-80 m ahead.
P.S.> Unless there was some unnoticed GPS signal drop and Locus noticed the hint position at the last moment, as GPS worked fine before and after....
The same question
Good day Libor,
thank you for interesting question.
This settings is applied only to generated navigation commands by Locus, not on commands generated by routing services itself. So in case, you use new BRouter which generates commands on itself, this settings won't have no effect.
What this settings do? Well, Locus tests shape of track and in case, there is any curve, it generates new command in it's most curved place. And how sharp this change or direction needs to be to generate command there, is defined by this parameter.
Parameters you found in configuration file ( 15,30,300 ), has nothing to do with this. They just say, number of seconds when Locus notify on navigation command, before you arrive to that place. And yes, time to command is computed from distance and current average speed that I mentioned on another place, as average from last 60 seconds.
(five minutes later) I've rather check it to not to talk some nonsences. And in case of navigation, I use one different speed. it's computed from last 5 minutes, not just 60 seconds and is used just for navigation. I remember that 60 seconds was too short and it has really negative effect on estimated times in case, you have changed speed more frequently, mainly in a car.
Oki, I'll try to reduce it to three minutes, which should be good compromise. If there will be still some issues like you had, it will probably needs a little bit better algorithm that will do shorter average (1 - 2mins) for lower speeds (bike, foot) and longer (3 - 5mins) for higher speeds (moto, car).
Better?
Good day Libor,
thank you for interesting question.
This settings is applied only to generated navigation commands by Locus, not on commands generated by routing services itself. So in case, you use new BRouter which generates commands on itself, this settings won't have no effect.
What this settings do? Well, Locus tests shape of track and in case, there is any curve, it generates new command in it's most curved place. And how sharp this change or direction needs to be to generate command there, is defined by this parameter.
Parameters you found in configuration file ( 15,30,300 ), has nothing to do with this. They just say, number of seconds when Locus notify on navigation command, before you arrive to that place. And yes, time to command is computed from distance and current average speed that I mentioned on another place, as average from last 60 seconds.
(five minutes later) I've rather check it to not to talk some nonsences. And in case of navigation, I use one different speed. it's computed from last 5 minutes, not just 60 seconds and is used just for navigation. I remember that 60 seconds was too short and it has really negative effect on estimated times in case, you have changed speed more frequently, mainly in a car.
Oki, I'll try to reduce it to three minutes, which should be good compromise. If there will be still some issues like you had, it will probably needs a little bit better algorithm that will do shorter average (1 - 2mins) for lower speeds (bike, foot) and longer (3 - 5mins) for higher speeds (moto, car).
Better?
Better. :-) But I think the averaging interval for ETA should be independent on interval for estimation of hint advance notification. As the ETA is much less dynamic than the distance passed in given time.
I suppose 3 min is too short for ETA, but too long for hints - especially for bikes, as their speed is very variable..
Better. :-) But I think the averaging interval for ETA should be independent on interval for estimation of hint advance notification. As the ETA is much less dynamic than the distance passed in given time.
I suppose 3 min is too short for ETA, but too long for hints - especially for bikes, as their speed is very variable..
For the hint, good would be filter as avgpeed = K . previousavgspeed + ( 1-k) . immediatespeed.
It is averaging as well, but not linearly, It is old good well known exponential filter, giving the most weight to the most recent speed values.
If K is e.g. 0.96, it is more or less like 25 s average, but with putting more stress on recent values.. As recent values are the most important for the hint notification.
For the hint, good would be filter as avgpeed = K . previousavgspeed + ( 1-k) . immediatespeed.
It is averaging as well, but not linearly, It is old good well known exponential filter, giving the most weight to the most recent speed values.
If K is e.g. 0.96, it is more or less like 25 s average, but with putting more stress on recent values.. As recent values are the most important for the hint notification.
Hmm good idea with separate usage of both values for different purpose.
Fine, so changed. Short average with quick changes will be now used for compute of time to next navigation commands. Slowly changed average will be then used for ETA times that has usually no direct impact on navigation announcements. Thanks! And if 60 seconds will be still too much ... it needs some testing I think. Currently was used 5 minutes, so it will be definitely a lot lot better now.
EDIT: ah I missed your second post. This has one big disadvantage I see - it ignore time differences between values. So where there will be 15 seconds break because of some problem in GPS, interval will be 40 seconds and not 25s - not a big deal. I have small function that do this averaging for me and I've already prepare possibility to enable weighs based on time. So if announcements won't be fast enough, I should make this time shorter or enable weights. We will see.
Hmm good idea with separate usage of both values for different purpose.
Fine, so changed. Short average with quick changes will be now used for compute of time to next navigation commands. Slowly changed average will be then used for ETA times that has usually no direct impact on navigation announcements. Thanks! And if 60 seconds will be still too much ... it needs some testing I think. Currently was used 5 minutes, so it will be definitely a lot lot better now.
EDIT: ah I missed your second post. This has one big disadvantage I see - it ignore time differences between values. So where there will be 15 seconds break because of some problem in GPS, interval will be 40 seconds and not 25s - not a big deal. I have small function that do this averaging for me and I've already prepare possibility to enable weighs based on time. So if announcements won't be fast enough, I should make this time shorter or enable weights. We will see.
for inspiration, I provide an Excel chart for speed filtering by moving arithmetic avg and Exponential filter.
for inspiration, I provide an Excel chart for speed filtering by moving arithmetic avg and Exponential filter.
Hello Libor,
thanks for filtering introduction. Oki, let's improve it little bit.
I'm testing it and seems that in this case, smoothing factor 0.99 needs 207 seconds till it filter value from 10km/h to 45 km/h. Sounds to me like a optimal value for ETA times, where we do not want too quick changes. Change to half of value (30 km/h) is done after 70 secs, which should be enough to withstand some stops in car on red lights.
For better timing of navigation voice announcements, we needs faster reactions as you correctly mentioned. As I look on my charts, factor 0.9 cause change to 45km/h after 20 secs, change to half ( 30 km/h ) after 7 seconds. This sounds usable.
Are you able to improve simple exponential filter with some "time weight"? Because in case, there will be gap in GPS measurements, it should be handled by filter a little bit.
So something like: (for faster version of filter)
alfa = 0.90 * ( 1 / dT^1/3 ) 'where dT is difference in time'
avgSpeed = alfa * previousSpeed + ( 1 - alfa ) * current speed
I'm sure, you will have something better for reducing smoothing factor, then third root of 'dT'. I just wanted to reduce effect of this dT factor.
Thank you for your time and suggestions!
EDIT: seems that this should work. 30 seconds gap, reduce smoothing factor to 0.28, which cause almost immediate change in average speed (just three seconds to 49 km/h). Which is wanted after such huge time gap.
Hello Libor,
thanks for filtering introduction. Oki, let's improve it little bit.
I'm testing it and seems that in this case, smoothing factor 0.99 needs 207 seconds till it filter value from 10km/h to 45 km/h. Sounds to me like a optimal value for ETA times, where we do not want too quick changes. Change to half of value (30 km/h) is done after 70 secs, which should be enough to withstand some stops in car on red lights.
For better timing of navigation voice announcements, we needs faster reactions as you correctly mentioned. As I look on my charts, factor 0.9 cause change to 45km/h after 20 secs, change to half ( 30 km/h ) after 7 seconds. This sounds usable.
Are you able to improve simple exponential filter with some "time weight"? Because in case, there will be gap in GPS measurements, it should be handled by filter a little bit.
So something like: (for faster version of filter)
alfa = 0.90 * ( 1 / dT^1/3 ) 'where dT is difference in time'
avgSpeed = alfa * previousSpeed + ( 1 - alfa ) * current speed
I'm sure, you will have something better for reducing smoothing factor, then third root of 'dT'. I just wanted to reduce effect of this dT factor.
Thank you for your time and suggestions!
EDIT: seems that this should work. 30 seconds gap, reduce smoothing factor to 0.28, which cause almost immediate change in average speed (just three seconds to 49 km/h). Which is wanted after such huge time gap.
If GPS signal is restored after N seconds, then I would set
avgspeed = alfa^N * avgspeedNsecsAgo + ( 1 - alfa^N ) * immediateSpeedAfterGPSrestore
The longer the gap is, the weaker is weight of previous avg and more weight is put on immediate speed after GPS restore.
OTOH, the longer is time constant - like for the ETA, the less impact the same gap causes, and the weakening of old avgspeed weight is slower.
Edit> During GPS loss, I would try for some time to keep last known avgspeed and try extrapolate distance to next navigation point and generate the hints like if GPS was working.
If GPS signal is restored after N seconds, then I would set
avgspeed = alfa^N * avgspeedNsecsAgo + ( 1 - alfa^N ) * immediateSpeedAfterGPSrestore
The longer the gap is, the weaker is weight of previous avg and more weight is put on immediate speed after GPS restore.
OTOH, the longer is time constant - like for the ETA, the less impact the same gap causes, and the weakening of old avgspeed weight is slower.
Edit> During GPS loss, I would try for some time to keep last known avgspeed and try extrapolate distance to next navigation point and generate the hints like if GPS was working.
so, if we have alfa 0.99 for ETA, than in case of 1 min GPS outage, 0.99^60 = cca 0.55
Aften 1 min, there would be one time calculation
avgspeedNew = 0.55 . avgspeedOld + 0.45 . immediateSpeed.
Similarly, if alfa = 0.90 for hint advance notifications, and if outage is 10s, 0.90^10 = cca 0.35
So after 10s, avgspeedNew = 0.35 . avgSpeedOLD + 0.65 . immediateSpeed
so, if we have alfa 0.99 for ETA, than in case of 1 min GPS outage, 0.99^60 = cca 0.55
Aften 1 min, there would be one time calculation
avgspeedNew = 0.55 . avgspeedOld + 0.45 . immediateSpeed.
Similarly, if alfa = 0.90 for hint advance notifications, and if outage is 10s, 0.90^10 = cca 0.35
So after 10s, avgspeedNew = 0.35 . avgSpeedOLD + 0.65 . immediateSpeed
Thank you Libor for a help. appreciate it.
New filter implemented.
Thank you Libor for a help. appreciate it.
New filter implemented.
You are welcome.
As I help improving Locus even for myself, it is not as honourable as it seems to be... :-)
Kalman filter would give better results, but these filters are more complicated. OTOH, running exponential filter is even easier than running sliding average.
You are welcome.
As I help improving Locus even for myself, it is not as honourable as it seems to be... :-)
Kalman filter would give better results, but these filters are more complicated. OTOH, running exponential filter is even easier than running sliding average.
A second thought - I suppose as initial avgspeed value there should be used some nominal speed
like e.g. 60-80/20/5 km/h, and this value should perhaps be used instead immediate speed after GPS loss..
As immediate speed after some longer GPS loss could corrupt the avgspeed value, if by chance it was very different to the previous avg, and the avgspeed would then need some time to adapt back to long term value.
This is valid especially for ETA, for the hints the immediate one is fine.
If GPS signal is restored after N seconds, then I would set
avgspeedForETA = alfa^N * avgspeedForETANsecsAgo + ( 1 - alfa^N ) * NominalSpeed
Or, I would even keep avgspeed constant until GPS is back again, as avgspeed for ETA is long term parameter.
A second thought - I suppose as initial avgspeed value there should be used some nominal speed
like e.g. 60-80/20/5 km/h, and this value should perhaps be used instead immediate speed after GPS loss..
As immediate speed after some longer GPS loss could corrupt the avgspeed value, if by chance it was very different to the previous avg, and the avgspeed would then need some time to adapt back to long term value.
This is valid especially for ETA, for the hints the immediate one is fine.
If GPS signal is restored after N seconds, then I would set
avgspeedForETA = alfa^N * avgspeedForETANsecsAgo + ( 1 - alfa^N ) * NominalSpeed
Or, I would even keep avgspeed constant until GPS is back again, as avgspeed for ETA is long term parameter.
I think that help in this area is always honorable :). I studied some filtering methods on university little bit, but it never was my favorite subject. I even did a work about Kalman filter and it's practical implementation is even done in application SmartMaps, but results wasn't a lot better then measured values, so same system is not in Locus for now.
Anyway back to topic. I noticed this also during testing. Big gap cause big change in computed times and it takes quite a long time to get back to "correct" values.
This is not just about break in GPS signal - this is not so frequent. Imagine simple example on bike (maybe rather car where are bigger changes in speed) ... you stop on red road signal for a two minutes. ETA time should remain same! And it will be, because Locus compute average moving speed (speed from last ~5 minutes) only when you are really moving (speed above 0.5m/s). Anyway immediately after you start on green after two minutes, smoothing factor get kick: 0.98^120 = 0.08 and ETA time jumps really a lot. This was covered with average after last 5 minutes (previous system) and such big changes had small effect on final average.
Nominal speed should be quite a problem - various value needed for different situation. I think about some limit on time difference. If we set that max. gap should be 5 seconds, then on quickly changing average speed, this will be fast enough: 0.90^5 = 0.59 , on slowly changing speed, this won't have huge effect 0.98^5 = 0.90. This seems to me like a good compromise.
I think that help in this area is always honorable :). I studied some filtering methods on university little bit, but it never was my favorite subject. I even did a work about Kalman filter and it's practical implementation is even done in application SmartMaps, but results wasn't a lot better then measured values, so same system is not in Locus for now.
Anyway back to topic. I noticed this also during testing. Big gap cause big change in computed times and it takes quite a long time to get back to "correct" values.
This is not just about break in GPS signal - this is not so frequent. Imagine simple example on bike (maybe rather car where are bigger changes in speed) ... you stop on red road signal for a two minutes. ETA time should remain same! And it will be, because Locus compute average moving speed (speed from last ~5 minutes) only when you are really moving (speed above 0.5m/s). Anyway immediately after you start on green after two minutes, smoothing factor get kick: 0.98^120 = 0.08 and ETA time jumps really a lot. This was covered with average after last 5 minutes (previous system) and such big changes had small effect on final average.
Nominal speed should be quite a problem - various value needed for different situation. I think about some limit on time difference. If we set that max. gap should be 5 seconds, then on quickly changing average speed, this will be fast enough: 0.90^5 = 0.59 , on slowly changing speed, this won't have huge effect 0.98^5 = 0.90. This seems to me like a good compromise.
I more and more think, regarding ETA, that Locus should keep avgspeed constant during the GPS gap. As it is quite good estimation that the speed during the gap is in average equal the avgspeed. Significant consideration of immediate speed after the gap makes unjustified jitters in avgspeed and therefore ETA.
The pauses with zero-speed I would treat the same as GPS gaps - keeping old avgspeed.
I was considering nominal speeds for ETA only. The avgspeed needs some initial value. Starting with near zero or immediate speed leads to a leading time, while adapting from nominal speed makes initial avgspeed closer to real value. would have lower initial error.
Initial nominal speeds or keeping old avgspeed would have advantage of even possibly increased ETA alfa above 0.99 ( as I consider 0.99 still low ) . There would be no need for quick adaption and significant exponential weighting would be spreaded across longer interval.
ETA estimation is tricky and involves both short term and long term speed averages. 5 min avgspeed 130 km/h is not useful, if we turn to slow tertiary road then or otherwise. OTOH, long term average is not useful either, if final part of route is way different from the average., Exponential filters by easy way combines both in single simple formula.
You used 0.98 but previously we spoke about 0.99. I suppose 0.99 rather small and 0.98 definitely small for ETA.
If jumpes are eliminated, there is no need for quick avgspeed adaption.
I more and more think, regarding ETA, that Locus should keep avgspeed constant during the GPS gap. As it is quite good estimation that the speed during the gap is in average equal the avgspeed. Significant consideration of immediate speed after the gap makes unjustified jitters in avgspeed and therefore ETA.
The pauses with zero-speed I would treat the same as GPS gaps - keeping old avgspeed.
I was considering nominal speeds for ETA only. The avgspeed needs some initial value. Starting with near zero or immediate speed leads to a leading time, while adapting from nominal speed makes initial avgspeed closer to real value. would have lower initial error.
Initial nominal speeds or keeping old avgspeed would have advantage of even possibly increased ETA alfa above 0.99 ( as I consider 0.99 still low ) . There would be no need for quick adaption and significant exponential weighting would be spreaded across longer interval.
ETA estimation is tricky and involves both short term and long term speed averages. 5 min avgspeed 130 km/h is not useful, if we turn to slow tertiary road then or otherwise. OTOH, long term average is not useful either, if final part of route is way different from the average., Exponential filters by easy way combines both in single simple formula.
You used 0.98 but previously we spoke about 0.99. I suppose 0.99 rather small and 0.98 definitely small for ETA.
If jumpes are eliminated, there is no need for quick avgspeed adaption.
The nominal speed initial value idea can be replaced by small and frowing initial values of alfa.
E.g. for final alfa 0.99, leading alfa values for t=1..99 s would be alfa(t) = t/(t+1)
The nominal speed initial value idea can be replaced by small and frowing initial values of alfa.
E.g. for final alfa 0.99, leading alfa values for t=1..99 s would be alfa(t) = t/(t+1)
I take it now as an idea of avgspeed correction for ETA after gap or pause was amistake.
If old value is kept, avgspeed can afford long time constant for ETA, addressing involvement of speed average for both short-time ( last few minutes ) and long time ( asymptotically spreaded across significant part of the route ) .
Fast initial avgspeed setting for ETA can be obtained by temporary lower alfa, like for nav. hints.
I take it now as an idea of avgspeed correction for ETA after gap or pause was amistake.
If old value is kept, avgspeed can afford long time constant for ETA, addressing involvement of speed average for both short-time ( last few minutes ) and long time ( asymptotically spreaded across significant part of the route ) .
Fast initial avgspeed setting for ETA can be obtained by temporary lower alfa, like for nav. hints.
Thanks. I think we should wait on next field testing.
I was aware of these possible problems also, so last system I did during morning remember last average speed when you turned off GPS and use it as initial speed after you turn GPS back. Together with using speed values only when device is moving, I think that results should be quite usable.
Thanks. I think we should wait on next field testing.
I was aware of these possible problems also, so last system I did during morning remember last average speed when you turned off GPS and use it as initial speed after you turn GPS back. Together with using speed values only when device is moving, I think that results should be quite usable.
We will later see, if alfa 0.99 is high enough ( time constant long enough ) wrt changes of the road classes. As short time interval filters, and especially arithmetical average, are not reliable for rectangular-like patterns of route speed profile.
Edit: So optimal time constant ( alfa = 1 - 1/timeconstant ) may be a trade off of guessing game:
To be short enough to adapt to avg speed of the current road in case it lasts
and
to be long enough not to adapt to avg speed of the current road in case it does not last.
It is quite possible the optimal time constant is comparable to statistical average how often one changes the roads - but I guess there is no way but field testing of good alfa value.
We will later see, if alfa 0.99 is high enough ( time constant long enough ) wrt changes of the road classes. As short time interval filters, and especially arithmetical average, are not reliable for rectangular-like patterns of route speed profile.
Edit: So optimal time constant ( alfa = 1 - 1/timeconstant ) may be a trade off of guessing game:
To be short enough to adapt to avg speed of the current road in case it lasts
and
to be long enough not to adapt to avg speed of the current road in case it does not last.
It is quite possible the optimal time constant is comparable to statistical average how often one changes the roads - but I guess there is no way but field testing of good alfa value.
I suggest for eventual discussion this topic in forum
Avg speed filters and ETA estimation
I suggest for eventual discussion this topic in forum
Avg speed filters and ETA estimation
Replies have been locked on this page!