BB-8 presents some interesting engineering challenges. How do you get a robot that is basically a head balanced on a sphere to move around? How do you keep the head from falling off, and how do you move it independently from the ball? How can you make a robot that is a hemisphere on top of a sphere able to express emotions and interact with the world?

Nobody completely understands how the prop builders have made BB-8, so everybody who is building their own BB-8 is figuring it out themselves. The BB-8 Builders Club is collaborating on designs: everybody working independently (including me) is sharing what we learn. It’s open group prototyping, and it’s a fantastic way to work.

The Club’s best guess is that BB-8’s main “body” sphere is 50.6 cm in diameter, and the “head” hemisphere is about 30.0 cm in diameter. If you’re in the US, you can buy plastic hemispheres and spheres from California Quality Plastics; a pair of 50 cm diameter hemispheres will set you about about $500 USD. That’s way too much for me to spend on a prototype, and a 50 cm diameter is pretty big to have sitting around the house. I decided to build my prototype inside something smaller and cheaper.

I poked around for a while and finally settled on a run-about exercise ball for rats, which I picked up at my local pet store. I was lucky that the owner had rats, because I didn’t even know that the bigger run-abouts were a thing. The hamster-sized balls (about 17.5 cm diameter) are too small to work in comfortably–especially with the motors I have sitting around–but the rat-sized balls (about 29 cm in diameter) are perfect. I picked up the run-about for about $35 CAD. And I’m off!

I’m going to try to build the robot only from parts I have on hand. If something seems like a totally weird or completely awesome choice, it could just be because it was what I had sitting around. For example, I wish I could take credit for the choice of control over Bluetooth, but it was because I had an Arduino-compatible Bluetooth module and couldn’t find my Xbee shield.

Next up, I’m going to dig through my old parts and build a drive for BB-8.

In case you’ve been off in space rescuing Matt Damon, let me mention that new Star Wars movie is out. For many of us who saw the original in the theatre, and then survived the egregious abuse of fan loyalty that was the prequels, The Force Awakens was like a big apology hug from JJ Abrams. “We’re sorry. Here’s the movie you deserved.”

Much like the original series, there’s a character in the new film that’s captured the hearts of fans. The original movies had R2-D2, the helpful astromech droid who tolerated Luke’s complaining to deliver the plans for the Death Star and save his ass many times. The Force Awakens has BB-8, an equivalently helpful droid with a giant personality who you just want to hug. Really. You want to hug him. He’s adorable.

As a roboticist, I didn’t just want to hug him; I wanted to build him. I know several people who have build R2 and other astromechs over the years; those always seemed cool to me, but it all looked pretty straightforward. When I saw BB-8, a spherical droid whose head floats above his body, my immediate reaction was “now THAT would be a fun robot to build.”

My friend Matt introduced me to the BB-8 Builders Club, and I discovered that there were several people working on building BB-8 replicas, and some had already built them just based on what they had seen in trailers. Most notably, there’s James Bruton of Xrobots.co.uk, who in my opinion has built the coolest BB-8 out there… and published all of his files and code online. Go check it out.

But! The roboticist in me doesn’t want to follow instructions for what somebody else has built: she wants to figure it out herself. With this comes new skills (3D printing, 3D modelling), using old skills in interesting ways (mechanical engineering, electronics, programming, prototyping), and a fun little project.

I’ve been working on my BB-8 prototype for about a week now. These blog posts will be my attempt to chronicle the process and what I’ve learned. It will not be a guide to building BB-8; I can’t really do that with a prototype anyway, and I’m also going to tell you about the mistakes I’ve made. This is what it looks like to build robots. Feel free to follow along!

So for the second year in a row, I spent the first half of March in Portland, Oregon, USA, for EmberConf. The PN gang and I met Jeff Eiden of Spark, who gifted me with a Spark Core dev kit.

This little device is super cool. It takes 5VDC from a USB, and gives you both analog and digital in/out. It’s like an Arduino, but wi-fi connected, cloud-manageable, and API-interactable. All in this tiny little package… did I mention that you configure it without ever connecting anything USB except for power? Even on a WPA-passworded wifi network?

So the first thing I did (over lunch at EmberConf) was to make der blinkenlights: syncing the Core with the network, claiming it with the cloud web admin tools, and writing and uploading a program ALL WITHOUT EVER TOUCHING THE CORE. Seriously, this is cool. Painfully cool.

Anyway, it sat for the past few weeks until I thought of a project to do with it.

Lockify

I’ve had a Morning Industry deadbolt on one of my doors for a while now. It’s great when I rent my place on Airbnb, because I can have a guest choose a code before they come and they won’t need a key.

Last weekend I was doing a spring cleaning and I found an old RF remote that I bought with the lock: one of these little guys that looks like a keychain garage remote:

It can be paired with the deadbolt to lock and unlock it from the remote. That’s not useful to me, so I figured I could h4x0r this remote, connect it to a Spark Core, and use it to lock and unlock the door from a computer, phone, or tablet. Yep!

My friend and fellow Hacklabber Alex is a far more accomplished home automation hacker than I am. He has similar locks and can control them over Insteon. He uses a Morning Industry device that does the same thing I wanted to do. (I admire a company who will release a product that is basically a total hack.) Alex let me pop off the cover on the remote to figure out which switch connections did what:

… so I soldered the same number of wires to the same places on my own remote, choosing different colours so it would be easier to follow:

Then I came home and quickly figured out that I didn’t need all of those wires. (I didn’t need the green or the blue wire: turns out they were there because Morning’s solution to controlling two buttons was to have each button connected to its own Insteon bridge.) To power the remote, I needed to connect red to a +5VDC source and black to ground. If I supply current to the orange and yellow wires (even the 3.3V out on the spark’s digital pins is fine), it’s like pressing the button on the remote.

