Hooray robots!

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.

260 thoughts on “Hooray robots!

  1. how about for locomotion, you could have four things like they have on the ballbot (http://www.msl.ri.cmu.edu/projects/ballbot/) like powered trackballs, they can rotate in any direction, and motors could power them. though i suppose omniwheels are easier to make, the ball bearing type thingy works better overall, i think.


  2. Turning is not difficult: make the hamster ball a symmetric hamster ‘egg’ and all the interior stuff has to do is shift its weight from side to side, like lawn bowls. Of course this prevents turning in place, but it simplifies things considerably since you don’t need servos for the camera and you can avoid the mechanum wheels.


  3. In response to fr4ncium, IFI makes three inch omni-directional wheels as a part of their vEx platform. They’re not quite mecanum but they’re incredibly versatile.


  4. Actually, come to think of it, the Vex platform would be perfect for this kind of project. Although the computer that comes with the kit is incredibly slow and lacks the power necessary for something like this.


  5. >I cant imagine you could completely close off the hamster ball enclosure. It would run extremely hot from the motors and circuitry, you would have to have some vents for natural convection since fans would probably be too complicated, and some pretty big vents at that.

    What if you fill the hamster ball with say 50-70 ml of some liquid. I am thinking Isopropyl alcohol. As the eeeHamsterBot runs about it would spread the Isoprop around the inside of the sphere some would drip and land on the eee and motors (you could even put some funky paddles on wheels) this would evaporate and then condense on the inside of the sphere the whole sphere then will radiate the generated heat. The area of a sphere is A = 4 pi r^2 So this would be a Liquid cooled, Explosive filled (oh actually that’s a good point, isoprop vapor air small sparks from the motors could = bad, If you throw in some dry ice to evaporate and purge the air out first may be a good idea [But much less exciting]) eeeHamsterBot utlising maths!! How cool would that be 😀 😛


  6. so I had a similar idea a while ago, it was stilll a bot in a ball but it was mainly going to rotate on one axis and a weight would move side to side to steer, wouldn’t really need to be in a full sphere though. Pretty much what they did with those swarm bots that jason mentioned. Of course i’m way too lazy to actually put my ideas into action so it never would have happened, just like i’ll probably never do this next idea.

    So i’m sure we all remember those multiaxis gyros that the’d have at the fair/amusment park. The ones where they’d strap a guy in the center then spin them in every direction at once. Yeah you know the ones i mean.

    So i figue you could do the SphereBot in pretty much the same way. the way i figure it you only need two axis’ of movement to create omnidirectional travel. And i also solved the getting up the stairs trick. Here’s some diagrams, but there is still much to explain.

    so the first pic basically describes the whole idea, maybe, maybe not, i’m tired. but one thing that isn’t really mentioned is why the weight needs to move vertically, well i guess it doesnt but i thnk it will make the “jumping” easier. One of the major issues with this right now is that there isnt really an appropriate place for a webcam and powering the motors properly would also be an obstacle, though overcommable it will undoubtedly cause headaches.
    So the basic idea with the jumping revolves around physics and gravity being slower than the bot. Ever taken a circular object and weighted one side of it then tried to roll it? You might see what i’m getting at if you have. So the main thing for this to work is the entire bot needs to weigh significantly less than the weight inside it, but not while its inside it. The second picture sorta describes what i’m getting at. if the robot finds an obstacle it rotates the weight towards the obstacle to try to get over it if the obstacle is too high the weight will go all the way to the top, before it makes it past the very top and falls over it should do the following, and very quickly i might add. Rotate the weight back towards the object again, forcing it downwards, if moved fast enough the rest of the bot will basically push off the weight and lift itself off the ground. the movement of the weight on the center axis should allow this to be accomplished faster and with less lateral movement. So the bot should be able to hop up a bit, the overall size of the bot is what determines hopping height most though, I wouldnt expect one to be able to jump more than half its height and even half might be pushing it.
    Some other stuff: it only needs 2 motors though they need to be used in conjunction to create most of the directional movement, and it cant “spin” unless a third ring is added. I dont know if sustained movement in a given direction will cause a self balancing gyro effect that will cause the rings to line up with the direction of movement, or if i just made all that up.

    i’m sure there was some other stuff i wanted to say but i think i want to sleep right now.
    i can be contacted at this email address if somebody has a question or comment that they dont want to share with the rest of the class
    do it doug hotmail com
    though i hardly ever actually check it


  7. >How about another ball?

    Putting the camera in a second sphere would certainly not help prevent it from falling off of the first sphere. It would create a much larger gap between the magnets and be much more difficult to balance.

    However, if it could be done, this would allow for a very interesting behavior:

    The camera could send out a homing signal. In the event that the camera falls off of the main sphere, the sphere could locate the camera and go to it. When they find each-other, the camera could re-attach itself by magnetically rolling up the side of the main sphere. This would require the entire main sphere to be made of something that a magnet can stick to well enough for the camera to climb it. So now your hamster ball is made of solid iron.


  8. I’m absolutely floored that nobody has suggested vents that can push out strong pulses of high-pressure air, for the Metroid jumping ball effect.

    (This would also get it back up the stairs in the most awesome way possible.)


  9. Liquid inside the Ball? I thought Hamster Balls had holes in them, to allow breathing…

    As for the jumping ball effect (I have not played Metroid much, due to not possessing a Gamecube or Wii console), I imagine that it would be quite difficult to achieve due to various reasons. I can expand on why I think so if necessary.

    I agree with LockeZ on that a second ball on top would be quite annoying to stabilize (it is inherently unstable. What is the correct english term for systems which are unstable? Lyapunov-unstable?).


  10. You could also achieve this effect with the guts-mounted-with-pistons approach. You just have to have strong pistons, which can get the guts moving upward at a good clip, and then *stop*.

    (I think. Intuitively, it seems like it should work, but it’s in that area where I feel like Newton might have something dismal to say about it.)


  11. The correct term is, I think, “unstable” :p

    I actually think you could get the sphere-on-sphere arrangement to work, provided the balancing systems for the top ball are agile enough (by which I mean: I don’t think it’s so unstable as to require that such systems would be impossible or cost-prohibitive).

    I know the jump ball effect is hard, mostly because storing enough compressed air for more than one jump is hard, and directing it in a way so it’s useful is hard, and basically everything in the whole endeavor is hard. I’m just surprised nobody had suggested it yet.


  12. A new adjective for houses comes to life: eeeBot accessible. The picture of the bot helter skeltering down the stairs made me think of the problems involved with altitude levels. Or will we restrict the robot to one floor? Special robot elevators?

    The problems I see with the ball-on-top-of-a-ball are that it requires energy even when the robot is standing still (unless I misunderstood the idea completely). Personally, I like inherently stable systems more. Also, the surface of the bot and the surface of the camera ball would have to have material specifics ensuring a relatively high coefficient of friction, flattening to increase contact area (and thus transmissible force, naturally), while maintaining translucency and as little image distorsion as possible. Control of the two spheres is (with fast enough balancing systems) definitely possible, like you said, but the added requirements are probably the killers.

    I’m sorry to sound so negative.


  13. The instability of having the camera mounted on top doesnt seem like it would really work out.

    But what about having a camera on one side of the ball and counterbalancing it with batteries and an RF transmitter on the other side (this would look more like a pair of earmuffs than a spider)? The center of gravity would be greatly lowered, stability would be increased, and you could balance the “earmuffs” using omni/mecanum wheels.


  14. Excluding a camera setup, what would be the estimated cost of this project?


  15. I’ve poked through a number of comments, and tend to agree that the camera outside the ball, while technically challenging, creates a number of design handoffs with the mounting of the camera, weight, CoG, etc.

    Two alternate designs, which deviate from the hamster ball.

    1) Have a RF controlled Helo follow the ball, and it would carry the camera, and provide the “steering” for the ball. Upside: the ball is now sealed and rolling around like a toddler on a sugar high. Downside: flying objects going around the house, hitting objects and organics (i.e. people).

    2) Use the hamster ball idea, but instead of the ball-on-the-ball idea, go with a ball within a ball. The clear acrylic hamster ball is inside a larger, dyson sphere type item, which is sparsly populated with nodes. More of a bucky ball design, but with enough node points to let the thing roll easily. The camera can then be sealed inside the inner ball, giving visibility but sealed from the elements. The inner ball is also protected from damage by the outer ball. It will give a screen effect to the camera, but you can still see through it. The support mechanism for the ball within ball could be shock-mounted and also be fitted with paddles for water usage. More of a universal design,and you are less likely to loose the camera (except if weight exceeds bouyancy.)

    Okay, deviations from the other design, but would be fun


  16. There are lots of plausible suggestions to fix problems with the robot, but I think we should concentrate on making a robot that:
    – Runs off of a laptop inside a hamster ball
    – Uses wheels and motors to drive the ball
    – Is omni-directional, can turn in place, and is not mounted in any way to the actual hamster ball.
    – Requires no human intervention for object avoidance
    – Has a web-cam mounted on top of the ball, using magnets and as small a base as possible. The goal is to use the web cam for navigation/obstacle avoidance. Ultrasound, IR, or whatever could be used, and mounted wherever is most practical, but the goal is to use a web cam.
    I realize that this makes it a lot harder, but the point of this isn’t to make a hamster ball roll, it’s to make a robot hamster like the one depicted in xkcd comic #413.
    What do you all think?


  17. i agree with Jake, some things could be done drastically different, but that would take the fun out of the project :p

    I’m certainly planning to build this thing, providing i can find the ball it goes into. My personal plans involve a lego Killough platform as proposed by steve baker, and a camera that already supports wireless streaming (most likely a linksys, since they’re relatively cheap and look awesome).

    the wobbling seems to me like much less of a problem then it’s made here. Wouldn’t the friction of the wheels and the floor with the ball stop any wobbling? That is providing the base weighs significantly less then the camera ofcourse…


  18. I recommend using Phidgets (www.phidgets.com) for interfacing the laptop to the rest of the hardware. I made a laptop-driven robot before and I used the Phidget Interface Kit 0/16/16. I’m actually seriously considering building this robot. The only problem is that I can’t imagine where I could find a 14 inch diameter clear plastic ball to mount my laptop in (hint: I don’t have an eee pc :). If I do, I will probably build this just for the fun of it since I already have all the other parts I would need. –Peace


  19. Wow. I did not expect so many people to take my comment seriously…

    Anyway, the ball-on-ball idea MIGHT be possible, if the speed of the main ball was kept down, and the magnets connecting the balls were exceptionally strong…

    I don’t know though.

    The camera ball could have a “thing” to determine where it is relative to the center of the main ball, then adjust accordingly.

    And yes, this would require more power, but the coolness factor easily tops the power consumption issue, I find.


  20. Yeah, not sure if the top ball would spin decently to look as awesome as I imagine it to be (depends on the friction between the two balls vs that between the ball and the magnet), but that sounds amazing… Thinking about this though, I can’t help but imagine having a side camera or something with the normal camera setup holding specially designed cups/plates (normal ones, but with magnets in there center, possibly on platform which helps to keep things flat)… Then all we would have to do is set up a connection to our main machine, and have some sort of paths script and we can all have Eee waiters! 😛 … Alright, a bit beyond the scope of what we are going for now and it’s not very practical, but still, having little waiters bring drinks/ snacks to me would be sweet (of course how it gets them is another problem, would need to mod things for that to work… but still cool concept). Also, if you can get a gyroscope going… some sort of device like that would probably help control (less dependence on low gravity to keep everything strait) but still, would use more energy and I’d like to stay as true to the comic as possible.

    As for exceptionally strong magnets, neodymium magnets would work great (trust me, are a pain to take apart, using some for my current project, and they scare me so much now. Can hold together through at least an inch thick wood, I’m using 2/3 inch by 1/2 or something along those lines…) Not sure how the camera would react to having one of those by it though… Weaker magnets would create less problems with the electronics, but be more likely to loose connections


  21. > Wow. I did not expect so many people to take my comment seriously…

    If you think that my suggestion to make the hamster ball out of several-inches-thick cast iron was serious, then I am going to have to give you some bad news.


  22. You could solve a lot of problems by having the wheels stick out through the bottom of the hamster ball. It would not be particularly noticable, and the fact that the hamster ball would not be rolling would allow the camera to be superglued to the top.

    Of course, this defeats all of the practical purposes of having the hamster ball in the first place. But it would still be there to look cool.


  23. Here’s another idea with a similar appearance and function of the robot:
    -Keep the spherical shape of the hamster ball, but instead of completely enclosed, there is a small vertical gap in the plastic dividing the ball into two separate hemispheres.
    -The two hemispheres are connected by a horizontal axle through the center effectively making each hemisphere a wheel.
    -the robotic mechanisms is centered on this axle with a heavy counterweight (possibly the battery) underneath keeping the robot level.
    -The camera sticks up through the small crack on a rod mounted on the robot

    This keeps mostly the same functionality while getting rid of the snags like rotating the camera and turning the robot. The robot will always stay straight up and turning is as easy as rotating the “wheels” in opposite directions. This may defeat the original intention of the hamster ball though..

    I’m not a very good artist so i can’t provide a good drawing, but hopefully my description creates a good mental image. (o:


  24. How about having the eeepc & apparatus on top of the ball like so?

    Naturally, gyroscopes and accelerometers to maintain stability – similar to a Segway. If the eeepc falls off (and stays upright) it can keep going. If internal webcam isn’t high enough resolution/insufficient fps, attached webcam as shown would be required.


  25. The center of mass should be below the plane of the wheels and properly centered. With careful placement of the battery, this shouldn’t be hard.

    To reduce the number of espensive mechanum wheels, you could make the table triangular. To reduce it further, have simple balls without a drive at one or even two corners with a controllable (turning around the leg axis) mechanum wheel at the third.


  26. The camera mounted on top seems to have been deemed completely infeasible, and there are several possibilities for imaging. As mentioned above, probably the best option would be an infrared camera, mounted inside. This would give you the benefit of stability, as well as the ability to have an opaque sphere. In addition, with an infrared camera, tracking a hot target is very simple, so you could easily write a bit of code to make it pick a nearby person and follow them, which would be all manners of cool.
    Thats my two cents…


  27. The eee (I have a 701) is perfect for this on another level that I’m surprised nobody has mentioned yet: it’s remarkably shock resistant. The solid state hard drive gives it some incredible capabilities – at work, I’ve demonstrated these by dropping mine from 2-3 feet up, with nary a stutter or loss of productivity.

    The guys I work with are, for the most part, incredibly jealous and pissed that they spent the money for Dell XPS systems or – in one case – an AirBook.


  28. To maintain the point of the hamster ball, most of it should actually be inside a hamster ball. If that isn’t a consideration, you can do whatever you want. Put it inside an elastic buckyball with a shock-absorbing rotating mounting and let it bounce around.


  29. You clearly have a brilliant and motivated readership; you got over 100 comments for a hamster ball camera.
    Please include diagrams for world peace machines, sexy robot ladies, and calorie-free icecream in subsequent comics so we can use this crowd-wisdom to solve some other important problems!


  30. As far as the Mecanum wheels go: Yes, that layout would work very well, /as long as all the wheels have the same ‘twist’./

    If they all had a left-hand spiral, all four motors turning the wheels ‘outward’, away from the center, would make it spin clockwise; Inward, counterclockwise spin.

    To go ‘North’, the north and south motors would spin as per normal wheels; East and west would spin as to go east. Thus, the ‘side’ wheels would ‘screw’ northward, while the ‘front’ and ‘rear’ wheels would resist the eastward force by trying to ‘screw’ west.

    In fact, this’d be a cool little platform WITHOUT getting into the whole hamster ball discussion, and I’m tempted to work on it alone. BUT if we’re going to go there, let’s discuss the twin-hamster-ball concept.

    There’s a lot of discussion of making the upper hamster ball an active balance system, and dealing with problems therin.

    However, since the second ball will be enclosed, one could skip the entire issue of detrious- resistant casters and instead use ball-bearing contact points instead. Low friction contacts. Then use the originally-proposed internal arm and high-powered magnets to keep the camera, and its containing ball, high atop the drive ball.

    Ballast the drive platform appropriately to keep it upright, of course. If the computer and drive mechanisms are insufficient weight, throw in a few lead slugs as low as possible to help.

    And if it ever DOES do something to whip that camera out of its magnetic grip, install some sort of plaintive-sounding alarm to call for help. After all, this was meant as an electronic pet, so some interaction might be encouraged.


  31. Some people are providing some seriously good ideas for the problems that building a robot like this would face. But, the problem i can see with some of these ‘solutions’ is complexity. Occoms razor comes to mind when i read alot of them, i mean, dont get me wrong, alot of them are really ingenious but their complexity would become their downfall…an air intake system with tubes and a “lung”? Bear in mind there is limited space inside the thing as it is…

    (Apologies for being needlessly overly critical, but still:P)


  32. A possible though on the wheels; not sure if they was covered, as I only skimmed the comments looking for it. If this is a repeat, then my bad.

    When thinking about omni-directional wheels, I thought about something like a scroll ball in a mouse. Set the robot on a ball, with and instead of having the ball spin the sensors like in a mouse, have the sensors spin the ball. A number of smaller spheres could be set around the edge of the robot, so that it touches the outer sphere at enough points to not fall over. The main wheel-ball could spin, go in any direction, and the outer sphere would mirror it’s actions.


  33. Wouldn’t tracks inside the ball be a bit easier, and cheaper, that mechanum wheels?
    It would kinda limit the movement and roll of the ball, but it would be simpler to do, surely?
    Or would it not work?


  34. I am by no means a roboticist, so I dont know how much weight my thoughts will carry, but after reading all of the comments above, and just my own general curiosity, I think of three things:

    1) I think someone already brought this up indirectly, but wouldnt the friction of the wheels opposed to the movement direction create problems? ie: if the wheels are on the X/Y axis (looking down from above), and you want to move along the X axis, then the Y wheels would cause problems, as they are resting on the inner surface.

    Additionally, if there was something to “pick up” the opposing wheels, so moving soley along the x axis or y axis is possible, I dont think it would be possible for it to move at an angle between the wheels (ie: a graph of y=x) because the force of the wheels against the inside of the surface would cause problems (sorry, I have limited physics knowledge, Im sure someone could probably prove what Im saying, if it makes sense)
    — I think someone already brought this up, I would just like to know that I understand the problem properly

    2) I dont know how well image processing is as far as AI technology goes, wouldnt some sort of small radar system be more practical? Obviously if someone is driving it, then a camera is better, but if it is moving on its own, I would think some sort of radar system would be more feasible, but I dont know how easy a computer can process images of obstacles, but a radar could tell exactly how far said object is away from it (I wouldnt know the difference in coding obstacle avoidance with either, but I have to imagine it would be easier to code for a radar than for image processing)

    3) Lastly, obviously this only works if the exterior camera is removed, but wouldnt a non-smooth exterior surface be more ideal? Lets say a faceted surface, so the exterior might look like a (trasparent) soccer ball, covered in pentagons, or even smaller polygonal shapes of some nature, I would think that would assist in traction. If I am visualizing it properly, this would make it so the internal wheels are able to “push” on a smooth surface. (Obviously given that a hardened plastic shell would probably have enough friction for most surfaces, but I think if the facets were small enough, it wouldnt affect the “bumpiness” of the ride in a noticeable manner but potentially limit side to side slippage)

    Just thoughts


  35. @ Eddie
    1) Are you thinking about omni wheels or mecanum wheels (http://en.wikipedia.org/wiki/Mecanum_wheel). I’m not sure I completely understand what you are trying to say, but it sounds like you are suggesting that the wheels are not parallel to each other. From what I can see in Munroe’s drawing they are mecanum wheels, which I imagine to be similar to the second picture on the wikipedia article. If so, they should be able to move in any direction along the x and y (each wheel that is, it’s a combination of the larger wheels movement and the smaller screw shaped wheels movement).

    2) Yes I imagine something like that would be easier… or simpler yet, a map of the area, with the camera only detecting moving obstacles or something. Though I do believe a simpler sensor then a camera would provide more basic object detection, though if possible I’d like to stick with the camera since it’s awesome, also, it’s hard to post pictures taken from a radar, they don’t look as nice… If you have a camera you can have some sort of feed from the robot to it’s own website…
    3) Actually, it would help (more points of contact, etc). But I do not believe the exterior camera would have to be removed. when it goes over the edges would create slight “bumps” but nothing extreme, and as long as the magnets are strong shouldn’t shift it’s actual position.
    And for keeping this simple, I agree… working on a vehicle thing for a competition (RC not automated) and our simplified version of our “simple” idea is still bringing us down to the deadline.
    (I hate the weekends, it means I have to go through two whole days without xkcd comics :P… a well here I go)


  36. You could use a drive system that copies the mechanism in a balled mouse, which would be cheaper/easier to build than mecanum/omni wheels. Mounting 3 of them (120° apart of course) is all one needs for basic propulsion.

    The camera does not need its own drive system, and can float on top of 3 ball bearings. The camera would be “attached” to the arm via a 5-10lb pull rare-earth magnet.


  37. Ok lets get down to facts people.

    I shall ask as I wish ti be replied. Short succinct and to the point.

    Has any unanimous censuses been drawn by either Randall, or the commentors?

    Traction for ball
    mounting of cam external
    cost estimates?
    programming platform
    and/or omni directional wheel manufacturers

    please respond with a simple yes or do, if yes please provide examples.

    Thank you all for your time.


  38. @eddie

    If the design were to use omni wheels instead of mecanum wheels, then there’d be no drag issues at all. Omni wheels are basically big wheels with smaller wheels around the outside, letting them slide sideways.

    Mecanum wheels are similar, but instead of the smaller wheels being at 90 degrees to the big wheel, they’re (optimally) at a 45 degree angle. This way, they can literally screw themselves sideways across a surface.

    With omni wheels, you just drive the motors in the direction you want to go, and anything that isn’t driving in that direction idles. The little sideways wheels let it scoot along just fine.

    Mecanum wheels need a lot more coordination between motors, because their angled rollers mean they resist sideways motion unless driven. However, the upshot is, unless you’re moving at an angle, that means all four motors are putting power into motion, and they aren’t just idling and being dead weight.

    Also, Mecanum wheels have a distinct advantage in that THEY LOOK FRIGGIN’ AWESOME when they’re screwing across the floor sideways. Hit Youtube for ‘Mecanum Wheels’ and also ‘Airtrax forklift’.

    As for something other than the camera… Again, you can’t post ‘Look, live radar feed from my adorable ballbot!’ and expect much awesome. Camera feed as an accessory, perhaps, with primary lidar or sonar sensors might be good, but both of those still might require a mount external to the main ball. I dunno about radar, though; Sure, the ball would be invisible to the radar waves, but I don’t know of any recreational-use radar systems out there. Isn’t there also health risks involved to radar exposure…?

    Third: Personally, I’d avoid a really bumpy ball for various reasons, but if the ball were just plain grippy, or had a really fine texture, that could work well. It’d also help lower the amount of wild spinning on the spot the machine does.

    Use the mag-coupled system initially suggested in the webcomic, but encase the camera (Or lidar, or whatever) inside a second, nontextured, transparent ball, and you could use really low friction ball-bearing contact points on the camera, letting the clear ball spin freely against the textured drive ball.

    That way, by keeping the clear sphere off the ground, you’ll be minimizing surface scratches, so you won’t have to buff or replace it nearly as often as if it were the drive ball, and you won’t have to worry about its less-grippy surface leaving your ballbot twirling helplessly on the spot. Well, not as much.

    I admit, you’d be subject to the grippy ball collecting and depositing crap up against the clear sensor ball, and there’d be some scuffing and wear involved from that, but it’s better than spinning it against the ground directly, and it solves the problem of having the sensor pod’s contact points on the drive sphere needing to be both crud-resistant and low-friction.

    AND it would look awesome.

    (Captcha: Alive Branham. … Better than a dead Branham, I guess.)


  39. While the second ball idea would look awesome, I believe that having the camera in a dome “capsule” with a concave round base with ball bearings would produce a more stable image. Unless the camera is mounted directly the the magnets and has low friction from the rotating ball, wouldn’t this create a tendency for the camera to roll along the edge of the sphere should the robot accelerate/ decelerate. A dome like cap wouldn’t have the camera rolling, it limits the possible directions of motion creating disturbance, and since the dome doesn’t roll the clear material over the camera never touches the main sphere.


  40. >-Keep the spherical shape of the hamster ball, but instead of completely enclosed, there is a small vertical gap in the plastic dividing the ball into two separate hemispheres.
    >-The two hemispheres are connected by a horizontal axle through the center effectively making each hemisphere a wheel.

    I was thinking of this too. And now I want to build one like this.
    The drive system would be pretty simple, 2 independent motors, each one drives a gear that would be fitted to a track that goes around the inside rim of each hemisphere.
    The motors would of course be at the “bottom” of the sphere bot, along with the batteries to keep the center of gravity low.
    You could mount the camera and all other sensors internally, making the outside effectively be a plain sphere with a small gap between the two halves.
    Now imagine a swarm of these.
    Too. Freaking. Cool.


  41. @Kilik:

    The dome cap idea would work, but it’d only solve a single problem: Keeping the camera window pristine. In fact, it’d be identical to the original design, of having the camera exposed, but indexed via magnets. And that would create an issue that the second-sphere camera system could help mitigate.

    If you textured the main drive ball, say by skinning a basketball and applying that rubbery pebbled surface to the main sphere, you would get additional grip on the drive sphere. This would make movement easier and minimize ‘spin in place’ incidents.

    However, if you used the original camera cart idea, or the similar domed cart you’re suggesting, the very small bearing balls rolling over the pebbled surface would create a not-insignificant amount of vibration. This would be exacerbated by the multiple contact points rising and falling off the bumps and dimples in an uncoordinated manner, causing the cart to rotate slightly as well as bounce up and down, creating even more shakes to the video image.

    By encasing the camera in a second ball, however, you’ve gone from multiple small bearings to, in effect, a single very large bearing. The second ball would roll over the small bumps with less difficulty, and with only the single contact point between the two balls, there would be far less rotational jitters, only the linear vibration. And since the second ball would have to be smooth inside and out, the encased camera cart would use ball-on-ball-bearing rollers to contact the inside of its ball, minimizing friction; Combined with the magnetic link to the lower ball’s armature, that would keep it from rolling inside its own ball.

    As for the camera rolling around the outside of the main drive ball, that’s pretty much unavoidable for any passively-balanced ballbots like this one. Whether you’re using a magnetic link to hold the camera in place, using a weighted skirt to passively keep the camera upright, or if you’re sticking to a single clear sphere and putting the camera inside, under all circumstances, you’re going to have the camera bob around a fair bit whenever the machine starts or stops.

    However, if you went the ‘Rolling monolith’ route and put a tower atop a bowling ball and had it actively balance, that’d be a different kettle of fish.

    (Capcha: Botany Value. The jokes write themselves, people.)


  42. Wish there were an edit function. Above: ‘Combined with the magnetic link to the lower ball’s armature, that would keep it from rolling inside its own ball.’

    By this I meant ‘Wildly uncontrollable twirling inside this second sphere’. I do believe that the second sphere should be freely spinning around the camera cart. However, the magnetic connection between camera cart and drive robot would be sufficient to keep the camera fixed relative to the drive robot.

    Back on topic:

    How long can a webcamera, or a webcamera plus lidar unit, plus a VERY short range RF link, run on a small number of batteries? A few LiPoly cells, perhaps? Can electromagnetic induction generate enough power to run the cameras, without killing the main bot’s ballast batteries at a prodigious rate?

    If one were to use this double-ball system, and employ the grippy bottom ball, panning the camera could be done via running the mecanum wheels to twist inside the drive ball. (This does, of course, assume a multi-magnet connection between camera and drive robot, so that the camera is fixed relative to said drive unit.) Or the omni wheels. I’m not picky.

    But what about tilt functions? Would you add weight and power draw, and perhaps additional battery weight, to make the camera tilt itself? Or could you add articulation to that arm that supports the magnetic link (and RF link), so you basically rolled the camera ball/cart forward and back outside the main ball, to look up and down?

    I think this second idea would minimize weight extending above the center of the drive sphere, and also look awesome. Remember that this robot is not meant to cure cancer or handle nuclear waste, it’s meant to be an amusing toy, so looking awesome should be a primary concern. Rule of cool should apply foremost.

    Finally, a long note concerning mecanum wheels vs. omni wheels: After pondering the implementation of both, I thought I should post a ‘Common sense is not common’ statement.

    If one were to use the mecanum wheels as indicated in the initial design, there is a certain programming complexity issue. When mounting the wheels, one only needs to ensure that their axles are arranged in a square pattern, and that they are centered relative to each edge of said square. This way, when driven, they’ll want to climb ‘Up’ the inside of the ball.

    However, because in a Mecanum platform, the wheels turned sideways ALSO need to be driven, a problem arises. The wheels at front and back are turning the sphere as a wheel, and this wheel is the full diameter of the sphere. However the side wheels are turning a much smaller diameter wheel; How much smaller depends on the angle of their inscribed circle to the sphere, relative to the sphere’s center, and to the inscribed circle of the front-back wheels.

    In essence: Since the side wheels are traveling a shorter path to turn the ball the same amount, their sideways-screwing speed needs to be reduced relative to the front/rear rolling speed. Otherwise, a mechanical conflict will arise and the whole rig will roll off at an odd angle.

    The ratio only needs to be calculated once, though, because as long as the sphere’s size, and the layout of the wheels, remains constant, so will the speed ratio. And once this drive ratio constant is programmed into the drive routine, it’ll disappear into the mixers when you start blending translations and rotations. Note of course that using the mecanum wheels to twist around inside the ball needs no ratio.

    Unless you mount the wheels at different heights. Then you’ve got problems, as you’ll have differing ratios between foreward/reverse and side-to-side movement, AND you’ll need to figure out a ratio between the motors for when you want to rotate inside the ball.

    Don’t do that. Mount the wheels at the same height and save me and you both some headaches.

    You could use four (or three) omni-wheels instead. I prefer four, it’s cleaner. You’d need to mount them so their axles are in a + pattern, not a square, to keep the twist capacity, and you’d want to angle them so the wheels are perpendicular to the sphere’s inner surface, but programming will be much easier since the ratio of driving wheels to sideways wheels motor speeds will always be 1:0. IE, front and back wheels idle while left and right wheels drive.

    There will be a torque ratio, as the driving wheels will be following a smaller circle than the maximum diameter of the sphere, but it won’t have any effect on your direction of travel, so it can be ignored in programming. However, it will mean travel speed is greater than wheel speed.

    So, in essence: Mecanum wheels are meant for use on a flat plane, not inside a sphere, unless you like spherical geometry, trignometry, and SPLITTING HEADACHES. Go with the goddamn Omniwheels.

    (Captcha: such zenship. Take this lessen to heart.)


  43. I’d make one, but I’m not familiar with the whole “import soul” bit. Too bad.


Comments are closed.