What started as a need for a rear camera for older car turned into a complete car system. Fabrice Aneche builds own car navigation with Raspberry Pi using OpenMapTiles as a base map in his spare time as a do-it-yourself project.<h2>Raspberry Pi, LCD screen and a bunch of determination is needed to create a car&nbsp;system</h2>After Fabrice bought his car, he realized how badly he is missing a rear cam. Instead of throwing a pile of money at the nearest car shop, he decided, as a true geek, to <a href="https://blog.nobugware.com/post/2018/my_own_car_system_raspberry_pi_offline_mapping/" target="_blank" rel="noopener noreferrer">make own DIY system</a>. And that’s how everything has begun.As a heart of the system, he chose Raspberry Pi 3, an inexpensive single-board computer. It is connected to the Eleduino Raspberry Pi LCD screen, the video signal from the rear camera was captured using a USB adapter.<blockquote>My Car, from 2011, only has an LCD display and no rear camera, so I bought a PAL rear camera, we passed some cables from the rear window to the front then everything begun.</blockquote>The Raspberry Pi is powered by Linux with LXQTt desktop environment. After installing mplayer, the camera was running out of the box. Since everything worked, he thought about what to do next.<img src="https://media.maptiler.com/img/2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_2_a97b20d42b.jpg" alt="2018-10-08-diy-car-navigation-on-raspberry-pi-with-openmaptiles-2.jpg" srcset="https://media.maptiler.com/img/thumbnail_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_2_a97b20d42b.jpg 245w,https://media.maptiler.com/img/small_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_2_a97b20d42b.jpg 500w,https://media.maptiler.com/img/medium_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_2_a97b20d42b.jpg 750w,https://media.maptiler.com/img/large_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_2_a97b20d42b.jpg 1000w," sizes="100vw" width="1000px">A rear cam. Photo © Fabrice&nbsp;Aneche<h2>Maps powered by OpenMapTiles</h2>Since Fabrice has a GPS receiver around, he decided to utilize the screen for showing the actual position of the car on the map. As a map system, he chose OpenMapTiles for its’ ability to run offline on a device with scarce resources. Because the project is open-source, he hacked the code to serve precisely his specific needs.For serving map tiles, he wrote own server called <a href="https://github.com/akhenakh/mbmatch" target="_blank" rel="noopener noreferrer">mbmatch</a> in Go programming language. He chose one of the <a href="https://openmaptiles.org/styles/" target="_blank" rel="noopener noreferrer">default styles</a> for a day map and created <a href="https://github.com/akhenakh/mocs/blob/master/external/solarized-dark.style" target="_blank" rel="noopener noreferrer">his own</a> for a nigh, which is based on <a href="https://ethanschoonover.com/solarized/" target="_blank" rel="noopener noreferrer">Solarized color pallet</a>.This project is an excellent demonstration of the power of OpenMapTiles offline&nbsp;use.OSRM was selected as a backend for routing and the selected route was again displayed on the map.The complete car system is available under an open-source license on <a href="https://github.com/akhenakh/mocs" target="_blank" rel="noopener noreferrer">GitHub</a>.<img src="https://media.maptiler.com/img/2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_3_7511771b18.jpg" alt="2018-10-08-diy-car-navigation-on-raspberry-pi-with-openmaptiles-3.jpg" srcset="https://media.maptiler.com/img/thumbnail_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_3_7511771b18.jpg 245w,https://media.maptiler.com/img/small_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_3_7511771b18.jpg 500w,https://media.maptiler.com/img/medium_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_3_7511771b18.jpg 750w,https://media.maptiler.com/img/large_2018_10_08_diy_car_navigation_on_raspberry_pi_with_openmaptiles_3_7511771b18.jpg 1000w," sizes="100vw" width="1000px">A map with the actual position. Photo © Fabrice&nbsp;Aneche<h2>Start your DIY project with OpenMapTiles</h2>OpenMapTiles offers a free package for non-commercial personal projects. You can <a href="https://openmaptiles.com/downloads/planet/" target="_blank" rel="noopener noreferrer">download the data</a>, <a href="https://openmaptiles.org/docs/" target="_blank" rel="noopener noreferrer">read the documentation</a> and <a href="https://github.com/openmaptiles" target="_blank" rel="noopener noreferrer">hack the code on GitHub</a>.&nbsp;

 How to create you own car navigation with Raspberry Pi and our open-source map project.

