I was fortunate to work on this project as part of a hackathon at work. I’ve always had an interest in FPV flying, and I have a pair of FatShark goggles that I’ve use to fly with a mini CMOS NTSC camera. The quality is poor, and it can be difficult to gauge your surroundings as there are no depth cues. It works, but is far from ideal or immersive.
I needed this hack to be on the cheap, and since stereo cameras are expensive I had to find a way to make my own, using two cheap chinese IP cameras I had laying around. The idea is to run the cameras via the datalink on the drone to the ground, and use ffmpeg to serve the video over a web socket to the browser for each eye, where I can apply barrel distortion using webgl.
Or so that’s how it’s supposed to go. Ignoring timing issues with the camera left and right frames and no way to reliably sync them, it actually almost had hope of working and produced some initially good results testing indoors.
Following the 1/30th rule of stereography, which states that the interaxial separation (distance between eyes, or in this case camera lenses) should be no more than 1/30th the distance of the closet subject, or in this case about 2.5 inches to have features of about 75 inches away and background at infinity. Convergence of the two final images can then be adjusted while wearing the rift, as well as doing the necessary barrel distortion required due to the optics in the rift (what give the immersive feeling).
RTSP In The Browser
No worries, though. FFMpeg, the swiss-army knife of streaming video and video transcoding comes to the rescue with the ability to transform a conventional mpeg1 streaming video transport that we can use directly with jsmpeg. In fact, someone had already created the node module node rtsp stream that wraps and handles the ffmpeg process creation and sends the data over a websocket!
In my case, I had two cameras so I simply had two servers and two different node/ffmpeg processes, each running on their own websocket:
Decoding MPEG1 video in the browser actually works quite well thanks to jsmpeg, which takes data in via websockets and renders each frame to a canvas element. Using three.js, it is possible to create a texture from the contents of the canvas with video data:
Ready for VR: Lens Distortion
You may have noticed using a headset like the rift there is a lot of distortion when viewing content that isn’t specifically designed for it, and vice versa. You’re probably familair with the oculus screenshots showing two rounded views of images. That’s because the lenses apply a pincushion distortion, which is an optical trick to make it seem like a flat image is actually immersive. In order to reverse the effect, a barrel distortion must be applied to the image.
This is easiest done with a fragment shader. A shader is best described as a simple program that operates on either all verticies of the 3D scene or all rendered pixel values. These programs are run in parallel on the GPU for each frame of the scene (and pixel/vertex) so they are quite handy and well suited for the task. In my case, I was interested in the fragment shader.
The fragment shader operates on pixel values, so applying perspective transformations and my case barrel distortion can work in real-time, as fast as the video stream. Here’s a fragment shader to do a simple barrel distortion and the accompyning vertex shader:
The video in the first step of the jsmpeg client is being rendered to the canvas, element but we need a way to get it into a webgl texture so the fragment shader can do its work. To do this, simply read the canvas raw RGB image data and create a texture in three.js:
Video data is now being sent to the GPU in the form of a texture. Now, create a new three.js material with the barrel distortion shaders:
Now, simply create a flat plane geometry of arbitrary size (we’re using shaders to compose our image so it doesn’t really matter) and create a mesh of the geometry and material:
In standard three.js parlance, let’s create a camera, scene, renderer and insert the three.js webgl canvas to the document:
Pulling it all together, the last thing to do is to setup the render loop. On each render, we want to update the texture and render the webgl frame:
How well does it work? If you have a modern browser you can check it out right here! Here’s an example of streaming a static video file instead of live camera (aspect ratio and chromatic abberation are not corrected in this example):
Left & Right
Now that we’ve demonstrated the ability to apply a simple shader to our video, we can use a more complete example that takes care of things like chromatic abberation caused by the lens and handles both cameras. This is accomplished by drawing both video feeds to an enlarged canvas, side by side:
I’ve also used a more complete rift shader that handles chromatic abberation and the center spacing in the rift optics and LCD screens, but the same basic concepts hold true.
I mounted my camera rig on a gimbal and was able to do a few test flights before going for a fly at Treasure Island. The link drops out in some places, but overall worked well. The effect was certainly immersive and has given me the motivation to continue to work on the project. Here’s a rather compressed video of the flight:
I have plans to use a board like Nvidia’s Jetson and run the necessary code directly on the GPU, on the drone itself and send back a composite stream suitable for viewing directly in a headset, possibly using USB 3.0 high speed cameras, or using the built-in MIPI camera interface, which allows direct frame access on the GPU.
I posted the code of my hack to Github.
What happens when you have half a million addresses and need to find out where in the world they actually are? You geocode them! Which isn’t the easiest thing to do — the difficulty increasing as your need for performance, quality and quantity goes up.
The first, and probably the most obvious, is to simply use an external service. There are plenty to choose from, with many major companies offering up their Geocoder API for your personal enjoyment (or dis-enjoyment). So pick your poison — Google, Yahoo, Bing all have nice API’s that will happily take an address and give you something that looks like a lat and long.
Of course, can you really make 500,000 web requests and no one be the wiser? Of course not. There are limitations, both on the service and potentially on your process to make these requests. For one, it’s pretty expensive for most API’s I looked at to purchase a commercial license suitable for bulk geocoding. But it’s also slow. And in slow I mean it takes time to make 500,000 web requests, wait for them to complete, and put the data some place. That’s not counting the fact you’ll need to somehow address failures, which probably means some sort of queue/worker system, that’ll need supervision, management, et al. Yeah, not fun. So even if you manage to find an awesome deal on 500k web requests to someone’s API, you still need to manage the carrier pigeon effect. At least until connections get faster and it suddenly becomes cheap to buy expensive online data and services.
It’s also worth mentioning that many of these providers rely on the same sources of data that are freely available. In my tests, there were only marginal differences in quality across various solutions (both commercial API, private sources of data and home-brew systems). The largest factor in geocoding appears to be address quality first, and your data source second (and how well your parser can understand bad addresses). Soundex helps with address quality, but some addresses data is just bad and I suspect Google and others use some form of dynamic analysis based upon past searches to obtain higher quality and suggestions for incorrect cities, zip codes, etc. Here’s an interesting report comparing various geocoding options and the effectiveness of each based upon testing with 100 addresses (pay close attention to shapefile based data sources).
With these facts of life in mind, I decided what any crazy person would — setup my own! Google be damned. I can do it, and in one week. Well, maybe two. I know what you’re thinking, pretty foolish and maybe even a little masochistic, and you’d be right on both counts.
Fortunately, PostGIS has in it’s latest version, buried under extras a quite comprehensive geocoder project based upon freely available US Census Shapefile data. I’ll walk you through setting up your own geocoder, complete with soundex support and ability to bulk geocode from a db table.
If you already have Postgres setup, you can skip or skim over these steps. Just make sure you have a working installation and now the paths to all the relevant bits where things are installed
Download & Install Postgres
For maximum flexibility in the initial prototypying, I decided to compile Postgres from source, but most distributions also have a package available and Postgres maintains binary and graphical installer packages for some. To compile:
You’ll need build-essential, gcc, etc. packages to compile
You’ll now need to compile and install PostGIS. Before you do this, it’s a good idea to spend some time setting up accounts on Postgres. The authentication model for Postgres relies on system accounts, specifically allowing root access to the postgres user by default, where you can administer other users as necessary. For my setup, I made sure to have a system account for every postgres user.
Create the postgres user:
You now need to create a directory to store the main Postgres DB files. I put mine under /usr/local, but you can put it generally anywhere as needed (the path is specified in configuration and/or during server startup).
Now you’ll need to create a postgres cluster and start the postmaster process. First, change to the postgres user:
You can now login using the psql client (as the postgres system user):
If all is well, you should be at a postgres command prompt like the following:
To quit, type “\q”. Now we’re ready to install and setup PostGIS!
You’ll need libxml2-dev, libgeos-dev and libproj-dev (xslt and convert are also needed for documentation). I had to manually compile and install geos (which you can get from osgeo).
Since we’re interested in the Geocoder from 2.0, we’ll need to grab the latest development snapshot:
Create a spatial database template
So we can easily create spatially enabled databases, we’ll create one as a template and apply the spatial data types to it:
Now to create a new postgis enabled spatial database, we just do the following:
Add soundex ability
To add soundex ability to the db (used in matching parsed address parts which includes soundex, metaphone and levenshtein abilities), first build the module under the contrib directory of your postgres source:
This will add the fuzzystrmatch under the contrib folder of your installation. To add it to your database:
Create a geocoder database
Now, we’ll need to create a new geocoder database:
Now, we can begin to setup our geocoder. We first need to populate some street abbreviation and state lookup tables, and the tiger_loader.sql, which is the actual code to load tiger data into the geocoder table structure:
(I had my PostGIS sources under /tmp in this case):
Next, create the actual geocode function in the db (note you need to be in the tiger_2010 directory):
You’re now ready to load US Census shapefile data into the geocoder! There’s a slightly contrived way of generated scripts from the db, but I found this cumbersome for loading many states, so I wrote my own with perl. Someone from the PostGIS mailing list also wrote their own:
For the original loader script and instructions, check the original documentation.
I found it useful to get all the files into a single directory, and then just process them from there (instead of having a separate script to do each state):
The loading process takes anywhere from 30 minutes to over an hour, depending on how many points of interest are in the shape file and the complexity of the generated sql. Once it’s finished, it’s quite simple to geocode addresses with pretty good quality:
What’s even more interesting is bulk geocoding by loading an entire table of addresses and selecting them back out (or to another table) geocoded. Here’s some code that does that (modified from (http://postgis.refractions.net/documentation/manual-svn/Geocode.html)):
What’s it like to use it for real life stuff? Well, your mileage may vary. I loaded all US States and performance ranged anywhere from 40 ms to over 3000 ms for some difficult addresses on a dual quad core machine with 32 GB of ram and fast disks. Part of the complexity is in the address parsing and attempting to match address parts to many tables, resulting in table scans and a lot of time and disk complexity. If you have many millions of addresses to geocode, this could be a problem.
I was able to increase performance by “pre-normalizing” my addresses, and then sorting them by zip code. This seemed to help the most, along with increases shared memory cache in Postgres configuration. I’m also looking at optimizing away some unnecessary table scans, and trying to make more use of partitioned tables and different indexes. So far, it’s worked for my purposes, and I haven’t tried to cluster it yet, which may be an option for some (e.g. partition multiple states or sets of data over many machines).
If you’re using Socket.io and want to reverse proxy your web socket connections, you’ll quickly find it’s somewhat difficult. Since web sockets are done over HTTP 1.1 connections (where the handshake and upgrade are completed), your backend needs to support HTTP 1.1, and from what I have researched, they break the HTTP 1.0 spec (see this discussion at stackoverflow).
Some people have been able to get HAProxy to work for effective proxying of websocket connections, but I couldn’t get this to work reliably when I tried the latest version and TCP mode.
If you’re using nginx, you won’t be able to proxy web socket connections using the standard nginx proxy_pass directives. Fortunately, Weibin Yao has developed a tcp proxy module for nginx that allows you to reverse proxy general tcp connections, especially well suited for websockets.
Let’s get a simple web socket proxy up and running. Download nginx sources and tcp_proxy module:
Compile Nginx with tcp_proxy module
Create a simple vhost like the following (note tcp must be defined at the server directive level):
You’ll notice there is an additional http section, with a check_status directive. The tcp_proxy module provides a simple and convenient status check page which you can use to see if your backend node processes are up:
Create a Simple Websocket Server
Start four node processes, each listening on different ports:
You should now check your status page to verify all backends are up and running:
You can also go to our proxy via standard http (web browser) and correctly see “Hello World” to verify we’re hitting one of our node backends.
Test Websocket Proxying
Now lets create a simple web socket client to test if we can actually create a websocket connection over the proxy:
For simplicity, I used a node static page server to serve this test page from the same node process and attached my Socket.IO instance to it:
Now, when we run our node instances:
And when we go to http://localhost, we can see successful websocket handshakes (which means we’re going over the nginx proxy):
Using this method you can successfully balance a cluster of web socket nodes, with some simple failure provided by the tcp_proxy module. Depending on the need and placement of nginx within your specific application stack, the ability to use this instead of something like HAProxy or some other balancer strategy could allow scaling many more connections per server without introducing significant complexity.
One thing that should be noted is you can no longer guarantee that a client will always connect to the same node process, like in the event of disconnection, so your application will need to understand this and implement session management across the cluster (such as using a redis or memcache session store, for example).