GoPro cable cam

I've decided I'm going to try and compile a bunch of footage this summer from all the mountain bike trips I go on and at the end of the season put together a killer riding video.  With that being the plan, I wanted to make sure that I get some interesting shots and plan out the video a bit so it turns out better than my typical head cam videos do.  One of the shots I'm really eager to try is a cable cam shot through the forest on a long a trail.  You'll often see these super long shots following a rider in mountain bike videos and I think they are rad.  Anyway, I started Googleing around and found tons of examples of cable cams.  One that caught my eye was from this Vimeo video:

DIY GoPro Cable Cam from Maia Media on Vimeo.


I really liked the use of the RAM mounts because I find them to be very stout and easy to move into various positions, both of which are useful in a cable cam (I think... :) ).  Anyway, I also had the RAM mount stuff, so I just went over to Lowes and walked around looking for stuff to use.  Here is the list of things I ended up using for my cable cam:

List of items used:

1. GoPro Tripod Mount

2. RAM Mount handle bar mount with tripod adapter

3. Duct Tape

4. Clothes Line Pulley x 2

5. 1/2 in threaded rod - 1 foot - Can't find a link to just one foot.  You could shop around or cut a longer one down.

6. 200 - 300 feet of paracord

7. Line tensioner

8. A few locking nuts to match your threaded rod

I ended up having all the RAM mounts and GoPro tripod mount already from mounting my GPS on my motorcycle and mounting the GoPro on a tripod.  I picked up the rest of the stuff at Jax and Lowes near my house.  I just walked around Lowes until something came to mind, and then went over to Jax to get the paracord and ended up getting the line tensioner while I was there.

Here is the stuff I picked up at Lowes:

And here is what I got from Jax:

And the tensioner:

There's not really much to explain about what I came up with: 

I just found a 12 inch length of rod and wouldn't you know it, right above it was two pulleys that had a hole that perfectly matched the rode.  I just screwed a pulley on each side after a locking nut (which is totally optional IMO) and then I tried to attached the handle bar RAM mount in the middle.  The handle bar mount turned out to be a bit too big, so I just wrapped maybe twenty wraps of duct tape around the rod first.  I already had some paracord in my box of stuff, so I tested out the dolly with my wife in the living room and the camera rolls nicely along the cord.  Here is some video I took after the weather got nice enough to go outside and play.  This is maybe an 80' run from a tree to a post near my house.  I think 200' of cord will be perfect for the long forest shot.

The way I attach the cord between two objects is like so:

1. I take the end of the long cord and tie it around an object (tree, fence post, etc) with a bow line knot.  This is a great anchor knot and it unties very easily.  Here's a video showing how to tie one:

2. Then I took about a 6 foot length of paracord and tied multiple overhand knots along the cord.  I can now wrap this cord around a stationary object and then use the cord tensioner to attach to two of the overhand knots and tighten up the cable portion of the setup:

After I had the line rigged up I had some concerns about how to stop th camera at the end of the line.  I didn't want it just bashing into the object it was tied to as I figured it wouldn't be long before I broke a pulley.  I ended up laying my jacket over the line like so:


This worked like a charm bringing the camera to a gentle stop and had the collateral effect of dampening vibration on the line.

Feel free to shoot me any questions/suggestions in the comments.


- - Rob


Steadicam Smoothee with a GoPro H3 Black

One thing I really can't stand in my GoPro videos is all the shaky, jarring footage.  This is pretty hard to get away from if you have the camera mounted to your helmet or on a chest mount, but if you're planning on doing some hand held shots, there are a few options out there, one of which is the Steadicam Smoothee.

Full blown Steadicams are used all over professional film making, but one of my favorite examples is from the movie Goodfellas:


You can see you get one long, continuous shot, that is very smooth and dream like.  Once you're aware of the technology, you'll be spotting it everywhere.

