Since it looks like I'll be getting an empeg, be it from ebay or SB, let the fun begin. I know smu tried to get a nav project off the ground a bit ago, I don't know how that is coming along. Maybe we can make it a joint effort, and maybe kim could give us a hand seeing as his project it so far ahead. Anyway I'm going to start rambling off my thoughts. Firstly... the maps. I know nothing of map formats, but will look at other projects for linux that use them to figure something out. Some more thoughts on maps. I've got a Street Atlas USA CD that has maps on it. Would these be usable? (as long as your own the cd). Are they a standard format? There are a few linux GPS projects that can help get us started. One of particular interest to me is a perl module that provides an interface with various GPS units. The GPS unit I have at the moment is an Delorme Earthmate. The first thing I plan on attacking is getting the epmeg/GPS to talk. Probably just display the coordinates and any other info the GPS unit sends. I guess thats it for now... I'm headed to bed (I'll probly think of something more to say while im laying here). But until then... happy empeging.

-Dan

Hi Dan.

Getting the player to read the GPS is far from being the main task. (BTW: The Street Atlas CD should be usable once we get a converter written, the specs are available)
The main problems currently are:

1. installation of 3rd party apps on the player


2. a graphical API that works on the player (and is still portable enough to be ported to other Linux systems, from notebook to PDA)


3. an open map storage format that contains enough preprocessed data to make the actual route calculation use less CPU and RAM (both tight resources on the empeg, even tighter on PDAs)


4. the core route calculation algorithm (take a start point, take an end point, calculate shortest/fastest/preferred route).
   
5. the route tracking algorithm (take a route, and start a new route calculation if the driver leaves it, while he is on track: Give instructions to follow it)
   

I am currently working on 1 and 2 with the focus on 1, need help with 2,3,...

Getting real map data to play with is a task that we can tackle when the route calculation algo(s) is/are tested with constructed test sets of data.
If we want to get tricky, we could later implement TMS (traffic messages) into the route tracking and/or calculation, at least for those countries that support it.

cu,
sven

I probably shouldn't complain since I have not done anything to help this project :-) but I don't really see much reason to waste time on 1 and 2 at this point. An easy way to install the software is not an issue until the software exists. If it has to be zmodem'd over your early adopters will be able to figure it out. As far as 2, doesn't hijack provide a nice way to do overlays on the screen that would be ideal for a project like this? No reason to reinvent the wheel just to make it portable if there is already a perfectly good wheel on the platform you are most concerned with. If someone else really wants it to work on a PDA let them contribute the code to do it!

I still wish someone would write something simple that talked to a GPS and used basic screen overlays to display direction, speed, etc. At least that way there is a proof of concept, everything else can be built on top of that.

Just some idle thoughts...
-Mike

I think initially the only types of graphics you'll need are some basic arrows, and some text. You can record some mp3's that say "Turn Right at next street" "Turn Left" ..that sort of thing. Then you can macro some things to the player to bookmark its current position, play the appropriate mp3, then return to the preset bookmark.

Calvin

I don't know if anyone noticed, but with a lot of help, I got the GD graphics library working on the Empeg, at least well enough to get my Trivia game running. Basic font support, circles, rectangles, lines, etc...

Hey, I noticed you list algorithm used as a problem. I know this is kinda hackneyed, and a code cliche that everyone throws at this sort of problem, but what's wrong with Dijkstra's algorithm?

It may be cliched to death, but it *is* fairly flexible, allowing you to factor in "weightings" for the decision making process and stuff....

...you could possibly implement a linked list of function pointers or something as the "decision factor", so you can dynamically alter how it weighs the best route and stuff.

Just a thought. You have probably already thought about it and discarded it for some reason, but hey, there's my 2 cents from having no idea whatsoever where you are with the project and stuff...

And dont laugh at me, it was just a thought ;)

Hi.

Easier install doesn't only benefit the nav project, but many others as well, most notably: displayserver (at least as soon as Frank gets to adjusting it to beta7 and hijack). Also, it does make testing a bit more convenient.
As for the graphics (or general UI) API: hijack only provides a nice way to overlay the content of a buffer with the current player display, but no convenient way to fill that buffer or to generate and handle the menu structure of an application.
I intended to create (and started working on) an API that handles the menu structure, allows easy image display and basic drawing instructions like lines, circles, arcs and stuff like that.
Regarding PDA support: I do not intend to directly support it, but I want the API to be abstract enough to allow easy porting.

If you want basic GPS data display, just start and write such an app. Noone is gonna stop you (to the contrary, many will support you).

cu,
sven

