When MoNav learned to speak
Ch. Eckert
http://www.christeck.de/wp/2011/12/20/when-monav-learned-to-speak/
That's it. No usable result, but I hope to proceed during the next weeks
and months.
--
Beste Grￜￜe,
Best regards,
ce
Ch. Eckert
http://code.google.com/p/monav/source/browse/?name=permaroute
As anticipated, creating useful speech output is more than demanding.
It's quite challenging, and frankly, I'm not suprised about that.
The current code contains ugly hacks (Stevie Wonder would sing ï¿œIsn't it
uglyￜ) and is anything else than usable (exept for hardcore OSM addicts
like me, of course).
What I have done so far
* Persistent route
MoNav now is capable of detecting whether the current position is near
the computed route or not. This helps to take GPS inaccuracy into
account. The route is not recalculated at each GPS update anymore.
Instead, MoNav checks whether ther current position is near one of the
route's segments. If so, it keeps the route (or truncates it in case the
vehicle moves along the route). In case the vehicle leaves the route for
more than x meters, MoNav recalculates the route.
* Position clicking
Clicking the source on the map now behaves like a moving vehicle. In
case the click is near the route, it will either be shortened, retained
or recomputed as if the click was a real GPS position. This mainly
serves for debugging purposes, but is useful for demonstration anyway.
* Audio output
MoNav now is capable of playing back prerecorded audio samples. As a
preparation for improved turn instructions, the audio output can handle
a QStringList of filenames to play back. This allows for features like
"In 100 meter" "turn left" "then" "turn right".
* Routing issues
The work on spoken turn instructions shows a lot of issues with MoNav's
routing. Consider a small deviation in a residential area and a
branching of a motorway link. While in the first case, you don't want to
announce a "turn slightly right in 100 meters", you expect something
like "keep right in 100 meters" in the latter case. Appearenly it was
desirable to gain more information about the context of a crossing.
Additionally, it was desirable to get better turn restrictions from the
router directly. See the attached hard copies. I have no clue how to
cope with such situations correctly. But I hope we agree that such
routes are rather difficult to cope with.
That's less than the tip of an iceberg. It's just what I've seen while
writing the very first turn instruction code. Which means we need people
aware of and hacking on the issues.
It's fun anyway. For my personal needs, bike routing is more important
than car routing. And I guess it will be easier to cope with :) .
Yes, it's plain fun to use the Xmas holidays for hacking MoNav. I'm
still grateful that MoNav exists and the code is such a joy to read.
Thanks to all involved :) .
Christian Vetter
Nice Christmas present for us *g*. I'll have a look it during the week.
On Tue, Dec 27, 2011 at 2:02 AM, Ch. Eckert <geee...@gmx.net> wrote:
> * Persistent route
>
> MoNav now is capable of detecting whether the current position is near the
> computed route or not. This helps to take GPS inaccuracy into account. The
> route is not recalculated at each GPS update anymore. Instead, MoNav checks
> whether ther current position is near one of the route's segments. If so, it
> keeps the route (or truncates it in case the vehicle moves along the route).
> In case the vehicle leaves the route for more than x meters, MoNav
> recalculates the route.
Very nice, this feature has been absent for quite a while *g*.
> * Audio output
>
> MoNav now is capable of playing back prerecorded audio samples. As a
> preparation for improved turn instructions, the audio output can handle a
> QStringList of filenames to play back. This allows for features like "In 100
> meter" "turn left" "then" "turn right".
Maybe we can re-use some of the Marble audio files?
> * Routing issues
>
> The work on spoken turn instructions shows a lot of issues with MoNav's
> routing. Consider a small deviation in a residential area and a branching of
> a motorway link. While in the first case, you don't want to announce a "turn
> slightly right in 100 meters", you expect something like "keep right in 100
> meters" in the latter case. Appearenly it was desirable to gain more
> information about the context of a crossing.
Maybe we should come up with some specs what kind of maneuver we want
to generate in what situation, and then I'll include the necessary
data. We could also make much more data available in a slow manner (
about 8ms per road segment ) since we only need to generate maneuver
instructions lazily. This could be done in a relative space efficient
manner.
> Additionally, it was desirable to get better turn restrictions from the
> router directly. See the attached hard copies. I have no clue how to cope
> with such situations correctly. But I hope we agree that such routes are
> rather difficult to cope with.
Does OSM contain turn restrictions for that junction? If it does, we
can fix this, using an extended routing algorithm I've been working
on. It would most likely increase the routing data size by a factor 2
or so - so we should consider whether it's worth it.
> Yes, it's plain fun to use the Xmas holidays for hacking MoNav. I'm still
> grateful that MoNav exists and the code is such a joy to read. Thanks to all
> involved :) .
Thanks for your contributions so far, you have become an essential
part of MoNav :-P
Best regards,
Christian
Christoph Eckert
though I do not own a car, I rent one for an hour last thursday to test
MoNav on the N900 while cruising through the city of Karlsruhe. The
results are pleasing, but often surprising still. If only the weather
would be less rainy I'd use the bike for more real life tests.
I've removed the previous descriptiongenerator. On-screen and speech
output now is managed by a dedicated class called instructiongenerator,
though not unified yet. Its code does what I intended, but I dislike it.
I hope to do a major rewriteduring the upcoming weeks.
I've also experimented with the inclusion of CppUnitLite. It's not
present ATM, but I'd like to reintroduce it especially for the methods
which decide which speech output to generate based on the current speed,
type and length of the edges - in case noone objects.
The speech snippets are still included in the binary. As the amount will
not decrease, I need to figure out how to install (and find) them as
true filesystem files on each target machine. I've postponed this until
I'm halfway pleased with the speech output.
The output of speech and text instructions has become a preference
setting. The sole purpose of the lock button now is to link the source
indicator to the current GPS position.
Less surprisingly, the hacks triggered a whole bunch of entries in my
wish and TODO lists. E.g. I'd like to leave the plus and minus buttons
of the N900 to control the volume instead of the zoom in case speech
output is enabled and a route is present. Or a autozoom feature, which
zooms in and out dependent on speed and the situation at hand.
Obviously there's still a lot of fun ahead :) .
Ch. Eckert
> Nice Christmas present for us *g*.
well it was planned as one, but took longer than expected :) .
[…]
> Very nice, this feature has been absent for quite a while *g*.
I even remember the MoNav author mentioning this issue a couple of
months ago. Sometimes patience pays out :) .
[…]
> Maybe we can re-use some of the Marble audio files?
Didn't know about, and didn't find them neither in the Mac package nor
the git repo. Anyway, creating own samples is not really an issue, as it
is done by some shell script on my Mac which provides good quality multi
lingual speech synthesis.
[…]
> Maybe we should come up with some specs what kind of maneuver we want
> to generate in what situation, and then I'll include the necessary
> data. We could also make much more data available in a slow manner (
> about 8ms per road segment ) since we only need to generate maneuver
> instructions lazily. This could be done in a relative space efficient
> manner.
Meanwhile I did some more work and I learned a lot. I think I first
should learn more what is already possible with the existing data and
where things cannot be done due to lack of context. E.g., the turning
angle currently just take the node before and after the crossing into
account. Just by analysing a couple more nodes, I hope to be able to
improve the situation.
> Does OSM contain turn restrictions for that junction? If it does, we
> can fix this, using an extended routing algorithm I've been working
> on. It would most likely increase the routing data size by a factor 2
> or so - so we should consider whether it's worth it.
For my very own use, I do not need this feature. After I got speech
output working for cars, I'll focus on bike routing - which is the real
motivation for my efforts.
[…]
> Thanks for your contributions so far, you have become an essential
> part of MoNav :-P
Or the other way around - MoNav has become an essential part of mine ;-) .
--
Beste Grüße,
Best regards,
ce
Bernd Battes
Hello Christian,
just now, I am searching the net for the possibility to make voice
navigation in a precise way through offline access to OSM data while
navigating along a route to get more infos e.g. about the context of a
junction heading to.
While searching, I first came across MoNav which I find is a great
tool with its offline routing and rendering capabilities. (It's a pity
that it is so hard to compile on windows platform for use on android
as I can read in some posts).
And now I see, that you are even discussing speech output for MoNav as
well.
To explain my motivation to this writing I have to tell some
background.
I mainly use navigation on my cycle. And as my current device is a 7"
tablet it is hard to keep it charged while cycling and navigating.
Despite my dynamo hub charging system.
The screen with 1024*600 pixel consumes a lot, and in sunshine I don't
see anything but it eats even more power.
And as well climbing up hills takes much longer than heading them down
again. So long time littel charging and littel time good charging.
An other thing is that it is much more nice to watch the landscape
than the device screen.
So speech output with the possibility to switch off the screen for me
would be a great thing. But it needs to be accurate. It often happens
that you reach a crossing and the navi says e.g. turn left in x
meters. But there are two or more possibilities to turn left. Giving a
turn angle is to imprecise as GPS data isn't that accurate and anyway
an angle value isn't always intuitive.
So I think it would help if the navi knew which number in a row of
branches the correct turn is. Similar to as it is already done for
roundabouts.
I have the impression, that meanwhile data in OSM is that detailed
that it should be possible (At least in Germany).
For me it seems that a lot of the necessary information is already
present in MoNav or easy to get. The main thing is that there is
offline access to OSM data to find how many branches a junction /
crossing has. (Does 'GPS Lookup' already contain such info?)
For me it could be interesting both, following your project, or
playing around a bit for myself, if it is possible to get some infos
how to access and interpret your preprocessed data.
Sadly I am not a 'real programmer' but an amateur. For me I would try
to realize this access and the speech output with python, as I can do
that easily on an android (as long as I don't need access to the
canvas). But if there is anything I could help you I would like to.
Thanks a lot before,
best,
Bernd
Christoph Eckert
> And now I see, that you are even discussing speech output for MoNav as
> well.
I have been working on this, yes.
> So speech output with the possibility to switch off the screen for me
> would be a great thing. But it needs to be accurate. It often happens
> that you reach a crossing and the navi says e.g. turn left in x
> meters. But there are two or more possibilities to turn left. Giving a
> turn angle is to imprecise as GPS data isn't that accurate and anyway
> an angle value isn't always intuitive.
> So I think it would help if the navi knew which number in a row of
> branches the correct turn is. Similar to as it is already done for
> roundabouts.
> I have the impression, that meanwhile data in OSM is that detailed
> that it should be possible (At least in Germany).
The problem you mention is hard to cope with. Currently MoNav provides
an angle which can be used for speech output, including the issue you
mention. On such crossings, it will always be necessary to switch on the
device and have a look at the screen.
> For me it could be interesting both, following your project, or
> playing around a bit for myself, if it is possible to get some infos
> how to access and interpret your preprocessed data.
> Sadly I am not a 'real programmer' but an amateur. For me I would try
> to realize this access and the speech output with python, as I can do
> that easily on an android (as long as I don't need access to the
> canvas). But if there is anything I could help you I would like to.
Compilation for Android is not straightforward. I got a Hello world
application running. MoNav compiled as well, but crashes during startup.
Alternatively you could try to get a N900 (maybe s/h). The code that
does speech output just needs minor adjustment work, but is not capable
of generating professional grade navigation instructions.
Alternatively you could try OsmAnd. Its routing isn't that superb than
the one of MoNav, and speech output AFAIR is only available as an
experimental build. But in contrary to MoNav, it's a native Andoid
application and under active development.
A N900, however, is much more handy. The summer will show whether I'll
keep or replace it by a Defy+.
--
Beste Gr��e,
Best regards,
ce
bern...@gmail.com
thanks a lot for your reply.
> So I think it would help if the navi knew which number in a row of
> branches the correct turn is. Similar to as it is already done for
> roundabouts.
The problem you mention is hard to cope with.
neighbouring nodes of branches with their coresponding coordinates to a specific node
identified through the coordinates of the next point on my route?
In my imagination it should be possible as you use this data for routing.
If it is possible I would be very grateful if you could give me a hint where to find
information on how to access and interpret the files of the preprocessed data, to
be able to have a look into it.
I already had a look into the repositry but couldn't identify myself where the
preprocessed files are read and how they are structured.
It would be very handy in size as well if I could work with the preprocessed data files
as I would only need the ones for routing.
Thank you very much.
Best,
Bernd
Christoph Eckert
> If it is possible I would be very grateful if you could give me a hint
> where to find
> information on how to access and interpret the files of the preprocessed
> data, to
> be able to have a look into it.
I guess only Christian can answer such questions, but he's quite busy ATM.
bern...@gmail.com
Thanks for your reply.
I guess only Christian can answer such questions, but he's quite busy ATM.
@ Christian:
If you could find a little time to clarify whether it is possible to find all branches to a specific node with the help of your preprocessed data it would be very nice. (And if - how to)
But no hurry! I will have a look into this discussion from time to time. And anyhow for the rest of the week I will be off for ski touring :-)
What I have tried so far is to grab x y values out of (Andorra) places.pqdb and ways.motorway.pqdb which lay within the min/max values as in MoNav.ini.
The x y values I calculated according to tile-write.cpp line 90ff (Way::init(FILE *fp)).
But it didn't happen to get meaningful values at all. (Byte-order issue?)
For the files in the routing_.... folders I couldn't find any hint about their structure.
Thanks in advance,
Best regards,
Bernd
Christian Vetter
Sorry for the very long delay in answering, I head several deadlines
at work that required some effort :-D
Due to the structure of MoNav's routing algorithm we do not have the
information about adjacent streets ( the main speed advantage of the
algorithm comes from the fact, that we only have to look at about 400
roads for a cross-Europe route ).
I can see how this can be important for generating turn instructions.
So far I could think of two solutions for this:
- Have a separate data storage to query this information ( maybe even
a plugin to generate maneuvers )
- Pre-calculate maneuvers in the routing plugin. E.g. each edge in
the routing graph represents a series of streets and could be assigned
one or more maneuvers.
Another thing that could be problematic with maneuver generation:
- Complex junctions ( junctions consisting of several OSM nodes )
- Streets that are not allowed in the current OSM profile should
still influence maneuver instructions?
Regarding the routing_ files:
Those files are meant to be internal to the routing plugin, i.e.,
they can be completely different for every plugin. So it might be a
bad idea to use them from outside of the routing plugin.
Best regards,
Christian