A number of people have asked me about building the robot sketched in yesterday’s strip. You’re definitely welcome to, and I’d love to see the results.
There are a couple engineering details that might trip you up. Rotating the webcam is one of them — I don’t make this explicit, but the idea in the blueprint was that there would be a servo inside the robot rotating the retaining magnets, which could be powered off the main battery. In practice, it might be better to put the servo on the outside and power it off the webcam battery — or, if you can find one cheap, simply use an omnidirectional camera.
The reason this is necessary is that I don’t think the internal robot, which is holding the webcam, will spin easily on hard surfaces. This is also the reason the robot uses Mechanum wheels instead of a simpler and cheaper design with a powered wheel on each side and castors or bearings on the front and back. If anyone has any ideas for making the robot spin more easily, I’d love to see them. Or perhaps you can try building the simpler design and see how quickly and reliably it can turn. If it works, it eliminates about half the cost of the project.
If anyone sends in any interesting material on this, I’ll be happy to put it up on a wiki somewhere so other people can tweak the design and develop a how-to. As far as I know, no one has built a robot quite like the one in the comic, so it’d be a great project.
Possible additional feature: cover the robot with little flaps or ridges, add some tweaks to protect the camera, and it becomes amphibious.
Edit: I’ve covered a few additional questions, including why the camera isn’t inside the ball, in this comment.
xkcd 
Why isn’t the web cam inside the sphere? Wouldn’t that be easier? I’m assuming that you’d want the sphere to be as close to transparent as possible anyway.
LikeLike
I’m not sure how loose the tolerances would be on the image processing, but if the hamster ball is clear enough, one may be able to get by putting the webcam inside the ball. That would reduce a lot of complication…also, to effect yaw control, you could implement a simple gyroscope mechanism by slowly spinning up a mass to a (relatively) high speed and inducing sudden changes in its rotational velocity to create a net torque about the vertical axis.
LikeLike
one thing to note is that based on the scale of the comic and the size of an eee pc, it is using a ball designed for a guinea pig or ferret, and not an actual hamster ball.
LikeLike
hiiiiiiiiiiiiiiiiiiiiiiiii
kiiiiiiiiiiiiiiiiiiiiiiiisssssssssssssss
tenk you
okeyyyyyyyy
byby
LikeLike
Check out the Swarm project @ http://orbswarm.com/: those guys use the angular momentum of the gear inside the robotic spheres to propel them.
LikeLike
A similar idea was floated here. Perhaps the smaller microcontroller is a better option?
LikeLike
I’ve noticed that most hamster balls (and other similar modes of transportation for small creatures) have air vents in the and are hardly smooth on either inside or outside. This complicates the matter a bit. I’m going to try and make this with Lego NXT robot parts (I’m not as good with computers as I’d like to be), so I think I’m going to look for a perfectly smooth plastic sphere.
TRH
LikeLike
Instead of the EEE PC one could use a Fox Board, a complete linux system in less than 7x7cm
LikeLike
> Why isn’t the web cam inside the sphere?
Because the sphere is being ground into the floor constantly, and will get scratched, dirty, and possibly covered in something opaque (this also means the bearings under the webcam may have to be more like castors, since they’ll be dealing with grit). Robot wheels get really dirty — image processing is hard enough without looking through a scuffed, curved piece of plastic with dirt smudges constantly flitting across the camera’s view.
> Instead of the EEE PC one could use a Fox Board, a complete linux system in less than 7×7cm
The EEE PC makes an attractive robotics platform because it has a built-in screen and keyboard — you don’t have to SSH/VNC in every time something goes wrong (and weird, frustrating things go wrong on a robot like this, many of which do things to the connection). You can just flip open the lid and type commands. It’s already optimized for low-power use, has a built-in video diagnostic display, works with all kinds of off-the-shelf hardware, etc.
Part of why I was interested in this is that laptops are getting so small cheap that they’re starting to look like better robotics platforms than the standard embedded systems we’ve always used.
> I’ve noticed that most hamster balls (and other similar modes of transportation for small creatures) have air vents in the [side]
> [the bot in the comic] is using a ball designed for a guinea pig or ferret, and not an actual hamster ball.
Yeah; I call it a hamster ball, but most likely it would just be a generic hard plastic ball not designed for animals. There are a number of companies who make them, although I can’t find any URLs at the moment.
LikeLike
A group over at UAT here in Arizona made something very similar to this, only the camera was inside the sphere and it had some sort of gyroscopic mechanism to keep its innards level. Their site seems to be down though, I’ll post a video somehow when I find it…
LikeLike
I keep believing whenever something like this comes up, that it is pure imagination from Randall’s side, and that it is impossible to do, and that even of the offchance that it IS possible, nobody would spend so much time and money and hard work on building and coding.
And each time I am proven wrong.
LikeLike
I’m not much of a builder; when can I expect to see these guys in the xkcd store? I’m sure mass production wouldn’t be hard (cafepress?).
LikeLike
It’s cool-looking, but what’s the advantage of encapsulating it in the ball? We put hamsters and ferrets in the balls to keep them from getting into the tiny spaces that they are uniquely designed to get into. But the device designed here doesn’t have that problem. It seems to me that quite a few engineering problems could be eliminated by thinking outside the ball.
As designed, the internal mechanism will need a way to keep from flipping over when the ball meets an obstacle. Some kind of torque limiter or level sensor would do it. I like level sensors so that the device could choose to put itself against a wall or obstacle in order to deliberately change the camera elevation angle.
LikeLike
Rotating the webcam should be doable. Use two bar magnets, one on the webcam and the other inside at the end of the arm. Mount them horizontally, and the camera will only go on one way, with poles reversed. That only leaves the need to include a stepping motor to rotate the magnet inside the sphere.
LikeLike
If the camera can be turned, why worry about spinning at all? Who cares about “front”? It can travel in any direction without spinning/turning.
LikeLike
if you used an XO, extra-sturdy what-what. you could maybe even let it go down the stairs, into caves, your brother’s room, etc.
LikeLike
My thought about this is that if you placed the omni wheels not only at the bottom but on the sides and top as well you would be able to role any way possible and flipping becomes less of a problem, also you could embedd the webcam in the ball by replacing a small part of it with a highly clear substance (better than the ball) to use as a camera, you could even use 6 to make it able to see multiple ways at once, thoughts?
LikeLike
> If the camera can be turned, why worry about spinning at all? Who cares about “front”? It can travel in any direction without spinning/turning.
Yes. It’s either/or — either find a way to turn or make the webcam turn. Either one makes the robot do robot things successfully.
LikeLike
> The reason this is necessary is that I don’t think the internal robot, which is holding the webcam, will spin easily on hard surfaces.
I don’t see how it could spin at all, on any surface. All the wheels are in line with the center of the robot. Unless with these Mecanum wheels you can apply power to the outer rollers, you’ll need to turn all the wheels 90 degrees.
As far as the problem of the ball spinning on a hard surface… I like the gyroscope idea, but here’s a simpler one: increase the coefficient of friction on the outside of the ball (coat it in latex maybe?).
LikeLike
although someone stated that they thought a hamster ball may have been the wrong choice (or at least, a difficult choice), i think that’s detracting from the point slightly.
to put it simply: hamster balls are *awesome*.
there’s clearly an innate sense of fun to a robot design which involves a hamster ball, and that, i believe, is the point.
there were a few striking positives about such a design, though. one would be its waterproof shell and natural bouyancy. such a robot, equipped with a padded, grippy sphere, could be used to send down potholes, caves and all manner of things. not only that, but the robot is also encapsulated within spherical armour, making it extraordinarily resilient.
the one weak link here, though, is the camera. the situation *would* arise, sooner or later, where it gets bashed, and the magnets lose their hold. as far as i can see, though, there’s no way of preventing this, short of having a small remote trapdoor so that the robot can withdraw its camera, then extend it again when needed. the camera could be seperated from its magnetic arm (after being withdrawn) by extending the arm to the correct length, then simply rolling, letting the surface of the sphere seperate the two magnets again.
also, how about having two synchronous EEE robots working on two opposite sides of the sphere, with a sprung frame between them, keeping them both held against the inside of the sphere. this would prevent the EEE from being rattled about inside, and also add some extra mobility (more power and weight, or perhaps more directions of movement).
hum…… you’ve got me thinking now.
LikeLike
I understand the logic behind the top-mounting of the camera, but the method seems a little odd. I mean, how strong are the magnets you’re proposing? Too strong and the camera wouldn’t ‘glide’, too weak and it’d be knocked off way too easily. I also don’t get the IR link. If we accept that the ball will become opaque over time, won’t this also affect the effectiveness of the IR link? How about some sort of RF? Bluetooth? IR seems anachronistic and impractical, compared to the sophistication of the rest of the technology involved (except, perhaps, the hamster ball itself).
LikeLike
>one thing to note is that based on the scale of the comic and the size of an eee pc, it is using a ball designed for a guinea pig or ferret, and not an actual hamster ball.
As much as I don’t wanna be “that guy”, please never put a guinea pig in one of those balls. Their backs are not designed to arch like hamsters or rats, and it is very uncomfortable and potentially injurious to them.
Just a brief message from your fellow geeks at the Silver Squirrel Rodent and Wildlife Rescue and Rehab.
LikeLike
http://www.whencloverfieldhit.com/video/view/90
LikeLike
“IR seems anachronistic and impractical, compared to the sophistication of the rest of the technology involved (except, perhaps, the hamster ball itself).”
Ah, but that is where you are wrong. Aliens use hamster balls as spaceships.
LikeLike
Could we do away with the bearings between the camera and the ball entirely and instead build a clever magnetic field that keeps the camera apparatus hovering a millimeter above the surface of the spehere. Since there would be no direct contact beween the ball in the sphere it may be a bit tricky to control the planar momentum of the camera.
LikeLike
> If we accept that the ball will become opaque over time, won’t this also affect the effectiveness of the IR link? How about some sort of RF?
The blueprint in the comic specifies RF. I’m not sure where you’re getting IR.
> It’s cool-looking, but what’s the advantage of encapsulating it in the ball?
Different drive mechanisms are useful for different things — an advantage of this is that it’s not as fouled up by string/rope, thread-like plants, or muck, all of which suck for a lot of treaded designs — plus, amphibious without much modification (also, make it heavy enough and it rolls along the bottom underwater as well 🙂 )
> As designed, the internal mechanism will need a way to keep from flipping over when the ball meets an obstacle.
I figured you just make it heavy enough and the motors weak enough and the ball just slick enough that it can’t naturally flip itself. But I like all your suggestions to deal with it more.
> I like level sensors so that the device could choose to put itself against a wall or obstacle in order to deliberately change the camera elevation angle.
I like those too!
> I don’t see how it could spin at all, on any surface. All the wheels are in line with the center of the robot.
You know, I hadn’t really given that the proper thought. I ran this by a friend who works on mechanum-wheeled robots, and he thinks that at the very least you could spin around an axis that’s through one of the wheels, and he’s pretty sure you could spin around the center.
If not, oops! But it’s not a big deal to flip the wheels — they’re just harder to draw if you flip them 90 degrees and then put them at an angle 🙂
LikeLike
Of course there would be no need to import the soul if you used Lisp.
LikeLike
I was with you right up to the camera. That really screams “NOT GONNA WORK!” at a deeply visceral level!
If the hamster ball is anything other than dead smooth, it flat out won’t work – so wave goodbye to having ridges or dimples on the ball for extra traction – which means that there is no way you’re going anywhere in water. It’s going to get horribly unstable and hard to keep in position if the hamster ball gets scratched or anything. What you have is inherently unstable – which is NEVER a good thing.
Worst problem with spherical robots is that when they start, stop, change direction or accelerate in any way, they wobble badly. Keeping the center of gravity low helps that – but putting the camera way up there (with it’s own separate battery and radio link) ruins that – and has the nasty side-effect of making the wobble even more noticable in any video you shoot.
Also – rather than using omni wheels – I’d use a Killough platform – which you can build out of Lego pretty easily for additional Geek credibility: http://staff.science.uva.nl/~leo/lego/killough.html
There are several other holonomic platform designs you could use…but you don’t need one – an R/C car or a skid-steer system like a tank would do just fine.
The new Lego Mindstorms NXT system includes bluetooth too.
For the fiction of really building one of these – the geeky approach would be to put the camera inside the ball and use cunning image enhancement software to eliminate the scratches and other imperfections in the transparency of the ball. As the ball moves, the camera gets ‘good’ and ‘bad’ pixels of imagery through the ball – but any given spot in the real world will be periodically visible through clear patches. Better still – you can track those imperfections as they move across the image to determine how your robot is moving without having to resort to stepper motors or rotation sensors on each of the wheels.
Since the ball is by far the cheapest part of the system – you can simply toss it out when it’s gets too damaged.
Ask yourself – how does the Hamster do it?
LikeLike
>Different drive mechanisms are useful for different things — an advantage of this is that it’s not as fouled up by string/rope, thread-like plants, or muck, all of which suck for a lot of treaded designs — plus, amphibious without much modification (also, make it heavy enough and it rolls along the bottom underwater as well 🙂 )
How would it have to be modified for underwater travel? For example, would you have to include some sort of flipper system for navigating at speeds higher than that which is allowed by simple inertia? water IS quite dense!
LikeLike
I’ve worked with mecanum wheels before and, for those of you considering taking on this project, I have a few bits of insight.
-The smallest mecanum wheels I know of are 6″ in diameter. I highly doubt you could go any smaller, because at that point you run into issues with making mini-rollers and fasteners small enough to fit in the wheel casing. I imagine that as the wheel diameter and mini-rollers shrink, the quickly decreasing area of the contact surface of the mini rollers and mobility starts to become a huge issue, so I doubt there are mecanum wheels smaller than 6″ in diameter.
-The 6″ diameter wheels are also very fragile. The FIRST robotics team I help out used them in competition and they were damaged in shipping (we were being stupid due to sleep deprivation and didn’t put the robot on blocks). It quickly led to the mecanum wheels not being able to strafe properly in any direction, although this is probably a much smaller issue with the hamster wheel since the spherical nature of the ball will make precise movement near impossible anyway.
-I’m not 100% sure, but I think that wheel configuration would allow for strafing in any direction as well as spinning.
That said, I think omni wheels may be a better approach. They are cheaper, more durable, and I have seen them in sizes similar to what would be needed for the provided diagram. The trick would be finding the right roller material.
LikeLike
Another cool omni-drive system uses two parallel cylinders – each with a spiral vane running around them (think of worm-gears) – but in opposite directions on each cylinder. If you drive them in opposite directions – you move parallel to the axes of the cylinders. If you drive them in the same direction – you go sideways (at right angles to the centerlines of the cylinders. Driving them at different speeds let’s you move in any direction. Watching one of these things drive in a circle hurts your head!
LikeLike
What are you guys using for your software with these? I’m new at this whole robotics building thing
LikeLike
Wouldn’t the robot run into problems with rotation if it was in a sphere? What I mean by this is like, if it runs into a wall at an angle, the ball would start spinning. This would be a problem for the model with the rotating camera because the front of the robot would be constantly moving and it would also be a problem for the robot with the rotating inner wheels because the camera would be facing a different way. The only way I see that would get past this problem is to have both rotating wheels to counteract the spinning and a rotating camera to keep looking one way.
LikeLike
Hamster ball with no rotating parts: mount the bot guts in the middle suspended by four piston actuators. The ball moves by shifting the center of gravity rather than rolling freely inside it. Who cares about staying level in that case?
Use small proximity sensors along the outside of the ball. As long as the bot always knows which way is up (gyro), it should be able to calculate where obstacles (current N hemisphere) and floor (S hemisphere) are continuously. Any camera(s) could be mounted under the surface of the ball, sometimes opening a shutter to snap a picture and closing to protect lens while rolling. Software can rotate the image right-side-up later; maybe embed bot orientation relative to camera position in the EXIF…
LikeLike
I don’t like batteries. In fact, I hate them. So reducing the number of batteries in the robot seems like a really good idea to me. Given that, why not use a high-frequency RF power link as well as the RF data link to the camera? UWB is likely the best technology for the RF link. It allows direct USB-USB over wireless links. If you run the power link at 900MHz and use UWB, which is 2.4GHz you don’t need to worry about interference.
You could also put a similar link on the bottom of the robot so that it could just roll into a charging dock to charge the batteries back up.
I do need to stress that if you’re going to use an RF power link, you need to use one half of a ferrite pot on each coil to increase the magnetic coupling between them and cut down on interference. Here’s a ferrite pot core for reference: http://www.mag-inc.com/ferrites/ferrite_pot_cores.asp. The best efficiency will be if both coils are resonant at the same frequency and if the operating frequency is the resonant frequency of the coils. (note that the ferrite shielding will mess up the frequency calculations pretty badly, but it’s still a good idea to use it)
Conventional webcams are designed to sit on top of a monitor or on a desk in order to get the best angle for looking at a person. We don’t care about that. It might work better to strip the cam out of the casing that it comes with and use a mirror to direct the cam in the right direction.
From the start, I haven’t liked those wheels. I’m with Super Aardvark. Turn all the wheels 90 degrees, but in addition to that, rotate them further so that their plane of rotation is the same as a diametric plane of the sphere. I guess the wheels aren’t actually that much of an issue though, since the ball never needs to turn its contents.
LikeLike
If anyone ever accomplishes this please post a video of it working on youtube or some were, i would LOVE to see this.
LikeLike
seems to me that an easier way to handle drive/steering would be to have a single drive wheel on the bottom, 3 or 4 casters for support, and use a servo or stepper motor to pivot the drive wheel for steering.
for the vision, ultrasonics would be more ideal because your eeepc could build rough maps based on what the range finder “sees” and it could get color vision from a web cam facing straight up toward a conical mirror. that way the eeepc has omni directional peripheral vision with its conic vision limited to what the ultrasonics see. the mirror assembly would also eliminate the need for rotating the camera, eliminating a source of power drain.
something else to consider would be accelerometers so it knows roughly what speed and direction it’s traveling in.
LikeLike
Another way to solve the turning/camera/wheel problems might be to diverge slightly from the “Hamsterball” idea. It seems like the sphere would need to be in two halves, joined together, in order to get the robot inside. So instead of running small wheels inside, each half itself could be like a giant wheel, with a central axle running through the middle. The robot would hang off of the axle with a separate motor for each side. I’m imagining that if both halves turn the same direction the ball moves that way and if they go opposite directions the ball turns.
If you allow for a small space between the two halves, the camera could be mounted directly onto the robot and stick up out the sphere.
To crudely illustrate with punctuation marks:
(=|’=)
( one half of sphere
= axle, robot, battery, etc
|’ camera-on-a-stick
) other half of sphere
There obviously some trade-offs, but it might be easier to build.
LikeLike
This has been done by UAT (University of Advancing Technology) students, albeit not with an eee PC:
http://www.uact.com/technology/icarus_project.aspx
http://www.uat.edu/whatshappening/default.asp?action=1&id=174&target_month=7&target_year=2005
Check it out. Was at DefCon a few years ago, for their IP-enabled contest. The design was kind of limiting, and the controller is not that great, but it worked, and worked pretty damn well!
LikeLike
This cartoon has attracted the attention of a big Maker site, that has a robot-building contest on the go as I type:
http://www.instructables.com/community/Sweet-robot-idea-in-xkcd/
LikeLike
Okay, that thing is definitely being built now, Kiteman. Cool! 😀
“It seems like the sphere would need to be in two halves, joined together, in order to get the robot inside. ”
For some reason, that made me think “Pokeball”
LikeLike
Adding some kind of weightshifting mechanism would eliminate the need for lateral wheels and reduce the complexity of the drive system. Of course, that means you’d have to try to make it only as stable as necessary to reduce the work done by the weightshifting mechanism for longer battery life. I don’t know exactly how possible it would be (you’d need to have a heavier ball for the necessary rotational inertia, and it wouldn’t be able to turn in place, though a lightweight single-wheel steering thing (rotate within the ball) could come into play for that in place of the mechanum wheels.
LikeLike
I’m getting an Eee PC 900, when I get enough money.
LikeLike
what about embedding a wireless usb hub/adapter in the cam, or wait for a wireless usb cam to come out.
LikeLike
Also, if you are going to make it submergable, I would suggest the possibility of a liquid sensor about two inches or so from the lowest point of the ball, this gives you an early warning if there is a crack.
LikeLike
>> I don?t see how it could spin at all, on any surface. All the wheels are in line with the center of the robot.
> You know, I hadn?t really given that the proper thought. I ran this by a friend who works on mechanum-wheeled robots, and he thinks that at the very least you could spin around an axis that?s through one of the wheels, and he?s pretty sure you could spin around the center.
I may not quite understand Omni/Mecanum wheels properly (I’ve never seen them in action), but with the configuration shown in the comic couldn’t you apply torque to all of the wheels such that they oppose each other to create a net torque about the vertical axis but no net force?
i.e. front wheel drives ‘forward’
rear wheel drives ‘backward’
left wheel drives ‘left’
right wheel drives ‘right’
Result = no net force, counterclockwise net torque about vertical axis (viewed from top)? Or am I way off the mark here?
LikeLike
I’m with greej. Have you considered the OLPC XO? (http://wiki.laptop.org/go/Hardware_specification#Core_electronics) Not only do you get a 6-to-8-hour battery life (in my personal experience), but also better durability, built-in WiFi with diversity reception for longer range, runs Linux and it’s main UI is Python-based. And it’s got a VGA 30fps webcam built in, with a Python wrapper for access to it.
Of course, at 433 mHz clock speed and 256 MB RAM, you’ll probably want to stream your video out to a server somewhere if you want to do any real video processing or cleanup.
On the other hand, the mesh networking possibilities have gotta open up something cool. Can’t you imagine a whole little flock of XO-Balls, y’know, flocking?
LikeLike
>The blueprint in the comic specifies RF. I’m not sure where you’re getting IR.
Oops, righto. Well, I’m getting it from the fact that it was 1 am when I read the comic (where I am, in India). Let’s put that behind us. In the spirit of contrarianism, I retract my previous suggestion of scrapping IR, and instead suggest adding as much IR as possible! Transmitting data by light is so steampunk, and if it worked for my old Palm Pilot, it should work for this little guy.
LikeLike
I propose using separate wheels and motors to move the hamster ball and spin the robot inside of it. This principle could be applied to many wheel configurations, as long as you have at least two motors for locomotion and one for turning.
Other suggestions:
– Allow the robot to go into ‘neutral’ and let the wheels spin freely if the motors can’t keep up with the hamster ball.
– Some kind of sound/laser/RF based device to judge distances.
– Program it to recognize if the camera is detached and stop moving.
LikeLike
I looked at the IMDB top 250 real fast, and got to #40 and found two movies with a woman as a lead. My girlfriend made me stop because it was too depressing.
LikeLike