Since I wanted to do this on a prototyping board and not have lots of wires, I stopped by Creatron, our local nerdshop, and grabbed a both USB port and a barrel connector that I could use to power it. (I have them both on the board in the photo, but I’m only using the USB now because that’s the cable I have handy.)

How to do it

So now I have everything I need:

Spark Core

Prototyping board

Prototyping-mountable USB port (or barrel connector; your choice, but not both if you wire it up the way I have!)

Place the Spark in the centre of the bread board so all of its pins are in one of the center rows.

Get power to the board, Option A: Place the barrel connector into the side rails for + and – power (taking care to match up the + and – on the board and on the connector).

Get Power to the board, Option B: place the USB port into four of the centre rows that are NOT shared with the Spark Core. Connect a short red wire from the USB pin labelled VBUS (or +5V or something) to the + row in the power rail, and a short black wire from the USB pin labelled GND to the – row in the power rail. (Or if you have a USB connector that lets you connect directly to the +/- power rails, do that.)

Connect the red wire from the remote into the + power rail.

Connect the black wire from the remote into the – power rail.

Connect the VIN port on the Spark Core to the + power rail with a red wire.

Connect the GND port on the Spark Core to the – power rail with a red wire.

Connect the orange wire from the remote to port D2 on the Core.

Connect the yellow wire from the remote to port D3 on the Core.

Double-check your connections. Here’s my picture again. I think the colours should make it clear. Remember, you only need the USB port OR the barrel connector, not both.

Then I uploaded this code to the Core, powered it all on, and it worked! Here is the dashboard I wrote using Dashing, a nice little Sinatra/batman.js Ruby/Javascript dashboard framework from Shopify. [Github repo for Roombot, my dashboard.] With it, I can receive click/touch events and can lock and unlock the door from anywhere within wifi range. (The other cards in the bottom row are TTC arrival times, and the image off the screen is one of my security cams.)

All in all, a fun, fast little project.

I really like this little Core. A remotely-manageable, wifi-connected computer with digital and analog in/out pins? For that price… wow. I see more projects (and more Cores) in my future.

TL;DR

If you want to be able to destroy a Rails session_store = :cookie_store session from the client, you have to tell Rails not to use an HttpOnly cookie. In Rails 4, add this to your config/initializers/session_store.rb:

TL;RA:

So we’ve been dealing with this problem for about a year now. Our application’s back-end REST API is written in Ruby on Rails, with Devise as our authentication mechanism, and our user-facing EmberJS (Javascript) apps consume the API.

We have been using the Rails :cookie_store, which lets you store all of the session data in an encrypted cookie. The good news about this is that you don’t have to make a database request for the session data every time the user makes a call; the bad news is that it’s very hard to log out, because the only way to destroy the session data is by sending an update from the server itself. In fact this is a widely recognized issue; for more information you can see this blog post.

Now, what we really should do is switch to something like a Redis store or the built-in :active_record_store, just like that blog post recommends. We actually did that in our app, but we experienced problems with users being asked to log in over and over again. Session persistence was an issue, so we had to make a (very Agile) decision to switch back to something that worked. While switching back to a :cookie_store means they users don’t have to log in again and again, it also means that they can’t log out. And we have extra complexity because we have a special Rails controller that handles launching into multiple apps based on user permissions. It’s going to need to be re-written at some point, but in the meantime we needed a fix.

Here’s the background: Rails uses a session cookie with the HttpOnly flag set. HttpOnly is a security feature that means a client (e.g. with Javascript) cannot directly update the contents of a cookie; updates can only come from the server. So you’d think it would be easy to destroy a cookie in Javascript and get around this whole problem of not being able to log out (because deleting the session cookie definitely logs you out). Except we can’t do that because of HttpOnly. Javascript can simply not write to an HttpOnly cookie. This is generally A Good Thing for security, so it’s hard to criticize Rails for making this choice (though I’m sure that won’t stop people from criticizing anyway). There was some discussion about using expiring cookies, etc., for cookie stores at https://github.com/rails/rails/pull/11168, but this comment from the pull request’s author is very telling:

Giving up. The inheritance and mixins approach in the chained and legacy cookie jar code is absurd beyond my patience.

Someone else is free to run with this code as a start and take the credit.

The proper solution is to use something like the :active_record_store or a :redis_store, where your authentication and authorization can just destroy the session in the database or Redis store. Maybe you’re in the situation we are, though, where that isn’t feasible. Well, I has solution.

The good news is that you can tell Rails not to make cookies HttpOnly, and it requires a single change in your initializer. You just need to add httponly: false to the session_store initializer. In Rails 4, add this to your config/initializers/session_store.rb:

Of course, you’ll have to manually destroy the cookie in the browser, or use something like Devise to sign out all users so they can pick up the new non-HttpOnly key. Once you do that, though, you can use any number of Javascript libraries to fiddle with cookies. There are several good ones, but I just wrote a little helper because all I needed to do was delete a cookie, and I didn’t want to import an entirely new library for a function I could write in one line:

Now, when the user logs out, the Javascript app sends a request to the Rails API to log them out, and once the Ajax callback is complete, I destroy the session cookie. Now when the app tries to redirect them to another page, their session cookie is missing, so Rails no longer knows who they are and sends them to the Devise sign in page. Here’s the CoffeeScript we’re using (I would apologize for it, but I love CoffeeScript) that removes the auth token we keep in localStorage and nukes the cookie: