Cats Lasers Robots

Intro

The Raspberry Pi has really come along nicely.  This year for Pi Day they released an version of the $5 Pi Zero, which has wifi and costs $10.  That's $10 for a full computer with wifi, and bluetooth, which is pretty amazing (you do have to find or buy a 8GB microSD card and a micro USB power supply, so actual costs are closer to $25, but still).

I bought one without any real purpose in mind.  Around the same time my girlfriend bought a cat toy call the "Bolt".  It's a laser which reflects off a mirror and makes a large arc on the floor, randomly changing directions.  There's a single button on the back to turn it on/off.

I figured the button was just shorting something to turn it off and on, and I could replicate that with a Pi to enable it to be web controlled.

Before I began, I had some requirements in mind:

• The finished product had to be fairly well polished.  It had to look, at least at first glance, like a consumer product.  
• It had to just work when plugged in, I could spend as much time as I needed hardcoding wifi passwords ahead of time, but the end result had to be plugging it in and it working.  
• The normal button the back of the toy had to work the same as always.  
• The interface had to be relatively simple to use, I was ok with a page that could be bookmarked.

Hardware

The toy took 4 AA batteries which means it used around 5V and I could probably power it from the Pi as well.  The Pi uses 5.25 V, and while you can't power things from the GPIO pins, there is a 5.25 V pin that is a straight connection to your power supply.  The Pi power supplies are generally 1 or 2 amps, and the Pi Zero needs like 200 mA, so I figured I'd be fine on power.

So I got the toy and I cracked it open to see what was what.  It opened pretty well considering there were no screws.  The wiring was pretty simple.  Two wires supplying power from batteries, and then two wires connecting the button.

The first step was seeing if 5.25 V would even work.  AA batteries are nominally 1.5 V, which means it would be 6 V.  However, they drop off in voltage quickly, and rechargeable batteries are 1.2 V which would give 4.8 V, so it had to be fairly robust.  I hooked up a power supply, and set it to 5.25 V and confirmed everything worked.  Then I measured the voltage across the push button and confirmed it was just 5.25 V. 

The next step was cutting out the battery compartment, and confirming that 3.2 V from the GPIO pins would turn it on.  I measured the current draw of the toy at about 200 - 400 mA, which would be easily handled by my power supply.  Finally, I confirmed that the actual 5.25 V pin on the Pi could power the toy.  At this point I figured the hardware was settled, I just had to figure out how to send a command to a Pi.

Software

This is where I ran into some troubles.  While I knew a lot of ways I could do this in theory, I didn't want to have to mess with routers and port forwarding.  My first plan was to use Twilio and use SMS to control it.  However, looking into it, Twilio just converts SMS into API calls, I'd still need an API, and some way for the Pi to connect to it.

The low tech way of doing that is to just poll the API constantly.  That works, but it lacks elegance, and I'm all about elegance.

It turns out that Rails 5 supports websockets, which is the ideal way of doing this.  Websockets are just an extension to http.  Essentially websockets start as a http request, and the server just leaves the connection open.  There's more to it than that, but it's really just a standard around leaving connections open so that servers can send messages to clients without the client having to request it each time.

Websockets API

I got to work on making a Rails API, which was pretty straight forward.  The websockets stuff was also pretty easy, as Rails tends to be.  However, when it came time to make a client, I couldn't get the format of the requests right.  I was attempting to use Python, and whatever their websockets library is, but I decided to look for implementations that were designed with the Rails websockets server in mind.

I ended up using this project, which is designed to work with Rails.  Once I switched to that, the rest of the API work went quite fast.

Websockets Client

Next I made the Pi client that would listen for websocket events and turn on the cat laser.  The basic idea was simple: I found a Ruby gem to do GPIO stuff, and set it to drive my pin high for half a second.  I tested it with the hardware and everything worked (amazingly).  The hard part came in making the client robust.  This thing had to be very user friendly.  It had to just work.

The gem I was using had some hooks for unsubscribed, but I quickly learned they weren't reliable.  Further investigation revealed that there was a ping that came through every 3 seconds.  My plan was to record that and attempt to reconnect when it got old.  However, I couldn't get that gem to reconnect successfully.  My final plan was just to write the ping timestamps to a file, and then have the script end when they got old.  A separate script would check for ping age and restart the main script when it saw them old.  I set up a ramdisk for the ping file so it wouldn't kill my SD card.

This felt pretty hacky, but worked very well.  Every method of artificial connection problems I could simulate were handled by this.  It could take up to a minute to reconnect, but that was fine, and was mainly due to me running this as a cron job.  If reconnecting faster were really an issue I could do it in a loop.

Hardware, part II

