Car Navigator
From 1ste Gimnechiske Wiki
I have planes to make a Car Navigation unit, that uses free maps from OpenStreetMap, runs on an embedded Linux, can give audible output to the car stereo, and can be used as an mp3/DivX player in the car. My hopes for this project is to enable WLAN connections for it to synchronize over Internet. There should be one main screen (for the driver) and a series of slave screens (for the back seat passengers), a GNSS unit enabling SBAS corrections, wheel sensors, USB support for external storage devices, and support for some sort of memory card (SD?).
One of the objectives of the project will be to utilize cheap hardware so that the overall cost will be as low as possible. This is also important for making a commercial version.
Contents |
Hardware
I wish for the hardware to be simple and cheap. There are embedded units on the market for as little as $75 a piece. Depending on the chipset, vendor and price, a wide range of features are available. For this project, the following is required:
- 12VAC power supply (preferably with UPS)
- WLAN (IEEE802.11b/g/n)
- USB 2.0 (minimum 1 port, but more ports would be an advantage)
- SSD (Solid State Drive)
- Enough RAM to run Map and Tracing software together with mplayer or other media player
- RS-232 or serial lines, at least 1
- Audio Output
Options
- Support for multiple screens (i.e. to allow watching movies on another screen while main screen display the map)
- Ethernet 10/100/1000 Port
- Radio/TV tuner card (preferably with RDS support)
- 3G support (or next generation as well)
Software
Map display software
Map synchronization software
GNSS software
Track rendering software
Entertainment software
The Map
My plan is for the system to utilize the free maps offered from OpenStreetMap, but if other systems also are accepted by the software, than this is only a pure bonus. There exist documentation of how to get Garmin maps supported, so a map software supporting Garmin should be possible to install.
Update
There must be a way to upgrade kernel and map software over Internet, and via USB devices. The maps should be possible to generate in the box (downloads the data directly from OSM and converts locally) or download from a series of predefined links, either compressed or original. Must be possible for the user to add/remove links as he sees best.
- Update via WLAN
- Update via USB devices such as pen drives and external cd drives
- Update via mobile phone modem driver connected with USB (or internal)
- Update via other external sources such as Bluetooth or IR if available
Map Display
Map display is divided in different views, each with their different advantages and disadvantages. They can be generated on the fly, on load, or on compile. Typically maps generated on compile is available for download as binary files, while maps generated on the fly need to read the data directly from some source (e.g. a database). Map displays generated on load is a semi form, between these two, they can for example be generated from the same source file as is used when the display is generated on the fly, but it will store the generated map, and if time stamp on the source is not changed, just open the pre-generated map display. Both of these options have its advantages and disadvantages. Generating maps on the fly demands a lot of CPU, memory disc access, generating on load demands more storage capacity, while compiled maps requires you to download entire maps or entire tiles for each update.
There are also three forms of view projections, known as 2D, 2.5D 3D. 2D can be compared with a normal paper map, while 3D tries to recreate a true view with buildings, landscape, bridges, etc. 2.5D is also here somewhere in between (i.e. main features are recreated in 3D placed on a 2D map.
There are also some view orientations (and I use the terms from nautical ECDIS and radar units), North Up (up on the screen is geographical North), Head Up (front of vessel or vehicle is up on the screen), or Course Up (intended course is up on the screen).
Further there are two movement modes, True Motion (the map stands still on the screen while the vessel/vehicle is moving) and Relative Motion (the vessel/vehicle stands still on the screen while the map is moving).
Routing
Routing can only be done from data sources meeting certain criterion, you might have map data of high visual quality that still not meet the basic criteria for routing.
Waypoints
Waypoints is the ability to save your own POIs, such as homes of family members, camp sites, fishing grounds, etc. This can be used as an aid to routing (shortcuts).
Tracks
Storing tracks in GPX format allows you to contribute to OpenStreetMap, either by drawing your own tracks in, or by uploading to OSM for others to edit. For the data to be usable by OSM it must have a high enough sample rate and high enough position accuracy. Generally a good unit can sample the position every second, and even better units can include (or even filter) on HDOP in the track log. Minimum requirement for a track point to be usable in OSM is a position (lat,long) and a time stamp. OSM ignores tags that are not of interest, so additional tags doesn't break compatibility.
Emergency Routing
Emergency Routing is an advanced form of routing, and can take various forms. The most interesting for Car Navigation is quickest way to POI where POI of interest might be petrol station, restaurant, hotel, ATM, hospital, police, or similar.
Position References
There are several forms of position references of interest for this project. Currently GPS is the most reliable with global coverage, but also GLONASS have global coverage (less reliable than GPS, but have improved over the last few years). Further, the European Space Aggency are developing Galileo and the Chinese will replace (or append) their regional Beidou system with COMPASS. Combining these allows for higher accuracy, and using the advantages of the various systems under changing conditions. For example Galileo is expected to have a much higher accuracy in urban jungles than what is known of GPS.
Calibration
Various correction sources need calibration. Such calibration must be done over time, depending on the system itself. If multiple GNSS antennas are installed, the offsets between the antennas, and the length of cable must be entered into the system, so that they can be used to correct each other.
Position Augmentation
GPS have an accuracy depending on Latitude, number of satellites and the position of them of up to 2 meters for one frequency receivers. Two frequency receivers are generally either military devices or highly specialized industrial devices. So our unit is likely to only have L1 (civil frequency) reception. There have been made a series of systems to improve the accuracy of all GPS units, using Augmentation. The most common systems are IALA and SBAS, though several other systems are also available. The same can be assumed for all other GNSS devices.
Examples of Augmentation Systems:
- IALA
- MF Corrections
- HF Corrections
- SBAS (Satellite Based Augmentation System)
- WAAS
- EGNOS
- MSAS
- Spotbeam
- Subscription Systems over Inmarsat
- Veripos Ultra
- Wheel Sensor
Wheel Sensor is an augmentation system used by some of the pre-installed car navigation systems, such as the ones you find in brand new Mercedes cars. The principle is simple, it limits the direction where the system accepts a position jump. The GPS position have regular jumps out from where you are, due to various error sources and noise. The wheel sensor can say that since the car is moving in a fixed direction, and the front wheels are pointing in the direction of movement, a position acquired to the side of the route is rejected. If this system is set up correctly, it will take over with dead reckoning (DR) when GPS signal is lost (for instance when passing a tunnel).
In this project I will try to find out exactly how wheel sensors are working, and how to put it into my system.
