In a bit of genius or craziness, I decided to combine two open source programs- our well loved GPSApp with a little program called Roadmap. Roadmap is a cool little program that uses TIGER map data (built into a special format) for displaying maps. After a bit of struggling and applying chewing gum I made them work together. Download it here! See the Installing.empeg file on how to install and download maps etc..
Please note this little hack is in v0.01 and I'm not even sure of it's usefulness yet. It does show maps of roads and such when you drive by however. Comments are appreciated, bugs are expected. (Screenshot attached)

That is so cool. (even though I haven't looked at the actual app yet.)

I was trying to go into that direction myself, but haven't had enough hacking cycles to spend on it.

Me scurries off to ebay to look for a cheap gps reciever.

Anybody know of a good deal on one that will work with the empeg. Preferably one that requires no modification, or at least very little. I'm seeing some Delorme Earth/Tripmates that are pretty cheap, are they any good? Anybody know of anything cheaper?

This is the one i'm going to get, and i think its like $50 new.

Edit, DoH! More like $150+

Hey, you're supposed to be working on a cleaner way to get route directions out of StreetAtlas. Get back to work, you slacker!

(Just kidding of course. This looks like fun!)

(Well, only sort of kidding. I still want easy yet hyper-accurate route directions for GPSapp.)

Ya I know.. but working with open source programs is infinetly more fun than trying to get a closed source program to do what you want.
Besides- I posted onthe street atlas yahoo group and actually got a response from one of SA2003 developers who said he would try to get an export route to file feature implemented in the next version. So time will tell..

Besides- I posted onthe street atlas yahoo group and actually got a response from one of SA2003 developers who said he would try to get an export route to file feature implemented in the next version.

*Boggle*

Oh no, he's boggled again.

Someone call the de-boggler.

Sweetness. It is a shame that roadmap doesn't do street names and addresses though. Actually this screenshot implies that it does know your current location which is all I would really want anyway. Oh, did you mean that it doesn't label all the streets? That would be awfully cluttered on the empeg anyway, but a single line of text telling you your current location would be useful (to me at least).

-Mike

Question on setting up all of those good stuff. I've never setup gps on my empeg before. I downloaded your release, setup everything exactly how your instructions. Hooked up my maybe working gps box, and got nothing. Went through all the setting for GPSapp, and found protocol=earthmate which is what i have. I made the custom cable, swapping pins 2/3 and straight with #5.

But i guess my main question is, do i need to setup mini_ifconfig and gpsd? i noticed in the GPSapp readme, it says very little at the bottom about those. So are the needed?

I wonder if I should post libpopt.a cross-compiled for people. Some of the build for this is a bit weird, but I have a built binary now. No clue yet if it will work, we'll try that shortly.

Oliver, you should probably get the generic GPSapp working before trying this alternate version.

When you say you "get nothing" can you be more specific? What keys are you pressing and what is appearing on the screen?

If it says "waiting for data from GPS receiver", try swapping the TX/RX pins. Also make sure the receiver works of course by plugging it into your PC and seeing if it works with the PC GPS software.

Ya building is a pain...I don't know much about Makefiles I'll learn more and make it easier next release. I forgot that libopt was required too...

It caught me off-guard that "cc" and not "arm-empeg-linux-cc" was being used to compile one library, and so linking gave a segfault. Other than that it was pretty obvious what was going on. I have a binary I just built and a set of maps for PA on the empeg now. I figure I'll shower and go for a ride.

Get a lawnmower that cuts the grass by itself, and suddenly you spend lots of time going other lawn work. Bah. I think I got a mild sunburn.

yea, i think the earthmate is dead. I friend let me use it, a battery leaked acid onto the board before he gave it to me, and i can't even get it to work on pc but i don't really have any software, just some freeware Eartha2NMEA.exe. what i really need to get my hands on is a voltage meter, found a nice website that details a few things to test to make sure the unit works. I think i should just go find a NMEA gps receiver first.

You can open the Earthmate and apply voltage directly to the input pins, FWIW, but yes, I recommend playing with an NMEA model first.

Reading the installation instructions... Is there any way that future versions could a) not need the extra schema files and such, so that installation could be simpler, and b) not need the extraction step, and instead read the contents directly from within each of zipped map files?

