Two Years Down – Sphero History Part II (view Sphero History Part I here)
The ball is the most popular entertainment device ever invented by man. It is synonymous with fun, and comes in all shapes and sizes. So why has there never been a wildly successful remote controlled ball? My answer – because they are too hard to control.
Inside the simple polycarbonate shell, the story of Sphero’s technology is really two-fold. It takes both firmware and software to make the ball go ‘round. You can think of the firmware as Sphero’s brains, and the software as his thoughts.
Sphero’s firmware is essentially the software that runs inside the ball (watch the video to learn more). It is largely invisible to the average user, but it’s where all the magic happens. Sphero’s electronics, mechanics and design function only because our firmware creates order where chaos should reign. When we showed the mechanical design to our contract manufacturer, they said, “It won’t work. You don’t think we thought about making an R/C ball? We’ve been building electronics and toys for over 20 years.” And if you think about it, they’re right. A ball only has one tiny contact with the surface, it has no front or back, it wants to roll down any slope, and every child wants to kick or throw it. To make Sphero we would have to give it a very sophisticated brain.
We knew from the very beginning that creating Sphero’s firmware was not going to be a simple task. First off, we realized we were not going to perfect it on our initial release. We needed a way to update the ball’s “brain” in a simple and foolproof manner. Our team spent months writing and testing a little piece of code, called a bootloader, that allows us to replace Sphero’s firmware over Bluetooth connection in less than a minute. Today this is common in many devices, but virtually none in Sphero’s price range and very few devices perform this over a wireless connection.
Driving the ball is really a delicate dance of controlled chaos. The firmware inside Sphero has to do three things very quickly. First, it must understand what the internal robot’s orientation is in 3D space. Second, it must use that information to control the motors to balance the robot inside the ball and simultaneously execute the commands of the program controlling it. Finally, Sphero’s firmware must talk to either itself (autonomous operation) or the device controlling it (e.g. smartphone) to send and receive commands.
Understanding what Sphero is doing in 3D space is a huge challenge. To accomplish this, we included three sensors: a gyroscope, accelerometer and magnetometer (compass). But these sensors are really noisy, and it is hard to extract great fidelity from the data without a lot of calibration and mathematical processing. Luckily, we have a pretty smart team of engineers on hand. We fuse the data received from Sphero’s sensors with a mathematical algorithm collectively called an IMU (the navigation system that directs the robot). IMUs are hard to do well, especially at a low price point. Thanks to our number crunching and super secret calibration process, Sphero’s IMU is as good or better than some that cost $1,000. For you hacker type folks, you might want to re-read that last sentence – you can’t find a cheaper or better IMU with a more robust SDK for 10x the cost than a Sphero.
This allows Sphero to behave in a consistent manner. The IMU provides a dependable heading during aggressive speed changes or even an external collision – like when someone kicks Sphero or it runs into a wall. This means from a user’s perspective, forward is always forward.
Another unique challenge was Sphero’s magnetometer. Most IMUs use a GPS, compass or external reference to correct for drift in navigation (for example using magnetic north or a group of satellites as a guiding point). But because Sphero’s compass is very close to the field created by its drive motors, using the magnetometer became somewhat of challenge. We had to engineer a custom shield to get Sphero’s compass back on track. This worked well until we moved offices. All of a sudden, Sphero was completely out of control! It turned out that our old office had mostly concrete flooring, and the new one had a lot of steel (we sit on top of a bank vault). With this realization, we abandoned the magnetic compass and came up with a new solution – to make our IMU even better via more math and calibration, using just the accelerometer and gyro.
The next step is to translate the output from the IMU to drive Sphero’s motors. While we control Sphero in three dimensions, it only has two motors. Think of an airplane with yaw, pitch, and roll. For Sphero, yaw is the direction you want to go along the floor. Pitch is the speed and roll is the rate of turn. To get the fidelity in the controls we employed a control system that uses a closed PID loop (proportional, integral, and derivative).
PID loops are a very common feedback system employed to manage things that have to achieve stasis at some predetermined level (e.g. a given temperature). With Sphero, we are trying to achieve a balanced robot at a certain speed, along a certain heading. While this is a common method to control things, it is a bit of an art form of perfecting values. Our team has invested a lot of time tweaking these values, even enabling “super Sphero users” to hack them.
Control loops work great when the data feeding them makes sense, but with Sphero there are some instances when certain values from the IMU simply do not mean anything (e.g. when the robot points straight up inside the ball). The challenge for us was to not ignore the seemingly meaningless information but fix the IMU so it’s data was always meaningful to the control system.
To fix the IMU, we had to invent our own yaw, pitch, and roll coordinate system that changes dynamically based on the pitch angle of the robot inside the ball. Cue the complex math! We actually had to hire a PhD in mathematics – with an emphasis in chaos theory. As it turns out, Sphero’s IMU operates in four dimensions using quaternions but Sphero the robot ball lives in the three dimensional world. A simple translation from four to three dimensions (simple for folks with PhD’s in math) didn’t work. Instead, we developed our own translation algorithm (and yes, we patented it). If you had asked me if we would need this kind of horsepower to make a ball roll two years ago, I would have said “No. It’s just a ball.” But as we are learning every day, Sphero appears deceptively simple on the outside while making him roll is incredibly complex.
Stay tuned for the final installment of the Sphero: from Concept Robot to Polycarbonate series – The Apps.