Hi.

Yes, I noticed, but I didn't see any sources for that (the patched GD sources I mean). I would really like to see them, and probably use them as a starting point for a more optimized API ( I remember you had problems with the speed of GD).
Your problems with it were mainly caused by writing/drawing to one buffer (GD format), then converting to an empeg raw buffer and finally merging (overlaying) it with (/to) the player's display. If I could get GD to use the empeg's raw buffer format internally, it should get a bit faster (both by elliminating the conversion step and because drawing to the empeg raw buffer should be easier/faster than writing to a multi-color GD buffer).

cu,
sven

Any reason why you shouldn't use the Java KVM for Linux and the AWT with small footprint class set (a la JMC Edition) for points 1 and 2?

Hi.

Dijkstra is a really nice algorithm if you are looking for a perfect solution (as far as I remember, I would have to look up the specifics), but even though it is one of the fastest algorithms for that task, it is still quite a slower than the estimation algos that are typically used by nav systems. But the "problem" about the algo isn't that much in finding the right one but in implementing it for the empeg (with tight memory and tight CPU power).

As for the progress of the nav project: Due to some events that were not under my control, I didn't get on nearly as fast as I wanted, so basically, I am still in the research phase (but at the end of that). I am currently sorting through all the information I got and will proceed with the first two tasks mentioned above (actually, I already started, but there is nothing presentable yet).

So if anyone wants to help out, he (or she) should just choose a task and email me, so that I can keep track of who is doing what (and put those into contact with each other that are trying to help on the same task). I would be really glad for any help.

cu,
sven

Hi Rob.

How would the Java KVM and AWT help in task 1? They might help with task 2, but I don't think they really would help much, because even with a small footprint clas set, Java still uses a lot of memory for itself that should better be available to the application IMHO.

Like I said in a previous post, the GD library should be ok for the graphics stuff (at least after being optimized for the empeg).

The easy installation will probably incorporate the use of an ftp daemon on the empeg (be it a kernel ftpd like Mark Lord proposed, or a user space ftp daemon which I would prefer) and a custom init on the spare partition, installed using the original upgrade process. I will hopefully get a first working version of that ready by the end of this week(end).

cu,
sven

Hey Sven,

I just dropped you an email with what I have for the graphics library. Hopefully you can carry the torch! An Empeg-optimized graphics API would be a huge step.

I agree with what you said. Half of the code in my Trivia game is setting "colors" for the image objects and converting the image into an Empeg buffer... Probably very inefficient.

If anyone else is interested in the GD source let me know and I can try to host it somewhere. I don't want to attach it here because it's about 700k or so.

I don't know if Kim Salo reads the BBS much now, but it would be interesting to find out what algorithm he uses. His empeg nav software does routing (including one-ways etc) and I seem to recall it already does real time rerouting if you take a wrong turn.

I could be wrong though. I do have a copy of the software but I don't have a UK map for it. If we can find a suitable Netherlands map it would be a cool thing to demo at the next owner meet in Amersfoort.

Rob

If you want basic GPS data display, just start and write such an app.

I have actually started to do that more than once, but having to teach myself C first tends to get in the way. Maybe someday when I am feeling overly motivated (not often).

-Mike

In reply to:

---

I do have a copy of the software but I don't have a UK map for it.

---

Could you send me a copy of that software just so I can take a look at it? I find this really interesting. Its one of the main things I added on to my car mp3 player when I made on from scratch a few years ago.

-Greg

I don't know if Kim Salo reads the BBS much now, but it would be interesting to find out what algorithm he uses. His empeg nav software does routing (including one-ways etc) and I seem to recall it already does real time rerouting if you take a wrong turn.

I'm using A*, which is one of the most commonly used algorithms for path finding. The accuracy and complexity of the algorithm can be controlled with the heuristic function.

However, the biggest design step is to make it memory friendly. In my implementation, I have five different buffers for the path finding which I can freely scale up or down, depending how much memory I want to spend vs. how fast it will be. In other words, what doesn't fit into memory will be swapped to the disk, but in a smart and efficient way.

Kim

Could you send me a copy of that software just so I can take a look at it?

I'm afraid he may not be allowed to do that

Honestly, you couldn't even do anything with the software unless you would have a map in the right format and the right type of map projection in place.

Kim

Hi.

If anyone else is interested in the GD source let me know and I can try to host it somewhere. I don't want to attach it here because it's about 700k or so.

I just uploaded it to http://www.incase.de/files/empeg/programming/gd-2.0.1-empeg.tar.gz. It is not linked from my homepage though.

cu,
sven.