Here at Klokan Technologies, we mostly develop software services and we run them as Docker containers. To release new versions, we use the <a target="_blank" rel="noopener noreferrer" href="http://martinfowler.com/bliki/BlueGreenDeployment.html">blue-green deployment</a> technique. This reduces downtime and limits the impact of configuration errors. The basic idea is simple. Instead of having just one production environment, there are two identical ones: blue and green. They take turns actively running the service. A new version is deployed to the environment that is not currently active. Only after the service successfully starts up there and passes all health checks is that environment marked as active. The old active environment is then stopped and prepared to receive the next deployment. The switch from one environment being active to the other one is a crucial step. If it’s not atomic, there will be a short period where neither environment is active and any request coming in at this time will fail. We use <a target="_blank" rel="noopener noreferrer" href="http://nginx.org/">Nginx</a> for this purpose because it does have this capability and because we have it as a reverse proxy anyway.&nbsp;<h3>Example</h3>To illustrate the whole process, let us consider an example. We will deploy a Python application in a file called <code>hello.py</code>, listed below. It listens for HTTP requests on port 9000 and responds with a greeting, providing a simple service.&nbsp;<pre><code class="language-bash">$ cat hello.py
from wsgiref.simple_server import make_server

GREETING = b'Hello, world!\n'

def hello(environ, start_response):
 start_response('200 OK', [('Content-Type', 'text/plain')])
 return [GREETING]

make_server('0.0.0.0', 9000, hello).serve_forever()
</code></pre>We will have one container for the application and one for Nginx. We will put both on the same Docker network, so that they can see each other. In our production environment, we have separate backend and frontend networks, but it is not necessary here. We will use official Docker images.<pre><code class="language-bash">$ docker network create example
$ docker pull nginx
$ docker pull python:3
</code></pre>First we start the application itself in the BLUE environment. Notice that we name the container <code>hello-BLUE</code>.<pre><code class="language-bash">$ docker run \
 --name hello-BLUE \
 -v $(pwd)/hello.py:/usr/local/src/hello.py \
 --net=example \
 -d \
 python:3 \
 python /usr/local/src/hello.py
</code></pre>Then we put the application configuration for Nginx into a file called <code>nginx-conf.d/hello.conf</code>. It sets up an HTTP proxy that forwards all requests to the application. Here again, we have to refer to the application container as <code>hello-BLUE</code>.<pre><code class="language-bash">$ cat nginx-conf.d/hello.conf
server {
 listen 80;
 location / {
 proxy_pass http://hello-BLUE:9000;
 }
}
</code></pre>Now we can start Nginx. It will read the configuration file we have just created and publish the application proxy on port 8080.<pre><code class="language-bash">$ docker run \
 --name nginx \
 -v $(pwd)/nginx-conf.d:/etc/nginx/conf.d \
 --net=example \
 -p 8080:80 \
 -d \
 nginx
</code></pre>See that it works.<pre><code class="language-bash">$ curl http://localhost:8080
Hello, world!
</code></pre>Now we make a new version of the service by changing the greeting in the <code>hello.py</code> file.<pre><code class="language-bash">$ cat hello.py
from wsgiref.simple_server import make_server

GREETING = b'Hello, world! (VERSION 2)\n' # &lt;=== Change here

def hello(environ, start_response):
 start_response('200 OK', [('Content-Type', 'text/plain')])
 return [GREETING]

make_server('0.0.0.0', 9000, hello).serve_forever()
</code></pre>We start the application again, this time in the GREEN environment. Notice the change in the container name. Otherwise the command is the same as before.<pre><code class="language-bash">$ docker run \
 --name hello-GREEN \ # &lt;=== Change here.
 -v $(pwd)/hello.py:/usr/local/src/hello.py \
 --net=example \
 -d \
 python:3 \
 python /usr/local/src/hello.py
</code></pre>We have to change the name of the application container in the Nginx configuration as well.<pre><code class="language-bash">$ cat nginx-conf.d/hello.conf
server {
 listen 80;
 location / {
 proxy_pass http://hello-GREEN:9000; # &lt;=== Change here
 }
}
</code></pre>Before switching active environments, we must check that the configuration is correct and that the application is reachable. There is an Nginx command line option for that, so we run it in a temporary container.<pre><code class="language-bash">$ docker run \
 --rm \
 -v $(pwd)/nginx-conf.d:/etc/nginx/conf.d \
 --net=example \
 nginx \
 nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
