Category Archives: Traffic analysis

Deep Learning with the Movidius Neural Compute Stick


Deep Learning is a breakthrough in Artificial Intelligence. With its root from neural network, modern computing hardware advancement enabled new possibilities by sophisticated integrated circuits technology.

A branch of this exciting area in AI is machine learning. The leading development frameworks include TensorFlow and Caffe. Pattern recognition is a practical application of machine learning where photos or videos are analysed by machine to produce usable output as if a human did the analysis. GPU has been a favorite choice for its specialized architecture, delivering its supreme processing power not only in graphics processing but also popular among the neural network community. Covered in a previous installment is how to deploy an Amazon Web Services GPU instance to analyse real time traffic camera images using Caffe.

To bring this kind of machine learning power to IoT, Intel shrank and packaged a specialized Vision Processing Unit into the form factor of a USB thumb drive in the Movidius™ Neural Compute Stick.

It sports an ultra low power Vision Processing Unit (VPU) inside an aluminium casing, weights only 30g (without the cap). Supported on the Raspberry Pi 3 model B makes it a very attractive add-on for development projects involving AI application on this platform.IMAG1435

In the form factor of an USB thumb drive, the specialized VPU geared for machine learning in the Movidius performs as an AI accelerator for the host computer.IMAG1439

To put this neural compute stick into action, an SDK available from git download provided by Movidius is required. Although this SDK runs on Ubuntu, Windows users with VirtualBox can easily install the SDK with an Ubuntu 16.04 VM.

While the SDK comes with many examples, and the setup is a walk in the park, running these examples is not so straight forward, especially on a VM. There are points to note from making this stick available in the VM including USB 3 and filters setting in VirtualBox, to the actual execution of the provided sample scripts. Some examples required two sticks to run. Developers should be comfortable with Python, unix make / git commands, as well as installing plugins in Ubuntu.

The results from the examples in the SDK alone are quite convincing, considering the form factor of the stick and its electrical power consumption. This neural computing stick “kept its cool” literally throughout the test drive, unlike the FPGA stick I occasionally use for bitcoins mining which turn really hot.

Building an interactive journey time map from Traffic Speed Map data with Google Maps API


Some practical applications for road traffic data processing are the subject covered in past installments here, including a traffic jam classifier using GPU deep learning on surveillance camera images and a mash-up of CCTV still image feed with Google Maps. Both are centered around the data source provided by, which is an initiative to support big data development by disseminating government data of various type to the public through the Internet.

This installment will walk through another mash-up of Google Maps API for real-time interactive journey time map using Google Maps API. Simply put, it is an overlay of real-time road saturation level information on an interactive digital map.  A demo is available here. As a public demo, it is limited to routes from one of three local regions (Hong Kong Island), largely in consideration of the free daily Google API account quota. For personal use, Google’s free daily quota should be more than enough for most needs.rtm-21-colorcode

Work as well in the 3D Earth view.

Zoom in for a clean view of travel time in color-coded road sections with direction arrows of travel.

Traffic Speed Map data from

The Transport Department here publishes road travel time data on for selected road sections. It is not clear from that site the method of collections and collation of this average speed published. However it is envisaged that apart from traditional roadside vehicle sensors and automatic CCTV vehicle speed estimations, public transport operators like buses might have contributed with real time data from their fleet to improve the overall accuracy.

The page at provided all the necessary information to consume this data feed, including URL to the XML Traffic Speed Map file (which is being updated every 2 minutes), the schema of the XML file, and some supporting documents with the coordinates of the route origin and destination.

As the XML schema suggested, the XML file is structured pretty straight forward. It includes all routes in one single file, under the element jtis_speedmap (JTIS is probably an acronym for Journey Time Indication System, which is a decade old infrastructure aiming at informing motorists, via giant dot matrix displays mounted on highway gantries, estimated travel time of certain routes). In this XML file, each route is represented by one jtis_speedmap node, and underneath this node carries data associated with that route, including the route record identifier LINK_ID.


Most of these data elements are self-explanatory. For more details, there is a separate PDF file describing the data elements in details. In addition, the table available in an Excel file included the origin and destination coordinates of each route.

Customary to the local authority’s geodetic practices here, the coordinates in this file are expressed in HK80 grid, therefore translation to Google Maps’ WGS84 system is required. Further details of the translation are explained in this previous post.

Google Maps Directions

Because the data from only provided the start and end point of each route (indirectly from the accompanying documentations in PDF and Excel), it is not sufficient for color-coded plotting of road sections on digital map – a feature common to most standard GIS visualization application for road network monitoring. In fact, this plotting feature would not be possible without working with complex GIS data structure.

