October 16, 2015

GPS Ideas for a Digital India

Last June, I had the good fortune to visit Pangong Lake, in Ladakh, on the Indo-Tibetan border -- shown in the movie 3 Idiots -- and spent a cold and windswept night in a tent at Spangmik. The place is awesome. A huge blue-green mass of salty water -- a remnant of the seas that got trapped between India and Tibet when the former rammed into the latter and created the Himalayan range -- is surrounded by immense snowy peaks that turn golden at sunrise. But what was even more impressive was the night sky with its hundreds of stars, that we in the cities have forgotten about. Thanks to the Global Positioning System (GPS) and the Google Sky app on my smartphone, I could, for the first time in many, many years see and, more importantly, identify so many stars and constellations, including, Polaris - one of the most important stars used by ancient mariners to determine their position. Then it struck me -- in the past, stars were used to determine location but today the GPS location from my inexpensive smartphone was being used to identify the stars. How can we leverage this amazing technology in Digital India?

The most obvious usage is to track trains. If a smartphone stuck on the dashboard of an Uber cab can be used to pinpoint its location on a city street, a similar phone can be provided to the driver and guard of any train so that the position of the train can be known at all times and that too without any human intervention. In fact, with an app similar to the taxi hailing apps that are widely used by individuals, passengers can track the movement of trains on their own without having to call anyone. Given the delays that are endemic to passenger trains, passengers and those who are waiting to receive them can know exactly when and where to expect which train.

In addition to simply knowing about where a train is at any point of time, there are many other ways in which the railways can use GPS. One application that immediately suggests itself is one that tracks individual wagons that are attached to goods trains. Unlike coaches of passenger trains that, in general, always travel together as a part of the same train, goods wagons are more often than not connected, disconnected and reconnected to different trains and are very often “lost” and non-traceable except with much effort. Now if each and every wagon, that costs nearly Rs 10 lakhs, can be fitted with a solar powered GPS enabled smart-phone like device, a cheaper and customised version of that fitted in Uber cars, then it will be possible for the railways to be able to trace and track down every wagon in the country with hardly any effort. In fact, customers who book wagons to move their goods would be more than happy to pay an extra amount of money to be able to track “their” wagons and be assured of their timely arrival at the expected station.

GPS works without cellphone coverage but the device attached to wagon may not be able to “report” back from remote locations. But whenever a train, to which the wagon is attached, passes through a station with cell-phone coverage, its position would be reported. So even if the wagon is stranded at some awkward location, the station through which it passed last would always be known and hence the search for it can be narrowed significantly.

What can be done for trains can also be done for the thousands of interstate buses and trucks that travel across this vast country. In fact, private companies can consider offering this as a service to state transport corporations and truck owners. All that they would need would be to install an inexpensive GPS enabled smart-phone like device, just as they have on Uber or Ola, on each bus and truck that is registered to the system and then it would be possible to track its location on Google Maps.

In the case of buses, whether intra-city or inter-state, passengers would be able to know the exact location of buses and the expected time of arrival at specific bus stops. This will help people by reducing the wait at bus depots and bus stands. Trucks getting lost, stolen, diverted, stranded or otherwise deviating from their expected path is a perpetual nightmare for anyone who ships goods and such a service will be very useful. In fact, if such a device can be attached to a container then the shipper can track from door to door as the container moves from a truck to a train and back to a truck again.

Once we start tracking vehicles on the road, many other opportunities and applications open up. We all know that government owned vehicles are heavily misused by government employees for unauthorised, non-official work and the public has to bear the cost of the fuel. In fact, more often than not, fuel is directly stolen and sold on the black market. Now consider if each government owned vehicle in India is fitted with a GPS device that records and reports its movement on a daily basis to a centralized monitoring system. It is as if someone is sitting up there in the sky and, literally, keeping an eye on all government vehicles. This would of course be a gross violation of privacy in the case of private vehicles but there is no moral bar on putting on such a surveillance on vehicles that are funded by public, tax payers money.

Even if the number of government owned cars in India is very high, each such vehicle must be tagged to some authority that, in principle, should control the use to which the vehicle is put and also approves payment of money for the fuel. Existing technology can be used to provide every such authority with a report of the mileage, and the route map if necessary, for each and every vehicle that it is responsible for. Now it would be up to the authority concerned to check the misuse of such vehicles if it wants to!  Of course, the GPS devices can be destroyed or disabled but that is another story altogether …

Another little known aspect of GPS is that most smart-phone cameras encode the GPS determined location of the place where a picture is taken into the digital image itself and this can be used very easily. For example, posting a digital image in Google pictures can cause it to be displayed on the map exactly at the place where the picture was taken. This feature can be used to track and monitor progress of construction projects like the ones taken up by the PWD or NREGA. The Ministry of Program Implementation can allocate a unique ID to all such projects and request members of the public to simply take pictures of the work that has been completed and upload on designated social media sites after tagging them with the project ID. Since the digital images will carry both the date and the GPS location, a simple collection of these images can be chronologically arranged to show the progress of the work, or lack thereof. While it contractors and corrupt government staff might tamper with the data, the presence of crowdsourced images taken by members of the public can be used as a cross reference. Central monitoring stations located far away from actual construction sites and hence hopefully immune to local corruption can check on the progress of such projects and decide to release or withhold further funds depending on the progress.

Finally, GPS encoding can be made mandatory for all land records, particularly in the rural areas where street addresses are not available. Traditionally, title deeds are identified through a complicated system of daag, khatian, mouza, block and rough maps. This leads to significant ambiguity in land ownership and doubts about the “cleanness” of a title. But going forward, land records should be augmented with GPS positions of boundary pillars.  Then each parcel can be displayed on an official Wikimapia style interface and unambiguously identified with a specific title deed so that anyone can determine who owns which parcel of land and the possibility of disputes can be reduced significantly

The availability of GPS services opens up the possibility of developing various kinds of interesting applications some of which have been listed here. The possibilities are endless and we are limited more by our imagination than by the cost or the technology but those who can visualise a new reality are vastly outnumbered by those who cannot. Organisations like ISRO, DST, Railways should float competitions where participants can showcase their ideas and the best one should be funded further for development and implementation. This would be another interesting aspect of Digital India.

This article has appeared in the October Issue of Swarajya

October 15, 2015

DIY IOT : Public Chat Servers to transport data over Internet

A key challenge in building the "Internet of Things" is to be able to connect a device to a computer over the internet and to use as simple and lightweight an infrastructure as possible. In this post we demonstrate how a public XMPP chat server can be used to transmit data and commands from one device to another using a chat client at one end and a python "bot" sitting on the other end. We will demonstrate the ability to INSERT data into an SQLite database, SELECT records from the same, play a variety of .wav files and execute any system commands on a "central" machine from any distant machine that supports an XMPP chat client.

Before starting on this exercise, we searched the web for prior activity in this area and we came across this webpage that suggests a similar approach for controlling devices over the internet, but the strategy explained here is simpler to code and implement.

We looked for a list of public XMPP chat servers and selected the Ad Astra service, perhaps because it was the first on the list! We next registered two userids, say x1@adastra.re and x2@adastra.re to be used on the two different machines using the web-registration form, because the in-band registration does not work!

We next installed the Pidgin chat client on two different Ubuntu machines and verified that text messages where being sent and received through the Ad Astra server without any problem.

Since working with two machines on a desktop is difficult, we configured our experimental setup as one Android phone acting as the distant machine and an Ubuntu 14.04 laptop acting as the central server. Commands transmitted from the Android phone using the Xabber chat app would be received on the server and acted upon.

For the server side we configured a chatting robot, or chatbot with Python using the xmppy library and using the code for the sample bot as a starting point. The sample bot program has a number of sample "handlers" that perform some simple tasks. These were modified to perform the following tasks
  • PUSH - to insert a piece of data into an SQLite database
  • PULL - to select a record from the SQLite database
  • SOUND - to play a selection of .wav files using the aplay command available in Ubuntu
These tasks were to be executed by calling a shell program and passing the relevant parameters through the python subprocess command.

There were three other handlers
  • EXESYS - to execute any system command on the central machine
  • TEST - to echo the command received back to the sender as a debugging measure
  • HELP - that lists all the possible commands.
Before the chatbot starts, we need to install SQLite, create a database and within it, an rdbms table. 

The chatbot ("chatIOT") is a python script that needs to be started with the userid@servername.com and the password as the parameters. It then listens for text messages and responds as appropriate to the six commands listed above.

The Xabber chat client on the Android phone is now used to send messages as follows

In the left hand image of a screenshot of the Xabber client on the Android phone, we see that the value PULLed from the database is 100.4. Then we PUSH 51.29 into the database and the subsequent PULL shows two values namely 100.4, 51.29 that were stored in the persistent database.

The second, right hand image, shows how the unix command ls for directory listing is executed and the data is returned. We note the three .wav files that could be played by sending the SOUND command along with a number that indicates which file is to be played.

How realistic is this setup in simulating a real IOT scenario ?

All that the distant device needs is a chat client. If it is an Arduino board then it is possible to create a chat client for the same as explained here and elsewhere. If the Arduino is connected to Raspberry Pi2, then life is even simpler because with python it is very easy to create a simple chat client - xmit.py

If one is not comfortable with messages being transmitted through a public chat server then one can build one's one chat server using the free and opensource OpenFire software and host it on a secure but publicly visible IP address. But even otherwise the usage of standard userid, password mechanism of a public chat server offers decent security.

What we have demonstrated in this exercise is how to build a secure data transport mechanism using publicly available components and with minimal programming. IOT developers and enthusiasts can focus on the behaviour of the edge devices without having to worry about the "plumbing" that will move the data from one machine to another.

The following files are available at Github :
  • the main python "bot" script, chatIOT.py and the shell script kmd.sh that is called by chatIOT.py to execute the SQLite and sound commands.
  • createIOTdata.sh and viewIOTdata.sh to create the SQLite tables and view the data
  • three .wav files for the three sounds
  • xmit.py - a lightweight xmpp chat client for sending text messages

Cross posted from iot-hub