</code></pre>If the check was successful we send the Nginx container a SIGHUP signal. This will make it re-read the configuration and restart itself without dropping any requests.<pre><code class="language-bash">$ docker kill -s HUP nginx</code></pre>And we can see that we have a new version deployed.<pre><code class="language-bash">$ curl http://localhost:8080
Hello, world! (VERSION 2)</code></pre>The BLUE environment is no longer needed, so we remove it.<pre><code class="language-bash">$ docker stop hello-BLUE
$ docker rm hello-BLUE
</code></pre><h3>Conclusion</h3>In our example, we only had one application container for the service. There could be more and they would all be manipulated together. There could also be more services running on the same machine. They would each have its own BLUE and GREEN environments. The Nginx container and other infrastructure containers with state are not deployed using this technique. This includes databases and most caches. We can’t stop or restart databases because the active environments are using them even during the switch, and we usually don’t want to clear caches on each deployment. There is more to making this approach viable for automated deployment. We haven’t mentioned how to determine which environment is currently active for a given service and machine. Also, manually editing configuration files before each deployment is clearly not the way to go. At Klokan Technologies, we actually use <a target="_blank" rel="noopener noreferrer" href="https://www.ansible.com/">Ansible</a> with a custom module to solve both problems, but that is a story for another day.ld all be manipulated together. There could also be more services running on the same machine. They would each have its own BLUE and GREEN environments.

An example on how to make blue-green deployment of containers with Docker and Nginx. 

cloud-banner.svg

large_data-banner.webp

maxres_data-banner.webp

medium_data-banner.webp

small_data-banner.webp

thumbnail_data-banner.webp

xlarge_data-banner.webp

xsmall_data-banner.webp

data-banner.webp

engine-banner.svg

server-banner.svg

MapTiler

名称

Název

Name

Maps API

Geocoding

Map designers tool

GeoData hosting

Static maps

IP Geolocation API

Data processing

Weather visualization

MapTiler SDK

Self-hosting Server

Self-hosting Data

Products

Streets 

Satellite 

Basic

Light

Dark

Outdoor 

Winter

Terrain

Countries

MapTiler planet

Attribution-free map

Maps preview

Showcases & Tools

Maps & data

Transportation

Weather

Business Intelligence

Aviation

News & Media

Government

Mapbox alternative 

Google Maps API alternative 

Maps in videos

Maps for games

Custom coordinate systems

Augmented reality maps

Elections

Usage

Documentation Portal

API Reference

Web SDK

Android SDK

iOS SDK

Planet Schema

Countries Schema

YouTube channel

Bug report

Documentation

News

Jobs

About Us

Become a Partner

Open-source

Press

Contact

Cookie settings

Company

Language

maps-platform.svg

Maps Platform

geodata-hosting.svg

GeoData Hosting

weather-visualization.svg

Weather Visualization

maps-static.svg

Static Maps API

map-design-tool.svg

Map Design Tool

search.svg

Search & Geocoding

geolocation.svg

sdk.svg

MapTiler SDK JS

Maptiler Cloud

self-hosted-maps.svg

Self-hosted Maps

map-server.svg

Map Server

Server & Data

geodata-processing.svg

GeoData Processing

Engine & Desktop

Careers

Pricing

JavaScript SDK

API Client Library + CLI

Tileset Schemas

YouTube Channel

Support

Resources

Search

large_vaclav-klusak.png

medium_vaclav-klusak.png

small_vaclav-klusak.png

thumbnail_vaclav-klusak.png

vaclav-klusak.png

Vaclav Klusak works as a developer and software engineer. He is specialized in high-performance geospatial applications and cloud development. His analytical expertise is backed by knowledge of several programming languages (C/C++/Python/Java). In the past, he participated in the Google Summer of Code project in the geospatial domain. Vaclav has a master’s degree in computer science.



Vaclav Klusak

DIY car navigation on Raspberry Pi with OpenMapTiles

Blue-Green Deployment with Docker and Nginx