Believe it or not
I already invented one of these years ago, though I never built a prototype. It's a pretty obvious design, though, and I'm sure it's been "invented" many times before.
To be honest, laziness played a large part in my not building the thing, although lack of experience in electronics was also a large factor. I'd wanted to incorporate two features that, after a bit of thinking, it was clear that I'd have to learn a non-trivial amount of electronic circuit design (and source the necessary components) to implement, so I never went any further than the imagining stage.
First, I wanted to use a standard radio controller, but I wanted the ball to have a network of receivers (at least 4 arranged in a tetrahedron, but an inscribed cube, other platonic solids or buckyballs would work too). My thinking was that as each of the (directional) antennae would be at a different orientation to the incoming radio signal, each of them would be receiving the signal at a different strength, so it should be possible to triangulate, roughly, where the RC signal was coming from. The point of this was so that if I pushed the RC stick towards the ball, it would travel away from me, and vice-versa. All motion would basically be relative to a line between the centres of the controller and the ball. That seemed to make most sense in the absence of some kind of external positioning system (like GPS, but finer-grained). It would mean you'd have to know roughly where the ball is in relation to your position if you want to steer it meaningfully, though.
The other tricky bit would have been coordinating the movement of the weights within the ball. It's (fairly) trivial to shift the weights(*) in the right sequence if you want the thing to move in a distinct set of "steps" (with it settling down to a new centre of gravity before applying the next movement), but if you want it to act more like a ball and move smoothly you need to factor in all the moments of inertia in three dimensions as well as the characteristics of the motors that move your weights in and out relative to the centre of the ball (how fast and how accurately they can move, where they are at any given moment, and even the lag between sending the movement command and being able to act on it). If you want variable speed control you need to be able to measure the current moments of inertia (using accelerometers that weren't that cheap or readily available at the time) and adjust how far you shift the weights when you're already going fast (like an ice skater can move their arms in and out to adjust speed when spinning). Mathematically, it's fairly complicated, but doable. Unfortunately, as I said, I lacked the skill in electronics to be able to translate the maths into a proper control circuit. The various feedbacks among inertial sensors, current and projected centre of gravity and the sensor array used to triangulate where the user is makes it all very complicated, particularly if the thing is moving at high speed. Depending on the size of the ball, you might have gone through a significant fraction of complete revolution by the time the circuit has figured out what it should do next, by which time that calculation is completely wrong for the current state. Quality, high-speed sensors is a big part in overcoming that problem, but at the time I didn't have access to them. Nowadays, I guess a mobile phone has most of the sensors needed for this kind of thing though it still needs something better than GPS for telemetry.
So, anyway, I've got to tip my hat to these guys. I'm not sure how they've implemented their telemetry or whether they've cracked the problem of controlling the ball at high speeds, but it's really nice to see that someone has had a proper go at implementing this kind of thing.
*a note on weights: another alternative form of locomotion would be to have various pistons spread around the surface of the sphere. By pushing them out and retracting them in the right order (and with the right amount of force) it should be quite easy to get the thing to move quite quickly. It does sound like a fairly industrial-level implementation, though, since you'd need more pistons than you would internal weights. There's also the problem of legs breaking off or getting stuck on/in things that doesn't happen if the ball is self-contained and only contains weights and motors. On the plus side, if you have pressure (weight) sensors on the ends of the legs, that's a pretty useful sensor to have for detecting not only which side is up, but also for collision detection.
The other form of locomotion that I considered, and I'm quite proud of, is to use two-way memory metal to construct the shell of the bot. The idea is that in one state each of the wires forms a strut of a platonic solid (eg, a dodecahedron), while in the other state the overall shape of the ball is deformed at the bottom and it tips over onto the next face. By alternatively lengthening and shortening struts in the right order, it should be possible to get it to roll in whatever direction we want. The beauty of this sort of bot (provided it could actually be built, and I haven't overlooked some crucial problem) is that the shell (and a few sensors, power sources and other electronics distributed evenly around the shell) essentially is the robot. Taken to the extreme, it should also potentially be possible to use the memory metal itself as the communications network medium so there'd be no unsightly wires or internal circuits even visible. If someone wanted to try this, they could build it as a set of nodes (vertices) containing the processing parts and then the user could build it simply by training the metal struts and building up the dodecahedron out of nodes and memory metal struts. That's one variation of this idea that I would really love to see someone implement!