Skip to main content

Terrain Aware Navigation

A passion of mine is enjoying the outdoors, especially tramping. I love how easy it is to escape, just pack your bag and head away into the hills. On my last really great trip, my group was at least three days walk in any direction from anyone else. We had a great time visiting a very remote lake on the West Coast of New Zealand called Ivory Lake. But what if we had gotten into trouble? Would one of us have to walk out for three days to get help?



Over the last year I've been training in Land based Search and Rescue. In New Zealand many tourists, hunters, trampers, and outdoors adventurers of all disciplines get into trouble every year and need help. For a well prepared group any emergency would soon be followed by a radio broadcast, or the setting off of a Personal Locator Beacon. This immediately notifies the appropriate rescue personnel to the scene. In some cases, especially with solo outdoor people, the emergency services don't find out until many days after an incident - when a concerned flatmate or parent realizes they haven't been seen recently.

People are carrying electronic devices everywhere they go, these devices continue to get more and more "connected". Smartphones can do more every year, cameras are coming out with inbuilt GPS. Today in Christchurch Google announced a new project to deploy broadband internet to large regions of the world via balloon!

As technology continues to advance it will change the world of Search & Rescue. Companies like Google already collect data from your smartphone. They know that information is power. They helpfully update everyone on the traffic conditions when your car hasn't moved for a while but you're in the middle of a highway. What if that massive data gathering exercise was applied to the outdoors? What if gps traces were commonly shared - not just to share your most recent run, but during or after long periods "off grid"? Will there still be anywhere truly off grid in a few years?

Think about the possibility of analysing (in aggregate) the data of everyone who has walked a famous walk. You could build up a much better understanding for various categories of people. In addition to building detailed models of people's behaviour we could build increasingly accurate models of the terrain.

We can't accurately predict walking time by distance alone, gradient plays a huge role. But taking gradient into account still leaves plenty of inaccuracies - the difference between walking a kilometer on a flat pavement versus a kilometer through thick bush is astronomical. Sure at the moment we have maps that vectorize the entire world and categorize the terrain, but often these blanket categories are incorrect. If there was no barrier to uploading peoples' location data, or better if there were real tangible benefits to sharing... well it would mean we could learn the "difficulty" of traversing a particular place based entirely on evidence. It would probably have to be dependent on the mode of transport and favor recent data over old but it would allow terrain aware navigation. Imagine subtle suggestions of where to go (and not to go) coming from google glass - simply because it can see the numbers. By knowing someones' past history and the history of others whom have been nearby, we can predict more accurately how long they might take, potentially help to keep them on the correct path. Or in retrospect work out in a data driven manner where they might have gone wrong.

So none of this is particularly new, one of the key people in Search and Rescue is Robert Koester who wrote "Lost Person Behaviour" which is a book all about the statistics of lost people and how different categories of people behave. It is one of the fundamental underpinnings behind current search and rescue. At the moment the models are not (as far as I'm aware) used in conjunction with a computer model. Last known position could be fed into a program which could plot the relative probabilities of someone being found in a particular area. At the moment its up to a search management expert to correctly take into account; points of interest like huts and photo spots; linear features like fences, roads, rivers and ridges and distances that a particular category of lost person might travel. I think some software that helps identify some of these could well be life saving.

Popular posts from this blog

Bluetooth with Python 3.3

Since about version 3.3 Python supports Bluetooth sockets natively. To put this to the test I got hold of an iRacer from sparkfun . To send to New Zealand the cost was $60. The toy has an on-board Bluetooth radio that supports the RFCOMM transport protocol. The drive  protocol is dead easy, you send single byte instructions when a direction or speed change is required. The bytes are broken into two nibbles:  0xXY  where X is the direction and Y is the speed. For example the byte 0x16 means forwards at mid-speed. I was surprised to note the car continues carrying out the last given demand! I let pairing get dealt with by the operating system. The code to create a  Car object that is drivable over Bluetooth is very straight forward in pure Python: import socket import time class BluetoothCar : def __init__ ( self , mac_address = "00:12:05:09:98:36" ): self . socket = socket . socket ( socket . AF_BLUETOOTH , socket . SOCK_STREAM , socket .

Matplotlib in Django

The official django tutorial is very good, it stops short of displaying data with matplotlib - which could be very handy for dsp or automated testing. This is an extension to the tutorial. So first you must do the official tutorial! Complete the tutorial (as of writing this up to part 4). Adding an image to a view To start with we will take a static image from the hard drive and display it on the polls index page. Usually if it really is a static image this would be managed by the webserver eg apache. For introduction purposes we will get django to serve the static image. To do this we first need to change the template. Change the template At the moment poll_list.html probably looks something like this: <h1>Django test app - Polls</h1> {% if object_list %} <ul> {% for object in object_list %} <li><a href="/polls/{{object.id}}">{{ object.question }}</a></li> {% endfor %} </ul> {% else %} <p>No polls

Python and Gmail with IMAP

Today I had to automatically access my Gmail inbox from Python. I needed the ability to get an unread email count, the subjects of those unread emails and then download them. I found a Gmail.py library on sourceforge, but it actually opened the normal gmail webpage and site scraped the info. I wanted something much faster, luckily gmail can now be accessed with both pop and imap. After a tiny amount of research I decided imap was the better albiet slightly more difficult protocol. Enabling imap in gmail is straight forward, it was under labs. The address for gmail's imap server is: imap.gmail.com:993 Python has a library module called imaplib , we will make heavy use of that to access our emails. I'm going to assume that we have already defined two globals - username and password. To connect and login to the gmail server and select the inbox we can do: import imaplib imap_server = imaplib . IMAP4_SSL ( "imap.gmail.com" , 993 ) imap_server . login ( use