Hi.

As many of you know, I have been trying to start this project for quite some time now. I hoped to cooperate with Kim Salo, because he already has large parts of a navigation system going, but he is either too busy with other projects or is simply not wanting to let others in on his project. At least I was unable to get any information from him for quite some time now, and I couldn't find a web page with information on his current project state either. Seems like we have to re-invent the wheel on this.

Anyhow, I just collected a few tasks that need to be completed to get a navigation system running (well) on the empeg. I listed them below, some are very detailed, some less detailed, some are huge tasks that probably need more than one person to fulfil them, some are minor tasks that might get done within a few days. Here is the list:

1. Software installer for the empeg, to make software installation easy for end users. This should be relatively easy to do using the info at the tweaking/programming pages at http://www.incase.de/framed/empeg/


2. Sound-API/Display-API/UI-API this might be a bit more time consuming, but should be farely easy to do, just needs some write-up. This will be needed to draw a neat line between the interfacing parts of the program and the actual logic in it


3. serial access to GPS (and other sensors, see below), ideally, this is goint to be neatly encapsulated, too. I really want the core of the system to be as independ of the hardware and operating system as possible. This will make porting to other architectures easier and might even attract people from outside the empeg scene.


4. MAPS we need maps for the various areas we are going to cover. For europe, I would recommend the maps provided by AND (http://www.and.com/), but they are expensive as far as I know. I would really appreciate help in this area. I currently don't have the time to do intense internet research for map data (and even more important: The data format specs for that maps). So if anyone would contact the various providers of map data and find out their conditions, this would be great.


5. A small serially connected device would be great that allowed the parallel use of a GPS and some other sensors (like compass, speedometer etc.). Most commercially available systems only use GPS for their initialization and use compass and speedometer sensors mainly to keep track of the current position, because GPS is not always available within a city.


6. A program framework that links the user interface with the real functions of the system.


7. A converter that converts the various map data formats to one format that we will use internally (well, the internal data format also needs to be specified here)


8. Many, many, many functions that build the real core of the system, like the position estimator (that reads the GPS, compass and speedometer information as well as the map data and estimates the current position, direction and speed), the advisor (that tells the driver where to go next) and the innermost function: The routing functions that calculate the route the driver should go.


9. Even more functions that are linked to the UI, like setting up the type of car, the drivers preferences (likes to use freeways or "normal" streets, likes to drive relatively slow or fast) etc....

In other words: There is a whole lot to do, and I really would like to get this going. This project will probably involve many different activities, contacts to the industry (map data, GPS receivers,...), hardware design (interface for speedometer+GPS,...) and last but certainly not least the software development itself. If we want this to grow to a usable system fast (within a year or two), I would say that we need at least 5 or 6 active people (putting in a lot more than just a few hours of work each month): One to acquire the information needed (map data and associated data formats, licensing information for the map data etc.), one for the hardware job (GPS+sensor interface) and 3 or 4 people that actively develop the software. note that this software development should be general enough to be of use to other projects (even non-empeg ones), too. The innermost core, the navigation/routing itself could best be handled by one or two developers, I guess.

Ok, anyone that would like to help with personal effort, please contact me via email (sven-navem@incase.de), stating your skills and your estimate on how much time you would be willing to invest on this project. Anyone that can not help in person, but still wants to help, here are a few things that would help me getting the project started a little bit faster than I would expect it to start currently:

• a notebook harddisc for my empeg, anything with at least 4gb would help. My empeg is simply full to its limit currently, and I don't have much money at the moment, so I can't buy one


• a GPS receiver that has a serial port and is capable of talking NMEA


• a serial cable (to connect it to the empeg) and power supply for the GPS receiver


• Oreos


• A bottle of really good whiskey

I anyone from Europe would be interested in helping on the software side, I would like to arrange a meeting on some weekend in late october / early november, to discuss the primary program layout and such things. I can provide sleeping space for up to four people (two for each room).

Geee, I just realized that I didn't work on the project for almost a year now, due to my studies, work and personal things. I really need somebody else involved with this project to gently kick my lazy ass from time to time ;-)

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

As there has been discussion about my navigation project also in other threads, I thought that it is most informative to gather a small Q&A list to get most of the questions answered.

Q: Is the navigation project still going?
A: Yes, it's still alive. It has been more or less work-in-progress since March 2000 when I had the first empeg vs. GPS communication running on my Mk1.

However, for the past half a year, not much has happened since I've been extremely busy with my primary work. Fortunately, things are getting balanced and I hope to spend more time with the navigation soon.


Q: Could you enlighten us on the current state of navigation software?
A: Essentially it's able to project the car's position to the vector map and show the current street name along with street numbers in realtime.

It has a preliminary route planning and guidance feature which lets you to type the destination street name either by using the remote or the rotary knob which after it calculates the shortest/fastest route and starts the guidance. The route planning takes turning restrictions and one-way streets into account.

It does not utilize any PDA device thru IrDA anymore as it turned up to be not so practical solution for in-car use. Instead, all feedback to the driver is given with speech prompts.

Big part of the design was to smoothly integrate the navigation with the existing player software. All speech prompts are mixed with the regular player audio output and therefore the music is faded down to 50% of its normal volume while the navigation speaks the guidance and other information on top.

The display shows the current street name, information about the route such as estimated arrival time/distance left to the destination. It can also show extended GPS information such as speed, number of visible satellites, etc. The navigation software is controlled with the front panel buttons and remote with certain keys fixed to change the focus between the player and navigation software to allow better control. While the navigation software has focus, it has internal menus where various things can be controlled -- meanwhile the player continues to play music on background and remains unaccessible until focus is switched back.

As noticed, there's no web site for the project as I don't see it too useful to hype something that is not publicly available yet (excluding the reference on geek site).


Q: Will it ever be available to general public?
A: That mostly depends if the project gets into a state where it's useful for other people. To make it work with other environments, it will require things like proper installation system (as it requires kernel modifications, relies on having a custom scratch mount point, etc).

The biggest obstacle however being the maps and the interface between the program and various map formats (and each geographical area needing a specific map projection code). Once the map interface works better and has support for other map types, it will be much closer to a state where other people could potentially use it.


Q: Do you need help?
A: At the moment, I don't feel comfortable to turn the project into a massive team effort as I know that it will easily get out of hands without a proper coordination especially since the programming work is not the key fact slowing down the development. It would be different case if I would be starting the project now, but since it's been going on for the past 1,5 years there's a lot of ideas regarding the design/implementation and experiments that I've made which affect to the overall direction I see it going.

However, if at some point I feel like dropping the project, I don't see it as a problem to contribute the existing work to the community. On the other hand, once it's actually possible to use the software in other environment, I'm sure there are many aspects where testing in different countries and geographical areas would help.


Q: Will the source be available?
A: There's no definite yes or no. However, I see it more likely to have a binary version available sooner than the source. Future will indicate where the project goes and which option seems better.


Q: What map types are possible to integrate with it?
A: It's solely based on vector maps which represent the street network using some known map projection formula. However, to get it work with multiple data sets, it seems pretty essential to have the source data always in same format.

For now, it looks like the TeleAtlas maps will be the ones that I'll investigate further. Partially, because it is the only company producing street-level vector maps for Finland. They also have pretty good coverage on Europe and US.

Kim

Hi Kim.

This might be an exaggeration, but if I wanted to summarize your post into 3-4 sentences, I would do it like this:

1. The software seems to be pretty well usable for you and seems to have quite a few features I would like to see on such a navigation software.


2. The maps you currently use are available for Finland only, other maps use different projection methods and are therefore not compatible at the moment.


3. If some other people want to do a navigation software project, it is either in parallel with your project, or not happening at all (for now).


4. If your software ever reaches a state where you don't want to improve on it anymore, you will probably release it as open source.

Is this right? If so, it doesn't make me happy, but it is your software project, so it is your decision. In this case, I see no other option for me other than starting a seperate project for some other navigation software. However, I will probably investigate on the lower level sub-projects first (UI-API, Sound-API, Player/Navigator skeletton, Plugin-API,...). This might help your project as well, if you get it to a releasable version within the time we need to finish the basics. It would be great though, if you would help us with some information like the data format of the maps you use, NMEA communication routines etc.

cu,
sven

PS: Nice to read some news about your project anyway, I always wondered how you got along with it. I would really like to give it a try, too. If your software is even half as good as it sounds by now, it is better than what I had in mind as a primary public alpha version.

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

You're determined to make me regret getting a separate nav unit aren't you

Rob

This might be an exaggeration, but if I wanted to summarize your post into 3-4 sentences, I would do it like this...

Roughly, your summary was about right.

It would be great though, if you would help us with some information like the data format of the maps you use, NMEA communication routines etc.

Sure. If you get a project moving (will it be whatever), I'm happy to help if you are having problems with something that I've gone through or would have a clue otherwise. It would be nice to see more 3rd party projects and applications going on with empeg as so far they have been pretty limited to DisplayServer and Tony's logo editor plus some smaller helper tools.

Still, what goes for the map formats, the one that I currently use is based on raw MapInfo mid/mif files which are relatively easy ascii files to interpret. However, most of the other formats used by NavTech, TeleAtlas and other car manufacturers (Mercedes, VW, etc) are using their own proprietary binary format, for which they are not likely to release any specs.

I'm aware of the SDAL project which is supposed to fix the situation but as it's owned by NavTech, it automatically means that TeleAtlas (which is their direct competitor) is very likely not going to support nor use it. That kind of breaks the idea of having a one common file format for the maps. Perhaps, it should have been designed by an organization who has nothing to do with the existing companies working on the field to ensure that everybody is on the same line.

However, if somebody happens to have more information or specs on various vector map formats, feel free to let me know.

Kim

Hi Sven,

I would not be able to offer any help with the programming but I do have a VDO Dayton MS5000 nav system and an empeg. I also have all of the map CDs for Europe so as I only can use 1 at a time I can send the one I am least likely to use to you.

I would also be able to test the 2 systems side by side for comparison.

The VDO maps (I am not sure who provides the content) are available for Europe and the US so this would seem like a good place to start. They seem accurate and have street numbers etc. They are available from most GPS sales sites for around UKP80 each.

MK2 Red S/n 949

As far as the specs for SDAL go, unless I am mistaken I have their documentation for that. Mind you from the noises I hear NavTech is pretty much closing up shop in a couple of places. Holland for one seems to be going away. At any rate as I have stated before, and this is to both Sven and Kim, I have a couple of GPS receivers (a Garmin OEM module which is NMEA, and a Delorme Earthmate which uses a binary output format that is Delorme specific) and would be more then happy to help test or whatever. I would also be perfectly willing to donate (if that is the term) some resources to Sven and/or Kim (I think I can probably dig up 1 or 2 laptop drives for testing purposes, mind you mostly 2 gigs perhaps a 4 or a 6 gig if I get REALLY lucky).

Cheers,
Hans


Mk2 - Blue & Red - 080000431

I have found hazardly during search for Linux programs.

It has interesting features :

GpsDrive

Empeg II - 10 Gb - Red Fascia - 750 Songs -

- I Will Strike From the Grey -

But Rob, just think, I am so glad you did........ :)