To address this data insufficiency issue, we are going to utilize a publicly available technology, the Google Maps Directions API. With this Google service, routing between two points on road network is as simple as providing the coordinates of the two endpoints. There are many options available from this service, but we are only interested in the “DRIVING” travel mode here for road network.

This route from Google Maps Directions, however, is not guaranteed to represent the exact route the Traffic Speed Map data meant to measure speed for, but should serve well as a reasonably accurate approximation, and can be further fine-tuned manually. For example, route 910-931 will result in a much longer route using Google’s route service than it is more likely to be, as shown in below the “as-is” route from the XML data (left) and the fine-tuned result by making judgement call after assessing the road network (right):

It should be noted that even after fine tuning, there are still some “interesting” routes. But without further information like waypoints from the data provider (the local Transport Department) to resolve these ambiguities, we would settle with this for now.

To make calls to Google Maps API, a Google API Service account is required. In addition, a secret key has to be generated via the Google API Console. By embedding this secret key in any Javascript code, the Google Maps API will be ready for action. There is a good online collection of samples for reference.

Integrating Google Maps Directions with Traffic Speed Map data at

To stick with the principle of keeping things simple, as in a previous article on Google Maps integration, the target is to keep everything inside one single Javascript HTML file.

The first step is to embed the static data from into Javascript code. Those data that are not likely to change often are considered static, and in this case, the coordinates of the routes available on the PDF and Excel file previously mentioned. Using simple awk scripts, the following code fragment is generated for such data. The way the Traffic Speed Map file uses hyphens in the link ID necessitated some character substitution legwork during code generation, as this is used as variable names suffix and thus have to conform with Javascript variable naming conventions which prohibits hyphens.

// start dynamic data code generation

// -- route ID 722-50059
origin722_50059= new google.maps.LatLng(22.2859946618326,114.15524436017);
destination722_50059= new google.maps.LatLng(22.28686575617,114.153536622643);

// end dynamic data code generation


Next thing is to build the method to read the XML file available on site. For security restrictions to safeguard cross domain issues on modern browsers, the XML file from the remote server will be mirrored to my web server using cron jobs and monkeyed in order to prevent violation of browser restrictions.

wget -q -O speedmap.xml
gawk "NR==2{print \"\"}NR!=2{print}" speedmap.xml > speedmap_clean.xml


Adding the entry below to the crontab to schedule running the XML file mirroring every 2 minutes for best synchronization to the data update frequency of the Traffic Speed Map at

*/2 * * * * /home/ubuntu/