Like so many things these days, the technology has come into reach of amateurs like myself and for around $100 you can create some pretty nice shots.  The trick with consumer level steadicams is that they take a little more work to get them just right.  In the case of the Smoothee, you'll notice that it takes a bit to learn how to "steer" it when your thumb and index finger.  You'll also find that getting a smooth shot goes up in difficulty as the wind does.

One thing to note is that the original Smoothee was developed for the GoPro H2 series which is a bit heavier than the H3 series.  To compound that, the device was intended to be used with the LCD backpack which also adds a bit of heft to the GoPro.  What this means is that when you first get the rig, if you just mount a standard GoPro H3 with no LCD backpack, the device is going to tend to swing.  You'll notice this in some of the shots in my sample video where I'm filming my wife on her horse.  These shots were before I decided to adjust the weight.  The swinging is also really compounded with wind and sunded changes in direction, so you're unlikely to get any great footage without adjusting the balance on the device.

After shooting some test footage with the camera, I decided to try and adjust the weight that comes on the front of the device and see if I could get a better dynamic weight setup.  Turns out, I was able to easily adjust the weight, and the results were perfect.  Here's a picture of how I moved the weight up:


I had to fiddle with the weight a few times to get it just right, but it's worth spending a few minutes to get the proper balance as your videos will turn out A LOT better.  Anyway, check out the a few clips I put together using my lovely wife as a subject:


Next up, I'll be showing the home made cable cam I built.  Stay tuned.


-- Rob


Mapping APIs and web services

A month or so ago, a friend of mine approached me about building a web site for him that would show routes and other information on a map and allow edits and so on and so forth.  I've played with the Google Maps API before but I wanted to have a look at using Open Street Maps instead because I really like using open source software when I can.

A little digging and I actually came across the MapQuest Open Data Map APIs and Web Services.  I signed up for an API key and played around with all the web services like geocoding and static map services before moving on to the JavaScripts Maps.  There is a bunch of sample code, and it's super easy to get up and running so I pretty quickly had a full featured map with controls and geolocation running.  That's when I remembered that I had created an XML file with all (actually as many as I could find), the ski resorts in North America.  This would be a perfect exercise to work with.  After browsing the developer guide, I found some sample code that loads a remote kml file using the MQA.RemoteCollection function.

I got this code up and running pretty quickly, but I wanted to round it out by using my own custom POI marker.  I found two Creative Commons (and GPL) licensed icons and mashed them togther to create the following:

I'm no graphic artist, but it'll do... :)

Here is where I got the two icons from: 

GPS marker

Inkscape icon

This is when I ran into problems.  It seems there is a bug when loading KML that prevents custom icons from loading correctly.  Instead I was only getting the icon shadows rendered:

I debugged the issue for quite some time, but I started seeing that a bunch of functions were not returning data or hadn't been implemented.  As a side note, the built in debugger in Chrome is pretty awesome.  I wouldn't go so far as to say it makes writing javascript painless, but it goes a long way to right direction.

After taking to the forums, I started to find that the Open Data API is pretty rough around the edges.  It works wonderfully for what it is, but there seems to be a lot of bugs still.  Either way, I'm going to keep using it, as this is really the only bug I've personally run into so far.

To get around this issue, I guess you'd need to parse out the KML yourself and manually add the POIs with a custom icon.  I did this for a few of the placemarks in the KML file and it worked great.

Anyway, have a look at the map with the default markers in place.  You can click on the markers to get info that was provided in the KML file.  I have a huge amount of data in the file, but I'm still missing a lot of info about resorts outside of the Western US as that's where I started gathering info:

 Full Screen 

Also, because I wanted to see the map with my custom icon and I already have a gmaps api key, I went and ahead and put this together.  You can click on the markers for info:

Full Screen

Lastly, I went ahead and added the ski resorts kml file I created from my xml data to the github repo where I keep this stuff.  Feel free to use the KML file or the above maps for your site or whatever you want really.  Some day I'd like to get around to adding all the stats for the rest of the ski resorts.

-- Rob


Data redaction