-Steve

//== MK2 20 GB Single Drive, Green Face Plate Currently installed in Toyota Solara ==\\

This looks very promising. If I had enough programming savvy, I would probably start working off this since it looks pretty mature. Even as a GPS solution for my laptop this looks good.

EDIT: Maybe if a bunch of us got together and bought this guy an empeg he would work on the port. I'm in for $100.

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

Edited by robricc on 11/10/01 09:27 PM.

Hi.

Yes, that project sure looks promissing, but there are a few things I noted while studying the readme file. First, it currently only is a moving map display, though a very intelligent one. Great if you want to try and find your way in an unknown environment, bad if you want to get guided through an unknown environment. Second, it doesn't use street based maps/vector maps which makes it almost impossible to do real street to street navigation, there simply is no information about streets/street names in those maps.
That system is surely interesting and far more advanced than my software will be by the end of the year. It seems to be a dead end in regards to a street level navigation system / guidance system though. Don't get me wrong: This is an extremely good piece of software as it seems, just not the kind of navigation system I would like to use in the car. I would use it on a mobile computer though if I were walking through an unknown city, just like I used the great software StreetPlanner from Palmtop BV (Netherlands) on my Psion Series 5mxPro some month ago.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Good points. It keeps looking like the main snag is the maps.

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

While on the topic of vector maps, I recalled some software I saw a while back. This is for the palm. The maps are seperate files that claim to be vector drawn with street data and such. You can view the available maps without a password. There are many different countries. May be able to find out where this guy is getting the map data.

Quo Vadis

Just trying to help,

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

As someone else mentioned it sounds like good vector map data is the biggest thing lacking at this point. Do you think it would be worth starting off with regular maps to get something going until a vector map data source can be found? If someone can get a simple moving map display working it could draw a lot more attention/help to the project.

-Mike

maps are seperate files that claim to be vector drawn with street data

Did you read the legal stuff? The maps may be used on one computer (not a problem) inside your own building (at least that's what the jargon says for the European maps. Not good for a GPS system, is it ? But it'll keep the lawyers happy!

Henno
mk2 6 nr 6

What if you live in your car?

-Zeke

just say you weren't paying much attention...

There was an interesting article about Nav system maps in this months automobile club magazine here in Germany. They were mainly complaining that there are no standards for map data for navigation systems! There seem to be 2 main map providers - Tele Atlas (Belguim) and Navtech (USA) - but in spite of this you often can't share the map CDs with your friends as almost every Nav system manufacturer customises the information on the CD. However, If you are lucky enough to be using a Tele Atlas system from Siemens-VDO or Blaupunkt you *should* be able to swap CDs with your friends. There also seem to be a lot of vehicle manufacturers using one of these systems (15 listed in the magazine). There are also 5 more manufacturers delivering vehicles with a Navtech CDs and a Siemens-VDO Nav system that can also use the Tele Atlas CDs if you want. My suggestion: maybe we should look at something like the Tele Atlas map system as the CDs are likely to be more readily available. There are other aftermarket companies producing map CDs for these systems, and they are of course mainly producing CDs for the most used systems. This makes CDs for these systems likely to be a bit cheaper too. Well one can only hope!! What does everyone think?

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 26GB blue)

