I am currently writing custom software to create a variety of distributed media solutions.  One of these involves a raspberry-pi security camera.  Right now my software isn’t finished, but I wanted to prove the concept out using existing software.  System requirements:

Raspberry pi:

• Broadcast audio (over the LAN) to a server
• Broadcast video (over the LAN) to a server
• Receive (and play over the speaker) audio

Laptop:

• Receive audio/video from the raspberry pi (and display it)
• Send audio (from the laptop’s own microphone) to the pi.

I bought a raspberry pi b+, cheapo USB microphone, and IR camera (with built-in LEDs), and some speakers.  The whole package was around $100, which is just plain awesome.  Im sure my grandkids will marvel, 40 years down the road, that for the cost of an Obama-approved school lunch, I could buy so much.

Here’s a schematic of the setup:

This can be accomplished with a few scripts, which i based heavily on those found here: http://blog.tkjelectronics.dk/2013/06/how-to-stream-video-and-audio-from-a-raspberry-pi-with-no-latency/

Run the following on the pi:

function on_signal (){
    launch "kill -9 $piVideoPid $piAudioPid $osxAudioPid"
}
trap 'on_signal' EXIT

# Receive os x audio
gst-launch-1.0 -v udpsrc port=9102 caps=\"application/x-rtp\" ! queue ! rtppcmudepay ! mulawdec ! audioconvert ! alsasink device=plughw:ALSA sync=false &
osxAudioPid=$!

# Send pi audio
gst-launch-1.0 -v alsasrc device=plughw:Device  ! mulawenc ! rtppcmupay ! udpsink host=$broadcastIp port=$piAudioPort &
piAudioPid=$!

# Send pi video
raspivid -t 999999 -w 1080 -h 720 -fps 25 -hf -b 2000000 -o - |  gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96  ! gdppay ! tcpserversink host=$localIp port=$piVideoPort

Run the following on the laptop (a macbook in my case).  Note if this were a linux box you would probably use “autoaudiosrc”.

function on_signal (){
    launch "kill -9 $piVideoPid $piAudioPid $osxStreamPid"
}
trap 'on_signal' EXIT

piIp=<raspberryPiIp>

# Stream OSX microphone (note the capsfilter, apparently needed due to os x bug)
launch "gst-launch-1.0 -v osxaudiosrc ! capsfilter caps=audio/x-raw,rate=44100 ! audioconvert ! audioresample ! mulawenc ! rtppcmupay ! udpsink host=$broadcastIp port=$macAudioPort" "ASYNC"
osxStreamPid=$!

# Receive audio
launch "gst-launch-1.0 -v udpsrc port=$piAudioPort caps="application/x-rtp" ! queue ! rtppcmudepay ! mulawdec ! audioconvert ! osxaudiosink" "ASYNC"
piAudioPid=$!

# Receive video
launch "gst-launch-1.0 -v tcpclientsrc host=$piIp  port=$piVideoPort ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false" "ASYNC"
piVideoPid=$!

echo "Waiting on $piVideoPid $piAudioPid $osxStreamPid"
wait

You should be able to see and talk to whoever is on the other end of the pi. Biggest problem is audio feedback, if the laptop and pi are close to one another.  I havent even begin to think about this, but the coolest things to note are:

• You get a silky-smooth h264 video
• The audio is acceptable
• It works almost entirely using gstreamer.  The cool thing about that is gtreamer has a very easy programmatic API.  So… that makes my job easy when I get to that part of my project.

Enjoy!

Here it is, my first post of the new blog!

My nephew inspired the thought that led me to bring back the blog.  I told him he could easily setup something on my website if he wants to learn web programming.  Then I realized that for me to share the website, I’d have to figure out how to actually setup apache for subdomains.  I also wanted it to support https and http.

Turns out this is fairly simple:

• Add an A record to DNS for each subdomain
• Inside apache, include at least the following:

NameVirtualHost *:80

NameVirtualHost *:443

• For each subdomain make a conf file (in /etc/httpd/conf.d/) that includes a VirtualHost entry for each subdomain:

<VirtualHost *:80>
ServerName carson.fenimorefamily.com

# Index file and Document Root (where the public files are located)
DirectoryIndex index.html index.php
DocumentRoot <directoryForYourSubdomain>
</VirtualHost>

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile <crtFileName>
SSLCertificateKeyFile <keyFileName>

ServerName carson.fenimorefamily.com

DirectoryIndex index.html index.php
DocumentRoot <directoryForYourSubdomain>
</VirtualHost>

Note that I basically repeat the same section for SSL and normal.  Why? Because in the SSL virtual host you actually turn on the SSL engine.  All the rest of the innards of each section could be placed in a separate file and included, I suppose, but prudence (or laziness) suggests otherwise for now.

Here’s looking forward to blogging about useful technical stuff; I’m purposefully not sharing juicy tidbits from my personal life, as I think the only interested parties for those things are web bots and terrorists.