As an SE, I work closely with customers during evals and provide assistance building out a proof of concept during the eval.  I always advise the customer to build a POC with real data rather than trying to make up representative data.  Although there's many reasons why you'd want to use real data during the POC phase, the choice is not often that of the customer's as there may be other over arching rules/regs that need to be adhered to.  For my customers, it's often that there is sensitive data on forms or documents that can't be shared outside of the organisation.

Of course the simple answer is to redact any sensitive information on the forms, when/if you need to share the forms with me or my team.  I say this often to customers, but then they ask me "ok, well how do I redact the information?".  Well, I don't have a good answer to that, and I just ask them to use some sort of 3rd party tool.  This need to have full control over the eval process caused me to build an in house redaction tool.  I call it "Redacto 5000".... :)


Redacto 5k is a WPF/C# app that uses the Parascript FormXtra SDK to load a form definition and then redact all or selected data from a batch of images.  I've also added the ability to grow or shrink the size of the redaction fields.  There are a few other things in the works like being able to draw on custom redaction zones and the ability to move all the zones at once in the X and/or Y direction.  

Although I have experience programming with WPF/XAML, I did have to spend a little time getting up to speed with all the neat and sometimes confusing data binding principles.  Once you get the hang of how bindings works and the syntax in XAML, it's actually not bad, but I did find that it seemed a bit non-obvious at first.  A good place to start if you're new to the concept is the MSDN:




Android and OpenCV

I've been working on an Android app for work, and some ideas where thrown around regarding placing camera guides real time over an object.  The idea being that the guides would automatically adjust to the size of the image we were working with.  I wasn't totally sold on the idea, but I went ahead and investigated it any way.  

Some time ago, I used OpenCV in conjunction with QT to build a webcam app that would do face/person/dog detection, so I had an idea that I could probably use OpenCV in some form or another for the edge detection (I figure detect the edges, and you could place the guides at the corners where the edges intersect).  I was pretty happy to see that a quick google search pointed me to the Android port of OpenCV:

Not only is there a port, but it comes with a pretty cool sample app that has a ton of examples already built.  Literally, all I had to do was modify the sample app and I'd have a pretty good proof of concept.  I'm always amazed at the amount of free information and tools available to people these days.

After reading the OpenCV docs for a bit, I found some information on feature detection, and specifically a function called HoughLines, which finds lines in an image:

A little more digging, and I found a tutorial on how to use the function:

So my work would only consist of writing the Java code from the C++ example code.  I'm probably smart enough to do that... :)

Anyway, I ended up with the following Java code (this code relies on the OpenCV sample app):

          Imgproc.Canny(mRgba, mIntermediateMat, 80, 100);

            Imgproc.cvtColor(mIntermediateMat, mRgbaInnerWindow, Imgproc.COLOR_GRAY2BGRA, 4);
            Mat lines = new Mat();
            Imgproc.HoughLines(mIntermediateMat, lines, 1, Math.PI/180, 150);
            double[] data;
            double rho, theta;
            Point pt1 = new Point();
            Point pt2 = new Point();
            double a, b;
            double x0, y0;
            for (int i = 0; i < lines.cols(); i++)
                data = lines.get(0, i);
                rho = data[0];
                theta = data[1];
                a = Math.cos(theta);
                b = Math.sin(theta);
                x0 = a*rho;
                y0 = b*rho;
                pt1.x = Math.round(x0 + 1000*(-b));
                pt1.y = Math.round(y0 + 1000*a);
                pt2.x = Math.round(x0 - 1000*(-b));
                pt2.y = Math.round(y0 - 1000 *a);
                Core.line(mRgba, pt1, pt2, mColorsRGB[1], 3);


Here's a screen capture from my GS3 while doing real time edge detection:


 Edge detection on Android using OpenCV


In the end, the code didn't perform well enough for my likings, and I think there's still a lot of (non trivial ) work to be done to make this work in non ideal conditions (like where the background is not in stark contrast to the paper for example).  Non the less, I learned some stuff from the exercise, and who knows, we may do a version that works on the static, captured image for cropping or something.