Will it be possible to use a 'Proprietary Format' for Empeg :

With the Nav system on Empeg we could imagine a utility to convert maps to Empeg format and anyone could use aby map :

You put your Map CD in your PC , use the converter and then upload it to EMpeg .

Is it really possible or requires too much work ?

Empeg II - 10 Gb - Red Fascia - 750 Songs -

- I Will Strike From the Grey -

Will it be possible to use a 'Proprietary Format' for Empeg :

With the Nav system on Empeg we could imagine a utility to convert maps to Empeg format and anyone could use aby map :

You put your Map CD in your PC , use the converter and then upload it to EMpeg .

Is it really possible or requires too much work ?

That is actually the only possible way to go around the problem Derek was addressing with the incompatibility issue between different map vendors. A proprietary format is also necessary to get the data structures optimized in a way which fits best for the program.

The biggest bulk of work is to write 15 different converters to convert the data to the proprietary format. And you are pretty much forced to reverse engineer the data format used in the CDs as it will be very difficult to get any format specs. It's not likely that you can obtain format specs from TeleAtlas or NavTech for instance. I believe they are anything but open-source -- you might be able to get the specs by negotiating and signing pile of NDAs, though.

Then again, from the map vendor's perspective, they don't see this kind of project that interesting (commercially) as the amount of players (and potential customers for this kind of project) is relatively small, especially with the EOL announcement.

Kim

Anyone in Belgium want to have a go at talking to Tele Atlas anyway? Maybe if we could convince a couple of them to buy empegs ....

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 26GB blue)

Hi.

If anyone could get the specs to the Tele Atlas maps, that would be exceptionally helpful. I am aware that they might want to charge quite some money for that and/or require to sign a NDA. I just hope they don't.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Hi.

Do you think it would be worth starting off with regular maps to get something going until a vector map data source can be found? If someone can get a simple moving map display working it could draw a lot more attention/help to the project.

In principle, this is a good idea. However a moving map display isn't really of much use on the empeg I guess. Remember that it only has a 128*32 pixel display.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

ROFL

___________
Tony Fabris

Anyone know if the maps at mapopolis.com are vector? The ones with street data are dirt cheap, and the ones without are just free.

RioCar (40Gig) Blue/Red/Green
'01 Audi A4 2.8 Quattro

However a moving map display isn't really of much use on the empeg I guess. Remember that it only has a 128*32 pixel display.

Excellent point. I just would love to see something actually get started. I have always thought some sort of nav system would be a great app for the empeg.

-Mike

This software seems it might be helpful. I try to download it, but I get rejected. The GPS communication portion is open source. Mayko map.

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

This looks good and free for US maps. No, I'm not just trying to up my post count.

Tiger 2000 Data

-Rob R
--------
12GB MK2 Blue 090000736 (6166 in the queue)
10GB "Backup" MK2a Blue 030102953

Kim, sorry to bring up an old post, but what are you using for your voice prompts? Are you just using pre-recorded PCM sound files, or are you using a text-to-speech engine? If so, which one? I am investigating text-to-speech products myself for my Trivia game and as a general purpose way to get the Empeg to speak (reading textual news/weather reports, etc.)

Kim uses PCM, which I believe has been generated offline by a rather nice TTS.

If you want to run TTS on the player, you might consider Flite (http://www.speech.cs.cmu.edu/flite/) which is rather more managable than Festival. The quality isn't bad for a free system - but not a patch on the commercial ones. It has been observed to run successfully on an ARM Linux platform not so dissimilar to the car player.

Rob

Yah, I have actually been in conversation with the Flite author recently. I compiled Flite last night and it does a good job of creating WAV files of the spoken text, but I can't get it to output sound because of the 4608 byte restriction on /dev/audio. Flite writes 256 bytes at a time. I'm going to try to hack around it, the author wasn't able to give me any help on that front, unfortunately.

I was just asking if Kim was using Flite or something else. If he had gotten Flite to output to /dev/audio, he would have solved one of my current problems and I would have begged to see what he did. :)

Interestingly enough the Flite package is being rolled into a commercial product. The author says that Flite will be back-filled with the innovations from the commercial product, but the voices won't be as good on Flite to encourage people to buy it. Whenever I hear this, I translate that into "the freeware/open-source product is now dead, forget about it." I am sure the Empeg will be an exception to that rule. :) But he says that Flite will get better voices and better part-of-speech recognition soon. Until that happens, I guess PCM is the way to go.