Bigger on the Inside

I have been asked a not a few times how I get the vector bot in and out of the sphere. Well that’s easy. The sphere has a small hole in it.

But that hole in only 5.25″ in diameter… and the vector bot is 19″ if it were a circle and not obviously a triangle… Solution: Design and build the vector bot to break down into parts that will fit through a 5.25″ hole. Everything is labeled and marked so it will only go together one way (easily).

I could have cut the hole larger, but I thought that leaving it small would give the sphere more integrity. It also leaves a smaller hole to patch later. Which is a nice side benefit. I did have my daughter (who was being mischievous with the duct tape at the time) put some tape around the cut edge of the hole. It’s amazing how a little tape can make you stop cutting yourself accidentally.

I also recorded it for you. And sped it up so you don’t have to sit through a 13 minute video.

Here is my post showing the way it currently moves

First Steps in the Sphere!

I finally got all the components talking correctly.  The Raspberry Pi receives data from the RF transmitter and sends movement instructions via USB serial (angle and velocity) to the Arduino. The Arduino translates those instructions for each of the 3 motors.  This happens BLAZINGLY FAST (and explaining what is happening will be a different post once I work out the kinks that I’m happily ignoring for the time being).

Getting the bot in the sphere is a challenge.

Here’s the first video I took of it actually working! IT’S ALIVE!

Please post any questions or post ideas!

Vector Robot First Steps!

Here are the first steps of the vector bot that drives my BB-8!  Each wheel is offset by 120 degrees. This is just looping through 360 degrees of movement. I think the wobble is from my inability to cut 120 angles by hand 😉

The math is pretty straight forward to find each motor’s relative velocity. Since the SIN method assumes radians, I have to convert degrees to radians.

motor_1_rv = SIN(degrees * pi / 180)

motor_2_rv = SIN((degrees + 120) * pi / 180)

motor_3_rv = SIN((degrees + 240) * pi / 180)

These will return a value between 0 and 1. Then you take each relative velocity and multiply it by an absolute velocity.

Later, I’ll probably map these relative values so the highest in the relative set would be 1. That way you don’t end up with two motors going 0.84 * velocity instead of both moving at 100%. Things to think about.

How physics works

“Every body perseveres in its state of rest, or of uniform motion in a right line, unless it is compelled to change that state by forces impressed thereon.” — Isaac Newton

Simply put, if you want something to move, you’ll need another force to act on it.  If you want something to stop moving, you’ll need another force to act against it.

In something like a bicycle this is easy. Legs create a linear force by pushing downward on the pedals using the gravitational force of the rider’s body which is then transferred by chain to the wheels. The wheels grip the road (friction caused by gravity acting on the spandex road troll) and the bicycle moves forward.

A car is slightly more complex. We replace the leg with a piston and gravitational force previously attributed to the body with a controlled explosion in the engine cylinders. That linear movement is translated to rotational motion (crankshaft) and geared properly before being transferred to the wheels. The wheels grip the road (friction caused by gravity acting on the vehicle) and the car moves forward.

In both of these oversimplified examples, there are only a few forces that really matter at the scale we’re talking about (BB-8 scale that is). We can throw wind speed and aero dynamics out the window since he’s not winning any derbies.  We really only need to keep track of a few forces. Namely gravity, friction and inertia. Since we’ll be discussing going from one state of INERTIA to another, we only need to add GRAVITY and FRICTION (and this lamp). As a point of order, I reserve the right to make up additional forces as we go.  That’s the law according to the rules.

Onward to Spherical Stability:

Weebles demonstrate part of this discussion very practically.  For simple spherical stability, you need a low center of gravity (I’m purposely ignoring gyroscopic stability since it would not be considered simple).  We’ll refer to this weight as a ballast. As you adjust the center of mass to the outside of the sphere (lower the center of gravity) you increase stability. Weebles (and weight driven spheres) have very low centers of gravity. You can increase stability even further by increasing the weight ratio of ballast to total weight.

Spherical motion, in many ways is far simpler than the bike or vehicle explanations. You can apply motion to the sphere by moving the ballast to another location in the sphere. Done. By moving the ballast, you change the sphere’s center of gravity. Then the sphere rolls to orient the ballast to it’s lowest point. How you move that ballast is up to the designer. The point is, you are always applying force somewhere in order to change the position of the ballast.

Hamster in a ball

The literal hamster in a literal ball works because the hamsters weight offsets the sphere center of gravity. When the hamster walks (or runs, trips, slides, rolls) ‘up’ one of the sides, its weight changes the spheres center of gravity and the balls rolls. Replace the hamster with a small robot and you have Hamster drive.

Axel drive

If you connect two opposing poles of the sphere via a shaft (or axel) and hang a ballast from it, you have effectively also lowered the center of gravity. By attaching motors to the shaft supporting the ballast, you can ‘move’ the center of gravity and thus move the sphere.

Turning can be achieved by tilting the ballast left and right perpendicular to the rotation force, parallel to the axel. Then the sphere will lean. You can spin the sphere by quickly rotating the ballast. Since the ballast outweighs the sphere, the sphere inertia is overcome before the ballasts inertia.

Omni Vector Drive

My solution (for now) is to attach the ballast to the sphere via omni wheels. The weight of the ballast gives the wheels enough friction to reposition the ballast and thus drive the sphere.

I’ll leave you with two pictures and a gif. I’ll highlight more of my design in another post.

Omni vector bot inside sphere
The ballast under the bot is 10 lbs

Here you can see the wheels rotating to correct the ballast position. This is me rotating the sphere and watching the wheels correct, but in reality the reverse will be happening.

Unpowered Movement


Exploring the Dome Code

First up: Its final form (until I change it)

“Finished” LED Arrays
Next, Goals. Goals are good.

I like to always start with the end in mind  What did I want these arrays to look like? How did I want them to function? What are the initial hurdles? And most important to a pragmatic problem solver… Do I know enough to get started?

I had already built the LED’s I wanted.

I wanted my arrays to appear independent. This brings up an immediate hurdle. Arduino is a single threaded processor.  People have done some AMAZING things with Arduino, but at their core, they are very simple. Here’s what a simple Arduino program looks like: (this is not actual code)

Get information
Do something with that information

This repeats until you turn off the device.  If I want all of my arrays to appear independent, I’m going to have to fake “threading”.  There are a number of ways to do this.  Since all of my arrays involve some aspect of time variance, it’s simple enough to make that the base of my loop, and fire off updates to the LEDs when the appropriate (random) amount of time has passed. (still pseudo code)

check the current time
if enough time has passed, update sweeper1
if enough time has passed, update sweeper2
if enough time has passed, update jitter

This will work, except we need to do a couple things if ‘enough time has passed’. In order to continue to make these calculations, we need to store a couple variables. We need to know when each array was last updated, and how much time should pass before the next update. Simple. Each “IF Block” would look more like this:

if enough time has passed:
update sweeper1
store last_Sweeper_1_Update
store next_Sweeper_1_Update

The current state of the code:

This has obvious organizational issues and things that can be done better, but it works. Quick note for those following along from home: In order to chain and control multiple TLC5940 together, you need to edit your tcl_config header and change the number of chips.

Here’s what the wiring currently looks like:

Semi-organized rats nest
Semi-organized rats nest
Helpful Links:

Breadboard Diagram

Arduino Playground: TLC5940


Just a series of pictures I took while building the inner vector bot.

1/2″ sand ply and 1×4 pine
Hardware for one wheel assembly


Getting the hub gear and the stepper motor gear to line up was taxing
Finished wheel assembly
“Finished vector bot

Here is a brief video showing how movement works with 3 wheels 120 degrees offset:

I will probably want to rebuild all of this when I get access to a CNC.

Dome Lighting

I wanted to do more with the dome lighting than what was shown in the movie. There, each array was made of 5 led’s and they didn’t do much. This was one spot where it’s “easy” to make it more interesting.

I purchased 100 2x5x7 mm LEDs. I knew they had a flange, but I could deal with that.  The openings in the dome are roughly 4×23 mm. So, I’d need to mount 11 LEDs in a row to fill the opening.

2x5x7 mm LED showing flange
Removing the flange cleanly was a pain, so I removed every other flange before super gluing them to my fingertips.

Video: LED Array

After quite a bit of sanding, I was able to get them to fit snugly into the opening.

Video: Mounted LED

I decided to do something even more different with the rear opening. I stacked the LEDs in pairs before gluing them together.

Video: Different Array

After getting the coding done (a future post, I’m sure) this is the result: (I wish video did a better job at recording lights.

Where it all began

Like many people, when I saw the newest little astromech to join the Star Wars cast, I was very intrigued. Actually, that’s not the right word is it… The word is obsessed. Not obsessed in the way normal people get obsessed. I’m not buying every version of BB-8 I can find from plushies to stickers (full disclosure: I have a sticker on my laptop), I became interested in the physics behind the droid.

There are many builders creating versions of BB-8, but mine is slightly different.  Let’s go back a bit, shall we?

We all know that BB-8 was a practical effect in the movie.  GREAT! They actually did it!  But how? There seem to be 2 popular ways to build this droid. Axel drive vs Hamster ball.

Axel drive involves connecting a ballast to the shell or skeleton of a sphere and using motors to rotate the sphere along a single axis to generate movement.

Hamster drive uses (usually) a heavy two wheeled bot inside the sphere. by moving the hamster, you move the sphere.

I’ll be using a vector bot.  It uses three omni wheels pointing outward in 120 degree increments and can move in any direction at any time.  While it has similarities to hamster, I won’t need to turn or spin the bot inside the sphere to turn.

I’ll be posting more information and designs as I go.  But just wanted to start off the new build blog with my basic direction.

TLDR > 3 omni wheeled vector bot mounted inside a sphere