b) not need the extraction step, and instead read the contents directly from within each of zipped map files?

Because hey, take the least powerful device you have, and make it do as much work as possible.

LMAO

I lied. My Treo is less powerful. I haven't set up IR yet, so I can't beam the stuff off to it to decompress.

Come on, it can't be that CPU-intensive to extract a single file with a pre-known filename out of a zip, especially when it only has to do it once at the moment when the program loads the map.

I suppose this could be done but I think a clever script that extracts the map files automatically would be better. I want to change the roadmap sources as little as possible to allow for easy upgrades when new versions of it come out. I already need to upgrade the sources to v1.rc1, because v0.15 was the latest I found at the time I started (argh).

But you can't just load a 10MB or larger file into the 16MB of memory on the empeg _and_ have the player and kernel and everything else running at the same time.

And I've had comments about the loading time of the tiny and uncompressed GPSapp route files.

And I've had comments about the loading time of the tiny and uncompressed GPSapp route files.

...not so much the loading as the disk spin-up delay occuring earlier than expected...

But your main point is certainly very valid. File size is an issue.

ISTR at some point you were researching geospatial file indexing schemes. Did anything valuable every come from this? I think that the ideal situation would be to be able to crunch all the data once and repackage it in a GPSapp-optimised filesystem tree which could be tar'd and zipped up for distribution.

My analysis of roadmap code is that it does not load whole county files into memory all the time. It uses memory-mapped files and reads what it needs, and the author already has a geospatial indexing scheme- that's what the 'usdir.rdm' file is for. So we already have a pretty decent indexing scheme going. I also don't think file size should be an issue on the empeg. If ths issue is File size vs CPU then CPU should win over file size every time. The one thing the empeg has going for it is it has more storage space than your typical embedded machine.

Hi Guys,
I just got a NMEA gps receiver from a buddy, I have serialport=/dev/ttyS0 under gpsapp, because i want to test this without having to go out to my car. I don't have notify=1, or anything else like that in my config.ini. The COM port setting for my gps device, are 4800-8-n-1 with Hardware flow control. But gpsapp still just sits waiting for data. I've checked the settings on the gps device, and the NMEA output is on. Any Ideas?

Edit: The Unit is hooked up to the back of the empegs com port, with force ac/dc toggled to dc.

Nevermind, all set.

You have to tell us what it was, now.

You have to tell us what it was, now.

Does the sled's serial port support hardware flow control? I wouldn't suppose it does. That would be my guess.... but what the hell do I know?

It was really nothing, my gps device is also my nextel phone. I switched phones with a buddy of mine who had the i88, and i have the i85. Only difference is GPS. The NMEA output is really gay. Sometimes it will just stop outputting. Even though it has around 8 links which are really good. And i have to go into the menu and turn off the output and then back on to get it to work. I usually have to do this once or twice just to get GPSapp to see the device. I never got the unit to work directly connected to the back of the empeg. Only in the car sled com port, which i have a custom serial cable with 2/3 switched and i think 5 for the ground, whatever the FAQ says. Anyways, this gps device isn't a very good one, because sometimes i will have an accuracy of 500ft and be in the middle of someone’s lawn I've been looking at this one, any ideas if it’s any good? Or if there are any better ones out there without a screen? Is WAAS any good? will it work with the empeg? It kinda says it outputs NMEA

Ok, now i've gotten a chance to play with this software a bit, and its pretty nice!

A couple of small things, other people have probably reported before, but I’m not sure.

1. When you hit the top button to hide GPSapp, so you can adjust the player (volume or track) When adjusting the volume, my volume popup hides extremly fast, only while gpsapp is running in the background.

2. Usually after the second time I hide GPSapp, to adjust the mp3 playing, it will freeze. When holding the knob to bring up the hijack menu, it goes straight into the last GPSapp screen, then after a few seconds, back to the player. I have to remove the empeg from the cage, and reboot.

Otherwise, this app looks pretty solid, besides the minor bugs in the map data.

2. Usually after the second time I hide GPSapp, to adjust the mp3 playing, it will freeze. When holding the knob to bring up the hijack menu, it goes straight into the last GPSapp screen, then after a few seconds, back to the player. I have to remove the empeg from the cage, and reboot.

This is a known bug which seems to affect all of the third-party programs that bind to the hijack menu. We have long suspected a bug in Hijack. I'd love to see it solved, regardless of where the bug lies.

I've finally found a few minutes to install this, and...Wow, it really does show great potential. Going forward from here;

1) Jan, are you looking to integrating this into gpsapp more tightly (possible non-US ramifications), or perhaps reworking gpsapp to allow a 'modular' moving map 'plug-in' (allowing other potential data sources to be used if they come along). Or are you intending for roadmapgpsapp to remain a derivative of gpsapp?

2) Assuming for the moment that the zoom scales can be unified, we still have some UI hurdles to jump;
a) gpsapp currently displays a dim route with bright waypoints. The roadmap lines are always bright. This is almost the inverse of what is ideal. Obviously with only 3 shades and black available we are very limited in how to resolve this. Ideally major highways would be brighter than back roads. But how do we then indicate the route over the top? Perhaps a dotted line that inverts itself a few times/second? Perhaps an animated line that color-cycles through the 4 shades...Hmm. picture/thousand words;


b) It would be nice if we could have a larger virtual screen, and then a pan mode. This way we could look around at a higher resolution.
c) It'd be cool to pop up the nearest road name. Chances are that we should be on it.
d) Labelling major highways at an appropriate resolution.
e) De-cluttering some of the big-scale zooms. It appears as if we still get dots where some of the roads were. Ideally if I go to a 5mile+ scale, all I want to see are major roads. (Interstates, turnpikes etc)
f) It'd be nice to shade-fill water. It appears as though it is displaying line data for shorelines already. I'm not sure how feasible this is.
g) Remove transparency from gpsapp popup route directions.

3) It would be cool to implement a road name search. My brief source code excusion suggests that the underlying data should be there in a searchable form. I don't know if it would be possible to implement a fuzzy search similar to the empeg's song search feature, but that would be ideal. I'm guessing that the database would be too large to keep in memory, and the fuzzy search would require looking in multiple parts of the database simultaneously until the search gets narrowed down. But I can dream
...and then highlight/mark the resulting road whenever it appears in our viewport. (and ensure that it appears in large scale zoom modes too)

Lots of other exciting potential...

The NMEA output is really gay.

Unless you happen to be gay, in which case it's really straight.

Is WAAS any good? will it work with the empeg?

WAAS is used by the receiver and no data is output, so it will improve your accuracy with no impact to users of the data.

c) It'd be cool to pop up the nearest road name. Chances are that we should be on it.

Roadmap v1.0rc3 has this ability, along with the ability to display road names, at approaching intersections and even use Flite to text-to-speech them. I'm planning to re-work the "bridge" between GPSApp and Roadmap and integrate version v1.0rc3 of Roadmap sometime reasonably soon. If Jan wants to give me some guidelines for making a "bridge" that would be welcome..

d) Labelling major highways at an appropriate resolution.

Map Labeling would be nice but Roadmap doesn't appear to even do this, maybe the latest version does.. haven't installed it yet.

e) De-cluttering some of the big-scale zooms. It appears as if we still get dots where some of the roads were. Ideally if I go to a 5mile+ scale, all I want to see are major roads.
(Interstates, turnpikes etc)

I think what your seeing mainly here are bodies of water which aren't decluttered by default- you can mess with this in the schema and/or preferences file I believe. Real large scale zoom outs are dangerous anyways because they require so much disk reads that the empeg can easily get cloberred.

f) It'd be nice to shade-fill water. It appears as though it is displaying line data for shorelines already. I'm not sure how feasible this is.

The code for this is probably already in roadmap, I just need to write the function that draws it correctly. I tried to use the function in vfdlib.c that draws polygons filled and it seems like it didn't clip correctly and clobbered the whole screen. Hard for me to test this shoreline stuff though, only body of water I have here is the ole Mississippi..hehe

3) It would be cool to implement a road name search. My brief source code excusion suggests that the underlying data should be there in a searchable form. I don't know if it would be possible to implement a fuzzy search similar to the empeg's song search feature, but that would be ideal.

Roadmap has very nice search functionality.. if you try the actual Roadmap program it works pretty well. No idea how you could put in what address you wanted though on the empeg without the remote or something.

Jan, are you looking to integrating this into gpsapp more tightly

I downloaded it, but haven't had time to try, or even look at how source was integrated. I did look at the roadmap sources to see if it is using a nifty encoding scheme, but it is pretty simple. I'm probably just going to see how it is developing for now.

(2a) The way routes are drawn would have to be changed considerably to get the crawling ants effect. Because it depends on the scale and we can't treat each route segment independently.

(2g) Yeah, transparency never was a problem with the simple route display. But clearing the area underneath the popup is pretty trivial.

It definitely has potential.

If Jan wants to give me some guidelines for making a "bridge" that would be welcome.

Not sure what would be needed. But it is probably best to keep roadmap as unmodified as possible to be able to track new releases. Gpsapp is smaller and I might just grab some or all of your changes at some point.

Real large scale zoom outs are dangerous anyways because they require so much disk reads that the empeg can easily get cloberred.

That's one of my issues with the data format. I had already decided that the data should probably be stored in several 'layers' so that at a larger zoom we don't have to seek past the unused details. i.e. one file with interstates and possibly borders/large bodies of water for the whole of the US. Other highways and possibly mayor roads in per-state files, etc.

No idea how you could put in what address you wanted though on the empeg without the remote or something.

We can intercept remote button codes as well. Grab them after a knob longpress, or some menu selection. I typically use the remote to adjust the volume while gpsapp is running.

Not sure what would be needed. But it is probably best to keep roadmap as unmodified as possible to be able to track new releases. Gpsapp is smaller and I might just grab some or all of your changes at some point.

Sounds fine, not many changes to GPSApp are really needed for this anyways. Although I may have to look into getting the zoom scales to match, not sure what that would involve.

That's one of my issues with the data format. I had already decided that the data should probably be stored in several 'layers' so that at a larger zoom we don't have to seek past the unused details. i.e. one file with interstates and possibly borders/large bodies of water for the whole of the US. Other highways and possibly mayor roads in per-state files, etc.

The author has this in his TODO file as something that needs to be done so hopefully in the near future this will get fixed.

It might be a projection issue. GPSapp is currently using a transverse mercator projection in the WGS84 datum, but the difference with a real UTM projection is that I center around the middle of the rectangle that fits around the route instead of the using the actual UTM zone in which the route falls.

