Iris Navigation Videos

I’ll have to write several posts to fill in the details about how Iris went from being a bundle of wires on my desk to an actual moving robot, and then various wirelessly programmable evolutions of that moving robot; but, in the meanwhile, here are some videos of the progression:

Early Iris Prototype Body:

Iris Navigation Fail:

Iris Prototype V3 Basic Locomotion:

Iris Prototype v3 Basic Navigation:

Enjoy! :)

Install the Wolfram Language on Raspberry Pi

Working with the Raspberry Pi Foundation, effective immediately there’s a pilot release of the Wolfram Language—as well as Mathematica—that will soon be bundled as part of the standard system software for every Raspberry Pi computer.

Here’s how one would take this whole technology stack and use it to switch on LEDs by setting voltages on GPIO pins:

GPIO with Wolfram Language

And here’s some image analysis on a selfie taken by a RaspiCam:

RaspiCam self-portrait image analysis with Wolfram Language

Future Raspbian images will ship with the Wolfram Language and Mathematica by default; existing users with at least 600MB of free space on their SD card can install them today by typing:

             sudo apt-get update && sudo apt-get install wolfram-engine


Verizon Fios / Actiontec MI424WR Routers Insecure

I just obtained Verizon Fios service again at-last (after a few unbearable weeks on RCN). Verizon sent a nice new gigabit router (Actiontec MI424WR rev 3) to go along with it.

So, here’s where things get interesting. I set up the network myself. I changed the DHCP configuration, moved the subnet, changed the SSID and made it hidden, added WPA-2 PSK using a 64-character ASCII key generated by GRC, disabled remote administration, locked down the router, etc.

Next, after confirming everything was working, and modifying my TCP settings to achieve the rated speeds, I logged on to the myVerizon site, to set up automatic payments.

That’s when I saw it:

SSID_InfoThat’s right: the myVerizon website, out on the real internet, knows my custom SSID, knows that I’m using WPA2, and knows my custom WPA2 Pre-Shared Key. Clicking un-hide does indeed work.

Verizon/Actiontec have a backdoor in the MI424WR router. I wonder what else it’s exporting for the benefit of Verizon / NSA? (oh, I jest :-/)

How difficult would it be for a malicious user to exploit this backdoor to potentially gain unauthorized access to my Router or my LAN? It would take more investigation to be sure (e.g. is the backdoor exposed via a low-level protocol on the Coax/Fiber, or, is it exposed through TCP to the entire WAN/Internet)?

But no matter the outcome of further investigations, this is already a direct breech of security, leaking, at a minimum, private settings and keys, and also adding vulnerable surface area to the wrong side of the Router.

When all it takes to reset everything to factory settings for the average brain-dead customer who has forgotten their password or key is to hold the “reset” button for 15 seconds, what possible <reasonable> justification for this level of intentional security hole is there?

I suppose the obvious answer is that, to Verizon’s bottom line, it does not matter. The public doesn’t care about security, so Verizon doesn’t feel any need to provide it to them. They choose to provide convenience for their customer service department instead. And the tiny number of customers such as myself that they may lose because of this issue don’t even compare to the noise against their bottom line. Le Sigh.

Update — a screenshot to show that I’ve disabled remote management:


It appears that the router uses:

Remote CPE Control via TR-069.jpg
This protocol, according to Wikipedia, is supposed to be initiated by the device. It’s supposed to be used to remote-configure devices.

I configured my router manually, before even connecting it to the Coax/WAN, so this protocol shouldn’t have been invoked. If Verizon is using this protocol to share my passwords without my consent, it would seem to be an abuse of the stated purpose.

Alas, maybe that’s what the “+” in “TR-69+” stands for? :(

PocketSphinx on Raspberry Pi

I decided to try to install PocketSphinx for Raspberry Pi for offline speech-to-text processing (until now, I’ve been using the Google Translate APIs for speech-to-text).

The short version is that the out-of-the-box experience isn’t very good. It can recognize “Hello” pretty reliably; but, not much else! I’m hopeful that matters will improve with a custom dictionary.

Anyway, here’s a HOWTO for getting it up-and-running on the RPi:


The latest source for pocketsphinx can be obtained here.

You’ll need to download both sphinxbase and pocketsphinx.

You’ll also need to ensure that ALSA is installed. There’s a pretty good primer about how to accomplish this here.

The short version is that you must, at the minimum, install alsa-utils:

sudo apt-get install alsa-utils

You’ll also need bison and libasound2-dev.

sudo apt-get install bison
sudo apt-get install libasound2-dev

Note that the Raspberry Pi lacks any hardware microphone input, so you’ll have to install your own microphone. I am using the Logitech C920 webcam for this purpose.

After you’ve accomplished all of this, you should be able to install pocketsphinx.


Install sphinxbase:

gzip -d sphinxbase-0.8.tar.gz
tar -xvf sphinxbase-0.8.tar
cd sphinxbase-0.8
sudo make install

Install pocketsphinx:

gzip -d pocketsphinx-0.8.tar.gz
tar -xvf pocketsphinx-0.8.tar
cd pocketsphinx-0.8
sudo make install
Running PocketSphinx:

Test pocketsphinx:

./src/programs/pocketsphinx_continuous -adcdev plughw:1,0 -nfft 2048 -samprate 48000

Note, if you receive an error such as the following:

Error opening audio device plughw:1,0 for capture: Connection refused
Mixer load failed: Invalid argument FATAL_ERROR: "continuous.c", line
246: Failed to open audio device

You likely have pulseaudio installed, which is causing sphinxbase to attempt to use pulse instead of alsa.

The workaround (if you indeed wish to use ALSA) is to remove pulse, and then follow the steps above to re-install sphinxbase.

sudo apt-get remove pulseaudio -y
sudo aptitude purge pulseaudio -y
sudo mv /usr/include/pulse/pulseaudio.h /usr/include/pulse/pulseaudio.h.old

If you’ve done everything correctly, running ./configure on sphinxbase should give you output that looks like the following:configure_sphinxbase_correct


I primarily posted this because I ran into the pulseaudio issue, and there were no good resources on the subject (most people just recommended installing and configuring pulseaudio, and allowing sphinxbase to use that instead of alsa). I wanted to avoid the overhead and keep things simple, so I dug deeper. After reading through the application and library source code (<3 open source!), making some sandbox code to attempt to reproduce the error, etc., I finally figured out how to get sphinxbase to use alsa as intended.

I am hopeful that this post may save someone else the trouble I went through!

Hello world!

Welcome, anonymous internet reader, to my latest blog creation! ^__^

My blog about dance is at, and I really should start updating that one again, too.

Anyway, I decided to create this blog because I’ve recently gotten back into doing some robotics hacking in my spare time, and I’ve decided to chronicle some of my endeavors here (particularly ones that may help others avoid pitfalls I encounter along the way).

I hope that some of the content I post does have a positive impact. Comments welcome!