With that I had a pretty solid setup.  I began to plan on how I would wire this all up.  While the hardware was simple, I was most worried about messing something up there.  It was around this time that I realized there was a flaw in my hardware plans.  I was planning on hooking a GPIO pin directly up to the low side of the push button.  I would raise it to 3.2 V and that would turn on the toy.  You could also press the button and it would raise it to 5.25 V as it normally would.  This let you use the normal button the same as always.  However, the button would also short 5.25 V to the GPIO pins, which would kill the Pi (or at least the pin).  My first thought was to use a diode, which basically act as a one way valve for voltage, but they also drop the voltage across them, and it was already lower than it should be at 3.2 V.  My tests showed the diode was unreliable.

The failed setup

My next plan was a transistor.  Transistors are both sophisticated and simple, but for my purposes I could treat them as a voltage controlled switch.  I used an NPN transistor I had laying around and connected the collector to the high side of the switch, and the emitter to the low side.  I could then supply 3.2 V to the base to send 5.25 V to the low side of the switch and turn the toy on.  Pressing the button normally would short the emitter and collector, which would be fine.  I tested this set up and it seemed to work, although it was getting difficult to test all these connections with the toy physically moving around when it turned on, and the Pi having no headers to plug stuff into securely.

The winning setup

I used this as an excuse to buy something I had my eyes on for quite some time.  This fancy third hands tool.  You can get these things for like $5, but this one has a reputation for being very versatile and well thought out.  Plus they included a bag of Swedish Fish in the box, which made me happier than anything else in recent memory.

At this point I had three wires.  One I had soldered to the low side of the switch, and then the 5.25 V and ground supplies coming from the Pi.  I shrink tubed the solder joints to protect them (after one broke).  I began thinking about how the Pi would fit inside.  The Pi zero is very small, and there was a good amount of empty space inside the toy, particularly where the batteries had gone, so fitting it wasn't a problem.  However, I wanted it to be secured in there so I wouldn't have to worry about it coming lose and putting stress on the wires.  There were four screw posts where the battery compartment had been attached.  I decided this would work perfect to attach one of the corners of the Pi.  I spent a while going over the possibilities.  There were a lot of ways the Pi almost fit, but there seemed to be one choice that was the best out of the ways it did fit.

I soldered the wires to the pins on the Pi, and I attempted to drill a hole for the cord, only to discover the plastic was having none of that.  I resorted to using pliers to cut and twist the plastic apart.  This actually worked far better than I would have expected, and the end result was pretty presentable looking.

I plugged it all in and tested it with the API hosted on Heroku.  Amazingly it worked.  I tested rebooting the server and killing the wifi and other permutations, and the client consistently reconnected.

Alexa

The API worked well, although it was a bit clunky to use, having to bookmark a page with the basic auth username and password built in.  This gave a warning on most browsers that you had to click through.  Ultimately a legitimate front end would solve this, but in the short term I decided to bring in yet another technology

I was aware that Alexa had an API to perform custom actions.  Setting it up took a few hours, mainly due to how cryptic Amazon is about everything they do.

First you need to create a lambda function.  Lambda functions are just short scripts you write in Javascript or Python and Amazon runs them when you hit some endpoint.  They're pretty straight forward.  I used Python 2.7, and set up a "role" (Amazon's permissions model) with whatever basic preset was available.  I then set the trigger to be "Alexa Skills Kit".  My code was just the color sample code, with all my code in the get_welcome_response method.  That method gets called when the Alexa runs the lambda and all I had it do was hit my API.

At this point you get an ARN which is what you need the Alexa to call to run your lambda.  The second half was much more confusing.  First, for some reason all the Alexa stuff is not in AWS, but rather the "Developer Console".  Once I found that I created a new Alexa skill.  There is a ton of configuration for the skills, but for the most part I either left it as defaults, or googled values to enter for things like "Intents".  The only real configuration I had to do was to enter my ARN as the endpoint, and enter what I wanted to say to turn it on as "Invocation Name".  Once I got to the testing step I enabled that and it worked.  I didn't have to fill out Publishing or Privacy details.

While the skill worked for me, I wanted to make it available to other users, while not actually publishing it.  After hunting around I discovered you can invite users to be developers in Settings > User Permissions.  They then have to accept, and go into the developer console and enable testing in the skill.  It will then show up as a custom skill in the Alexa app.

With this, the command "Alexa, laser" would turn it on/off, and it worked pretty well.  The only hiccups have been in Alexa failing to understand what is being said.

How's it work?

 This setup has been running for 3 months now, and has been amazingly robust.  There has been exactly one case of the API and client not working, and that was caused by the Pi losing its wifi connection for some reason and then failing to reconnect.  Unplugging the Pi fixed it.  I then set up another script to run on the Pi to check the last ping timestamp and restart the Pi if that is a few minutes old.


The code for the controller and client are on Github:

https://github.com/StephenWetzel/pi-controller

https://github.com/StephenWetzel/pi-client