Any reason why you shouldn't use the Java KVM for Linux and the AWT with small footprint class set (a la JMC Edition)

Do you have links to this stuff? Sun's j2me appears to be linux/x86 and Solaris/Sparc only. A quick google search just turns up a lot of press releases about future Sun/Arm projects and related hype. Is there a linux/arm j2me somewhere that I am missing? Do you actually have this stuff running on your empeg?

-Mike

Actually, what's the problem with starting with something simple? At least to get moral and support up and flowing. Vaporware rarely brings out the masses in interest.

I envision the basics, as mentioned, speed, direction, coordinates. I also envision a very rudimentary single waypoint routing ... enter your coordinates for your target and the empeg will point you in the right direction (complete with little arrow), miles (kilometers) to target, time of arrival given current speed.

Most of this is in GPSd right?

Greg

I agree with Greg. Once something simple like that is layed down and working more features can be implemented. It would be great (as a start) to have the empeg tell speed, direction, and coordinates.

-Greg

That was exactly my thought. I was planning on playing around with gpsd once I get my 30 gig unit. (I got a 10 gig in hand off ebay just in case, don't want to goof around with that until i decide not to sell it)

Dan

I also had a question that I forget to add to that, which was my main reson for posting. I had a Rand McNally GPS but I havn't seen it around. I was just woundering what a good gps would be to play around with on my empeg. (I am in the US)

-Greg

Kim, any thoughts yet about where you may choose to take your project?

It's a shame to see all these guys duplicating what you've already done.

Rob

Kim, any thoughts yet about where you may choose to take your project?

I've been waiting to find someone who could provide map data and preferably the knowledge of the source data format, in order to test the software in other environments. It seems that reverse engineering the data format of existing navigation CD's is the only possible way to go, since there is no information available without huge $$$ or strict agreements. SDAL didn't seem to help the situation at all.

Heck, even the data that I use is for private test use and only covers about 80 square kilometer area. The official navigation CD for Finland is supposed to come out only late this year or in 2003.

So, shortly, the maps and the knowledge of the map format is the biggest showstopper at the moment.

Kim

So, shortly, the maps and the knowledge of the map format is the biggest showstopper at the moment.

Kim, I know this was brought up before and at the time it did not sound like you and smu where heading in the same direction with your respective projects. But, now that the empeg has been EOL'd would you reconsider releasing the work you have done so far for the rest of us to use? It really sounds like you have done 90% of the work already and have a pretty cool system working. If the biggest piece you are missing is the map data maybe somebody else can help with that. I know a lot of people here would be greatful for your help.

-Mike

Kim, I know this was brought up before and at the time it did not sound like you and smu where heading in the same direction with your respective projects. But, now that the empeg has been EOL'd would you reconsider releasing the work you have done so far for the rest of us to use?

As pointed out before, at this stage, it's more useful to find someone who could help with the map data and test the program in other environment to find out how it would work. Then it would already be one step closer to build a package that other people could try out.

Believe me, it's more than 500kb of source code, kernel modifications, custom partitions and other changes here and there, and it still needs work to have it in condition where other people could use or benefit from it -- and the maps are the first thing.

Releasing the code is an option too, but that would require a lot of preparation and time to make it suitable for that. And as far as there are no maps or format knowledge available, the source is not going to help getting it running. Surely, you could rip some code and hack a simple GPS coordinate viewer, but what's stopping doing it already? I've posted the kernel modifications for adding a screen and audio overlay with the player application, and for anyone who has intermediate programming skills, it does not take too long to write a simple app to read NMEA ascii strings from GPS receiver (thru serial port) and display those on the screen.

Kim

Hmm... Well It would make sence to me for everyone to work together to get something setup since it seams like there is a bunch of seperate projects all over the place. I dont have much of a clue on programming anymore as its been a long while since i've done in (im waiting for some of it to come back to me), but I surely am willing to test anything anyone has. I still havn't found my GPS so im probobly going to be buying a new one, just have to figure out what one.. any suggestions?

-Greg

Intresting you are looking at GPS nav stuff i am looking forward to the next OEM to pop out

This has probably been said somewhere else, but for us US users, the US Census Department puts out all the data you could ever want. You can download their database of addresses, streets, landmarks (i.e. airports, stadiums, etc.), and all that jazz. They also give you a nice little 309 page manual for how all the information is presented, etc.

You can check it all out at:

ftp://ftp.census.gov/pub/geo/www/tiger/tiger2k/

Just keep in mind that ALL the maps for the US are over 2 gigs.... you may want to play with this on a city by city basis...