I’ll even try to do some retroactive blogging of projects from the past eight years.  To that end I’ll write a TODO list here and see how well I do at whittling it down.

• Mapping out the East Coast – Really keeping a log of places we’ve been and interesting facts
• Becoming landlords
• The chicken pi – my solution for monitoring a bunch of chickens
• Some woodworking stuff – I have pictures, why not post
• My recent raspberry-pi camera solutions
• Some details from my thesis
• My latest discoveries in web programming (oh how i used to loathe web, until angular came along)
• Programming a game with my nephew

This was a nerd get together. The only rules: eat a couple dogs before going on to lesser things (E.g. smores). The other rule: bring your wife and kids, unless your Carson. Carson was exempt.

Here we have an assortment of pictures of the Hot Dog BBQ: http://www.oakenweld.com/coppermine/thumbnails.php?album=35

As the owner of a brand spanking new Canon SD1000, I unpackaged the included software and found a nifty tool called PhotoStitch.  The camera itself only provides a special function which assists you in providing overlap between successive images of a panorama. The magic of the stitchery is in the desktop software.

PhotoStitch does a descent job, given its design parameters: it is intended to do the stitching largely unaided.  Hugin, an open source tool for creating panoramas, requires that you specify the alignment control points.  Although seemingly daunting, the task is actually extremely easy.

As one majoring in computer vision, I should understand the algorithms a little better – to be able to compare the two on an algorithmic level.  What is clear, subjectively, is that Hugin is just more powerful. If it makes a mistake, i can go back and add a couple more control points and out pops a better alignment.  Here below is a sample of output from PhotoStitch (software from Canon) and Hugin (open source software).

PhotoStitch

Hugin

A few pics from the party in the preceding post.

We chose to take part in the long standing tradition of the hot dog bar today in the Magicc Lab.  The first hot dog bar started in the spring of 2007 while at the INL, established with the de facto condiments: ketchup, mustard, relish, and Sour Kraut.  Later that year mayonaise was added to the condiment canon. This year, beyond the sheer joy of partaking of hot dog goodness, we also investigated the evolutionary history of the dog.   Look below to see the four major stages of hot dog evolution:

1. Emerging from the sea of primordial null dog soup, the basic frank emerged, exhibiting little taste or desirable texture.  These dogs have been given the name sawdust dog (SD), or just plain wiener.  This basic life form has survived deserved extinction for eons because of its low market price.
2. Slight evolution spawned the Oscar Meyer Beef frank, a $5/pack dog with barely noticeable improvements over the SD. It is expected – or at least hoped – that this branch will dwindle into extinction soon.
3. After steady evolution, the SD developed into the present day polish dog. The polish offshoot may optionally include a cheese core, but the basic idea is an infusion of more palatable spices into the same basic link.  Note the baboon buttox and lengthy arms that are crude predecessors to fully evolved bratwurst, below.
4. The Bratwurst represents the apex of evolution.  Full-bodied taste is carried by its well-developed bipedal frame.  Sporting a refined neck tie and a full smile, this dog looks as good as it tastes.  Other names include heaven-on-a-bun, or the King of Dogs. Some have suggested the name of this species be changed from Bratwurst to BratBest, to better reflect its palatability.

Hot Dog Evolution:

Link links:

Travis Millet, pictographer of the dogolution:

http://themilletfamily.blogspot.com/

The Crispy Dog, thanks to Jeff Kennington:

http://www.oakenweld.com/coppermine/thumbnails.php?album=20

A friend stopped by yesterday mourning the loss of his MacBook Pro power  adapter.  Since he had already ordered a new one from Apple, I asked if we could try to resuscitate the “broken” one.    It turned out to be a simple fix:

• Chisel along the seam of the power adapter; this may be he hardest part – mainly because it seems so unreasonably hard to get the blasted thing open.  Keep on chiseling, it will give with time.
• Snip the old wires and solder on the new ones.

Did I really need to make this list? Bottom line: if your macbook adapter broke because you bent the cord to death, just pop it open and resolder.

Here we are, yet again, memory of memories, cross-country skiing in Rexburg.
 

On a snowy Sunday afternoon, we made our way to the “Duck Park” in Rexburg, ID.  When we arrived we found the ducks all gathered around a drainage pipe that had warmed up a portion of the lake enough to melt the ice.  There was limited space, and unfortunately the ducks had to share this cramped space with a dead comrade.  Shown below is the dead comrade, as well as the live ducks.

Shown below I am contemplating giving the dead comrade the kiss of life.

Above are the front, back, and top view of the recovered camera from the  Thor II launch, recovered nearly two years after launch.  This camera differs from that used on the Thor I launch in a number of ways, namely: the film type used was Advantix on ThorII, versus standard 35mm on ThorI. The most significant difference was simply the timing circuit. ThorI used a relatively simply 555 timer circuit, whereas ThorII had a loop running on a microprocessor. Clearly, the 555 method produced good results, as shown on the ThorI page, whereas only 4 relatively poor photographs were recovered from the ThorII camera.