The Tiger data is probably in the NAD27 datum, although they might have switched to WGS84 in the recent versions. There is approximately 200 meter difference between the two. I'm also guessing that roadmap doesn't do a cartographic projection to a rectangular grid (i.e. 1 pixel in either direction == 1 meter), but is using something like 1 pixel == 1 degree (or 100th of a degree), I forgot the name of this projection, but it is commonly used for world maps (which is why many people think that europe and north america are larger than they really are.

Basically you can use a ruler on the gpsapp route display and the distance between two points in any direction is always correct for the scale. When there is no cartographic projection 100 meters north might be 10 pixels, but 100 meters east is only 7 pixels. The difference is even more near the polar regions where the latitudes are getting closer to each other while the longtitude lines always have the same distance.

I'm leaning towards dropping the transverse mercator projection. Typically people won't be able to tell the distortion, and it makes it easier to draw areas that span several UTM zones, like the whole US when we zoom out a lot.

My analysis of the projection function, roadmap_math_compute_scale in roadmap_math.c, suggests Roadmap does a WGS84 projection of some sort. I really haven't dwelved into the math any futher to say if it is doing cartographic projection or not.. although the comments suggests it does- he says the projection tries to compensate for curves around the poles. I'll trace the code more and see what it's doing and let you know if I figure anything else out.

Since I can't find it in the FAQ, and I don't feel like searching the BBS, can someone tell me which pins to hook my GPS up to on the serial port coming off the EMpeg? Namely, I need to know the 12V power source, and the Rx/Tx data lines. Also, does anyone know how much current the 12V line can support?

...I don't feel like searching the BBS

Ignore the wealth of information that already exists and get everyone to re-type it 'cause you're feeling lazy. Nice.

From memory, on the docking sled serial port port connector, the Amp Remote (12V) line is on pin 4, and can handle 3A. TxD and RxD are on pins 2 and 3. They are the opposite of whatever the empeg itself is, but can't remember which way around. If your GPS is TTL level (ie GPS module from somewhere like bgmicro) then you'll need to convert the voltages, but if you bought an off-the-shelf unit then you probably wont need to. Check the specs.

Of course, none of this information is guarranteed to be 100% correct. It is from memory. But it is all available for free on this BBS.

Non-obvious but useful search terms include Oncore, Trimble, SVee6, streetfinder.

Ok, so I decided to give this a go and am having trouble getting it to work. I followed the instructions and am pretty certain I didn't leave any part out. But roadmap is not showing up in the hijack menu. Here is the end of my boot log

hijack_exec("/drive0/var/gpsapp/gpsapp"), rc=0 (okay)
GPS app started
hijack_exec("/drive0/var/roadmap/roadmapgpsapp"), rc=0 (okay)
** roadmap_file.c, line 315: cannot open file usdir.rdm
** roadmap_dbread.c, line 377: cannot open database file usdir.rdm
## roadmap_locator.c, line 132: cannot open directory database (usdir)
player.cpp : 385:empeg-car 2.00 2003/04/01.
Prolux 4 empeg car - 2.1434 Mar 26 2003
Vcb: 0x4086d000

There are 3 lines there that say the usdir file can't be opened. I put that file on the empeg in the correct place and extracted it and everything. So why cant it open that file?

I can only think of 3 reasons for it not being able to open the file:

* looks in the wrong place (ie file put in the wrong place - which you say isn't the case)
* wrong permissions on the file (try chmod 777 usdir.rdm)
* corrupt file (but one would hope for a better error message in that case), maybe because uploading from Windows->Unix with a client that autotranslated linefeeds? (try re-uploading in binary mode) Or corrupted for some other reason.

/Michael

Another possibility... case sensitivity in a file or directory name?

I'd say it's permissions or ascii corruption more likely, too.

By the way, you said you "extracted them and everything"... If you used WinZip on the PC to extract them, it's very likely ascii corruption because WinZip has the "smart CR/LF conversion" feature...

Anyone else have any ideas. I just double checked and the file usdir.rdm is in the same directory as roadmapgpsapp. I tried the chmod 777 but that didn't work. And I deleted it and put it back on and it still doesn't work. It is still giving me the same error message in the boot log.

chmod 777 but that didn't work.

Hmmm, drive needs to mounted read/write for that operation. But waht does ls -l in that directory say about the file?

I deleted it and put it back on

Same method of extraction/upload, or did you do anything different?

/Michael

Hmmm. I don't have my empeg on the network at the moment so I can't check, but I'm fairly sure the database files don't go in the bin directory that the roadmap-gpsass binary goes in. Check and make sure you're either using the defaults given in the installation instructions, or specifying where they are in your config.ini.

GPSapp-Roadmap is a great program once you get it going, so keep trying. Not really usefull for navigating yet, but it's really cool to watch as your arrow traces out the upcoming turns.

Does anyone know how much of a shift would it be to always have the arrow pointing in one direction and have the map rotate as you drive? As I navigate, I always orient the map so that I'm going up the page, and it'd be neat if gpsapp could do it too.

Matthew

You MUST install the usdir files and other support files in /drive0/roadmap (not /drive0/var/roadmap) as the install document says. That is unless you change the preferences files which you must put in /usr/share/roadmap (did you do this also?). The preferences file has a line which tells the roadmap code where to look for map files. I would say try to Install again using the same directory structure I mention in my install document.. if that doesn't work it's probably your FTP program corrupting the file.

Yep, that fixed it. Thanks. All it took was moving the usdir and state map to drive0/roadmap instead of drive0/var/roadmap.