Now it is time for the XML request method.

	function readXML() {
		var xhttp = new XMLHttpRequest();
		xhttp.onreadystatechange = function() {
			if (this.readyState == 4 && this.status == 200) {
				liveDataXml = xhttp.responseXML;
		// use speedmap_clean for javascript xml parser CORS issues."GET", "speedmap_clean.xml", true);


For supporting the extraction of specific data elements from the XML data source, some helper functions are prepared like extractSpeed() and extractSaturation(). These methods used XPath expression, as exemplified below, to retrieve values of interests in the XML.

var path = "/jtis_speedlist/jtis_speedmap[LINK_ID[text()='" + id + "']]/TRAFFIC_SPEED";


The TRAFFIC_SPEED value is extracted for displaying along with the LINK_ID as tooltip on each route markers on mouse over. The ROAD_SATURATION_LEVEL value is color coded to red, amber, and green respectively to render the route on the base map. At this point both the static data (i.e. the coordinates of routes) and the dynamic data (i.e. the XML file with speed and saturation) are ready. Plotting the route is simply by calling the Google Maps API “route” method from the class DirectionsService. The callback function holds the response object and will call another method in my implementation to render the routes and markers on the map. This is where our parsed data from the Traffic Speed Map XML file come into play – setting up the color code according to saturation and label the marker’s tooltip with speed information.

  origin: originLatLng,
  destination: destinationLatLng,
  travelMode: 'DRIVING'
}, function(response, status) {
    if (status === 'OK') { // Update the route on screen
        console.debug('Route service called and updated display');


As there will be quite a lot of routes to plot on the same map, and there are overlapping sections according to the Traffic Speed Map data, it certainly make sense to present information with higher value (congested road sections) without being covered by the less valued. A simple trick for this is to set the z-Index of the route to the inverse of its speed. Adding directional arrows along the route also helps to avoid route information being overlooked for overlapping routes as a result of rendering.

var zIndexInvSpeed = 1000 - parseInt(speed); 

directionsDisplay = new google.maps.DirectionsRenderer({
polylineOptions: {
 strokeColor: color,
 strokeWeight: 8,
 zIndex: zIndexInvSpeed,


Event listeners are attached to each of the markers for a simple filtering function. On clicking of a marker, the map will hide every other routes but the one clicked. This will allow some form of interaction for viewers to focus on specific route of interest from a road network full of color-coded road sections.

Another feature is to allow viewers to cycle through overlapping endpoints during filtering. Imagine a position where two routes joined up, that is, where the end of route A is also start of route B. On the map the markers as rendered by Google Maps will certainly overlap. Allowing user to cycle through by simply clicking away greatly improve viewers’ ability to drill down by filtering without being hindered by the overlapping problem. Shown below is an example of clicking on the end of route 930-931 which coincide with the start of route 931-4650. The overall filtering effect will be filtering out 930-931 first, and then filtering out 931-4650, and finally back to no filtering (show all).

The following screen shows the tooltip of a marker, with information of the route ID and the speed from the Traffic Speed Map XML data.

Color-coded road sections.

The core of the Javascript file is a loop that will update the map at specific interval according to the Traffic Speed Map XML data. Due to restrictions on request rating imposed by Google Maps API (which is a fair restriction), there are delays deliberately set in my implementation between each DirectionsService route call, even though this has to be done only once on startup for each route.

Finally the secret API key to calling Google Maps API must be included as the parameter to its library, along with the callback method.

<!-- Your GoogleMap API key goes here -->


Transportation and traffic analysis is one interest I am particularly fond of.  Studies on travel time has been a serious topic in the academics as well as the transportation industry, and is a very complex cross-disciplinary problem. For the general public, it is still fun to integrate your own free solution and in the way you want it to be.

Traffic accident images from

This traffic accident involving five vehicles happened last month and was caught on the CCTV camera. The still-image video below is constructed from data available to the public at, the same data source for an analysis of camera images using Nvidia GPU deep learning on the Amazon cloud.


Analysis of traffic CCTV camera image from with GPU deep learning on Amazon cloud

In this installment, modern computing technology including Internet, artificial intelligence, deep learning, GPU, and cloud technology are utilized to solve practical problem.

Traffic jam is very common in metropolitan cities. Authorities responsible for road traffic management often install CCTV for monitoring. Data available at site published on the Internet for big data analysis is one such example. The followings are two sample images from the same camera with one showing heavy traffic and the other one with very light traffic.

Modern pattern recognition technology is a piece of cake to determine these two distinct conditions from reading images above. The frontier in this field is no doubt utilizing deep learning network in GPU processor. Amazon AWS provided GPU equipped computing resources for such task.

The first step is to fire up an GPU instance on Amazon AWS. The following AMI is selected. Note that HVM is required for GPU VM.

The next step is to choose a GPU instance. As the problem is simple enough only g2.2xlarge is used.

After logging in to the terminal, set up CUDA 7, cuDNN, caffe, and DIGITS. The steps can be referred from their respective official documentations. A device query test below confirmed successful installation of CUDA. The whole process may took an hour to complete if installed from scratch. There may be pre-built images out there.

Note that an account from NVIDIA Accelerated Computing Developer Program may be required to download some of these packages. A make test below confirmed complete setup of caffe.awsgpu5

Finally, after installing DIGITS, the login page is default to port 5000. At AWS console network connection rule can easily be setup to open this port. Alternatively, for more secure connections, tunneling can be used instead, as shown below running at 8500.awsgpu6

Now it is time to start training. A new image classification dataset is to be created. As stated above the source image set is obtained from At this site, traffic cameras installed over strategic road network point feed JPG image on the web for public access. The images are refreshed every 2 minutes. A simple shell script is prepared to fetch the image to build the data set. Below is the screen where DIGITS configures the classification training.

Since our sample data set size is small, the training completed in no time.


Next, a model is defined. GoogLeNet is selected in this example.

Model training in progress. The charts update in real time.


When the model is completed, some tests can be carried out. In this example, the model is trained to determine whether the camera image taken indicates traffic jam or not.

A traffic jam sample. Prediction: free=-64.23%, jam=89.32%

The opposite. Prediction: free=116.62%, jam=-133.61%

With Amazon cloud, the ability to deploy cutting edge AI technology in GPU is no longer limited to researchers or those rich in resources. General public can now benefit from these easy to access computing resources to explore limitless possibilities in the era of big data.