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.
April 22nd, 2008 at 10:34 am
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.
April 22nd, 2008 at 10:36 am
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.
April 22nd, 2008 at 10:38 am
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.
April 22nd, 2008 at 10:45 am
hiiiiiiiiiiiiiiiiiiiiiiiii
kiiiiiiiiiiiiiiiiiiiiiiiisssssssssssssss
tenk you
okeyyyyyyyy
byby
April 22nd, 2008 at 10:51 am
Check out the Swarm project @ http://orbswarm.com/: those guys use the angular momentum of the gear inside the robotic spheres to propel them.
April 22nd, 2008 at 10:55 am
A similar idea was floated here. Perhaps the smaller microcontroller is a better option?
April 22nd, 2008 at 10:55 am
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
April 22nd, 2008 at 11:27 am
Instead of the EEE PC one could use a Fox Board, a complete linux system in less than 7×7cm
April 22nd, 2008 at 11:32 am
> 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.
April 22nd, 2008 at 11:35 am
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…
April 22nd, 2008 at 11:52 am
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.
April 22nd, 2008 at 12:22 pm
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?).
April 22nd, 2008 at 12:45 pm
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.
April 22nd, 2008 at 1:00 pm
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.
April 22nd, 2008 at 1:09 pm
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.
April 22nd, 2008 at 1:19 pm
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.
April 22nd, 2008 at 1:38 pm
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?
April 22nd, 2008 at 1:46 pm
> 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.
April 22nd, 2008 at 1:46 pm
> 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?).
April 22nd, 2008 at 1:55 pm
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.
April 22nd, 2008 at 1:58 pm
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).
April 22nd, 2008 at 2:03 pm
>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.
April 22nd, 2008 at 2:08 pm
http://www.whencloverfieldhit.com/video/view/90
April 22nd, 2008 at 2:13 pm
“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.
April 22nd, 2008 at 2:49 pm
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.
April 22nd, 2008 at 2:55 pm
> 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 :)
April 22nd, 2008 at 3:07 pm
Of course there would be no need to import the soul if you used Lisp.
April 22nd, 2008 at 3:55 pm
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?
April 22nd, 2008 at 4:02 pm
>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!
April 22nd, 2008 at 4:09 pm
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.
April 22nd, 2008 at 4:24 pm
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!
April 22nd, 2008 at 4:32 pm
What are you guys using for your software with these? I’m new at this whole robotics building thing
April 22nd, 2008 at 4:37 pm
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.
April 22nd, 2008 at 5:10 pm
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…
April 22nd, 2008 at 5:14 pm
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.
April 22nd, 2008 at 5:31 pm
If anyone ever accomplishes this please post a video of it working on youtube or some were, i would LOVE to see this.
April 22nd, 2008 at 5:48 pm
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.
April 22nd, 2008 at 6:03 pm
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.
April 22nd, 2008 at 6:09 pm
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!
April 22nd, 2008 at 6:12 pm
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/
April 22nd, 2008 at 6:22 pm
Okay, that thing is definitely being built now, Kiteman. Cool! :-D
“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” o_O
April 22nd, 2008 at 7:14 pm
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.
April 22nd, 2008 at 7:15 pm
I’m getting an Eee PC 900, when I get enough money.
April 22nd, 2008 at 7:48 pm
what about embedding a wireless usb hub/adapter in the cam, or wait for a wireless usb cam to come out.
April 22nd, 2008 at 8:04 pm
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.
April 22nd, 2008 at 8:06 pm
>> 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?
April 22nd, 2008 at 11:01 pm
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?
April 22nd, 2008 at 11:19 pm
>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.
April 23rd, 2008 at 12:53 am
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.
April 23rd, 2008 at 1:22 am
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.
April 23rd, 2008 at 1:45 am
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.
April 23rd, 2008 at 3:23 am
I know nothing about robotics, and this was the best education I think I could ever have received.
Yet again, xkcd fans are made of win.
April 23rd, 2008 at 3:37 am
> 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.
I agree there would be a fair amount of heat produced, but I think that with the thinnish ball shell and huge surface area, along with the fact that it would be moving and thus constantly getting new “cool air” over the whole surface, it wouldn’t be anything to worry about.
April 23rd, 2008 at 4:17 am
[...] Interessant ist die Diskussion zu dem Blog-Eintrag, in dem ne Menge Leute mit Ahnung von Robotik über den Nachbau diskutieren: blog [...]
April 23rd, 2008 at 5:23 am
Er…. with Regard to RobotIQs, wouldn’t it be a lot easier to ReProgram Humans to behave as if Robots [to behave as if, leaves them with/gives them some semblance of fostered respectability and multiple choice to accompany the Perception that they may actually believe that they have a Personal Intelligence which they can use] rather than accept the primitive, random, chaotic, animalistic behaviour which so many of them/most of them exhibit?
Just AI Thought
April 23rd, 2008 at 5:40 am
I think it is best to make the ball opaque. Just imagine how alien it would look : a simple, solid ball, that moves around with no apparent reason, with a camera that somehow always stays on top !
Of course it is possible to have two hulls, one transparent and one opaque, and to change them whenever you like.
April 23rd, 2008 at 6:17 am
How about giving it an IR imaging system on the inside? While the webcam on the outside is kinda cool, it’s the most fragile part of the robot.
April 23rd, 2008 at 7:52 am
I love this stuff, even though i’m not really that savy with programing robots, I’ve tried with poor results. I so read robot blogs, however, and I thought you guys might like this one that NASA is creating for use on Mars, possibly in a “swarm” type format. Let me know what you think!
http://www.botjunkie.com/2008/04/15/orb-swarm-attacks-mars-rover-at-yuris-night-bay-area/
April 23rd, 2008 at 8:15 am
In my opinion the camera is not going to stay on top for long. It would have to wobble with the robot that’s wobbling inside and a magnetic connection either brings a lot of friction for the caster wheels or it will not be strong enough.
So my suggestion I want to add to all the awesome suggestions above is to use more than one cam and use the difference in image for compensation of dirt on the ball. This would also make a nice noise proof parallax algorithm challenge and as someone said be able to measure the speed of the ball more accurately. For extra coolness make the ball opaque to visible but not to IR light.
And rotation could be done with the omniwheels in the Killough setup as described above.
And to make it submersible you could use some kind of flaps or strings of which the ends are a bit weighted. The flaps will then hang down and provide the most thrust when they are on the bottom side of the ball.
April 23rd, 2008 at 8:17 am
But.. the problem would be to control the buoyancy. There would have to be a vent or some kind of deformation of to change the volume of ball. Any ideas for that?
April 23rd, 2008 at 9:33 am
Since all the robotics nerds seem to be here today, does anybody want to make something like this for me? I’m bedridden and it would really be amazing to have a remote-controlled mobile webcam at my disposal! Especially if it had a microphone and speaker deal too - telepresence as far as my WIFI can reach… awesome.
Spending 24/7 in one bed in one room year after year gets unbelievably tedious… and also prevents one doing nifty stuff like hacking together telepresence robots. Another of those little cosmic ironies.
Ricky
April 23rd, 2008 at 9:59 am
Not sure if anyone has mentioned this, but one other pitfall of using the magnetic hold for the camera is the oscillatory response you will get when the robot accelerates.
This response falls with the friction of the bearings/casters and with the weight of the camera.
As i think this, there would be an interesting interaction as you accelerate from a stop as the mass of the camera resists forward acceleration but also as static friction causes the camera to resist not moving forward.
April 23rd, 2008 at 10:22 am
Another thought on how to stabilize the camera. Attach the camera to a collar that sits below the center of mass of the sphere:
0
__)__
/ _M_ \
/ / \ \
| | | |
M \ ___ / M
You could would still use the magnet to maintain center, but this would ad a ton of mass to resist angular changes due to acceleration and static friction
April 23rd, 2008 at 10:23 am
Whitespace eating for the loss :(
April 23rd, 2008 at 10:49 am
There is a robot project like this at the Helsinki University of Technology in Finland.
http://automation.tkk.fi/Rollo
The robot is controlled with an external laptop and its camera is inside the sphere but the concept itself is very similar. Yes, the sphere gets dirty and thereby impairs the quality of the image but with the camera inside the ball the robot is easier to control and more indestructible. A bigger problem, however, is to make the robot roll over an obstacle, for instance a threshold.
April 23rd, 2008 at 11:08 am
Maybe you could use a superconductor and magnet to cause the webcam to float above the sphere. Liquid nitrogen and laptops don’t go well together, unfortunately. Maybe in a few years.
April 23rd, 2008 at 11:31 am
On the magically-staying-on-top magnetic camera:
If the ball was without holes (which sort of contradicts the hamster ball idea, I know), you could use a ventilator to create an air cushion on which the camera unit can ride.
The problem with the oscillatory response mentioned by Brandon Feil still persists, of course.
However, since we’re already talking control systems here, why not put the camera on top of a ‘cap’ which has an actuator configuration mimicking, or rather, mirroring the robot’s own movement on the outside? Designing the controller would probably not be overly easy, though (3 axes for the actuator, 3 inertial sensors, all of which are coupled, I think).
The cap would stay on because of its own weight, and the stabilization would have to come in part from a clever weight distribution (3 small batteries, motors and wheels at the lowermost extremities, to counteract the camera), making it inherently stable, and the rest from the controller.
If you’re having trouble imagining it, think of a spider with a greased bottom sitting on a ball… This might not help, but I thought the mental image was funny.
April 23rd, 2008 at 11:41 am
On cooling the innards:
Making it ‘breathe’ might be a solution. It would require a sophisticated system of cooling tubes, as well as a bellow, and might not be very practical. There would be two phases: Air intake and air expulsion (obviously…). During the intake, cool, fresh air gets sucked into the bellow through the tube system, passing over the components in need of cooling. During expulsion, the air takes the same paths.
This would require a large enough bellow to ensure that the air is actually exchanged, and also to have a large enough volume in which to store heat.
Apologies for the split post.
April 23rd, 2008 at 11:50 am
I completely forgot about the rest of the ball T_T Here I go again…
The breathing system would require something to reduce the air volume that the bellow would be forced to move. Or make the bellow(s) fill out the remaining volume of the ball…
April 23rd, 2008 at 12:04 pm
I know you’re thinking of a DIY system, but there’s an actual spherical robot being developed by Swedish company Rotundus (www.rotundus.se/main.html). Roland Piquepalle has some links on http://www.primidi.com/2005/02/03.htmlhttp://www.primidi.com/2005/02/03.html and New Scientist has an article on http://www.newscientist.com/article.ns?id=dn6932. Youtube has an animation here: http://www.youtube.com/watch?v=kB_esizySdI and a video here: http://www.youtube.com/watch?v=4zXXyqqLy0o
Just thought you’d all like to know. It’s really cool (and no, while Swedish, I’m not affiliated with Rotundus in any way).
April 23rd, 2008 at 12:12 pm
any library you write for this should be called pyson, and you should make the robot solar powered.
April 23rd, 2008 at 12:13 pm
This should be solar powered and any library you write for it should be called pyson.
April 23rd, 2008 at 12:23 pm
oops
April 23rd, 2008 at 12:25 pm
That’s “COUPLE OF”, not “COUPLE”. It’s not an adjective. Your nerd cred just plummeted hard with me :(
April 23rd, 2008 at 12:30 pm
And your nerd credit just plummeted hard with the rest of the internet community (:
April 23rd, 2008 at 1:15 pm
The project reminded me a lot of this:
http://www.cs.cmu.edu/~reshko/PILOT/
Which is very similar to the project Steve Baker posted, but that one was made of LEGO and therefore far superior in every way.
Basically you’d take something like that and just need to incline the three omniwheels to rest squarely against the inside of the ball (perhaps a good opportunity to add a little shock-absorbing suspention?) Drive any two wheels and let the third one idle to move, drive all three and you can rotate the bot inside the ball. Of course, as mentioned, the bot’s relatively high inertia might mean the ball spins instead!
But I see no real challenge putting the camera inside the ball on a dedicated turntable. The camera’s mass is so small compared to the rest, and probably won’t spin that fast, that the unbalanced torque would cause control problems.
A tilt sensor would be a good idea so the bot doesn’t try to flip itself over inside the ball in case the shell gets caught on a low ledge. This might be yet another opportunity to bastardize the Wii Remote.
=Smidge=
April 23rd, 2008 at 1:21 pm
We were talking about this at lunch today and concluded:
A ball made of diamond would not scratch!
4 omni’s on the bottom powered would give perfect motion in any direction, we prototyped this with a VEX kit.
Possible encoder idea: a spinning range finder, optical mouse on the bottom for tracking, and 3 gyro’s for accurate direction.
April 23rd, 2008 at 1:55 pm
First of all, I really like Steve Baker’s parallel cylinders idea. They seem simpler and less prone to part failure.
Secondly, does the camera need to be mounted on the top? I know that gravity does come into play, but I would imagine that there are strong enough magnets available to keep the camera on the side or front. This would keep the center of gravity low, and would lessen the effect of wobble. If you were to put the camera on the side, you could add a second camera to give the robot depth perception (unnecessary? yes - cool? yes). I think this would help in the event that you programmed it to avoid obstacles and calculate speed.
Finally, I don’t think coating the surface of the ball with a frictional surface would affect the performance of the webcam’s base as long as you use good (large, ‘frictionless’) bearings. Also, having an opaque ball with “eyes” rolling around the room would be awesome.
April 23rd, 2008 at 2:33 pm
I’m surprised nobody has suggested this yet. It seems obvious to me.
If the laptop has spare CPU cycles after its image analysis and behaviour plotting, its screen should totally display a cute hamster face!
I’m picturing an inquisitive little animal with a low poly count.
April 23rd, 2008 at 2:54 pm
“I’m surprised nobody has suggested this yet. It seems obvious to me.
If the laptop has spare CPU cycles after its image analysis and behaviour plotting, its screen should totally display a cute hamster face!
I’m picturing an inquisitive little animal with a low poly count.”
And as its screen saver, it should have the Hamster Dance! :-D
recaptcha: Dickinson Duck. Mmm, delicious!
April 23rd, 2008 at 3:03 pm
I wonder if you could include the camera inside a dome which uses a similar mechanism as the camera would have. The dome could be made of a clear material, and as long as it has a base it should be waterproof. I understand it would leave more space for stuff to build up, but easier to clean then a camera lens and it doesn’t pick up as much dirt since it stays on top. Awesome comic btw, doing too much already at the moment, but this would be awesome to make. Maybe once I get some time and money.
April 23rd, 2008 at 3:05 pm
@Little Richie:
Neither would a hamster ball made of Dragonforce ;).
ITS THE HARDEST METAL KNOWN TO MAN!
April 23rd, 2008 at 3:48 pm
May I suggest hydraulics, suede interiors, an xbox 360 and a sweet sound system?
April 23rd, 2008 at 3:51 pm
But how do you get it to blog?
Oh, wait. It’s pretty easy, if you can stand random content.
April 23rd, 2008 at 3:52 pm
Why not make the camera holder its own robot that is programmed to stay on top of the sphere? It would need an accelerometer and a funky stabilizing contraption, like a driven track ball to keep up with the sphere…
April 23rd, 2008 at 4:03 pm
>Why not make the camera holder its own robot that is programmed to stay on top of the sphere? It would need an accelerometer and a funky stabilizing contraption, like a driven track ball to keep up with the sphere…
Yeah, like I said. A magnet (or an arrangement of magnets) could still be used to sense the location relative to the main robot.
April 23rd, 2008 at 4:53 pm
you know, we’re thinking about this camera thing the wrong way. we’re trying to figure out the ideal way to anchor it on the top, with magnetic coupling. i just thought of a much easier way to do it.
place the camera on top of a sort of armature, in the form of arms that are shaped like the ball but stand off of it, and at the bottom of each arm have a caster and either a small weight or a magnet to couple to a ring of magnets hanging inside. if the arms extended, say, 2/3 or 3/4 of the way down the ball, it shouldn’t fall off easily, and the weights/magnets could keep it stable.
for bonus points, a tilt sensor could tell the robot what angle the camera is at so the robot can compensate and doesn’t sway drunkenly due to the swaying camera. the camera could be connected by IR or as another posted suggested, UWB connected and powered by high-frequency RF
April 23rd, 2008 at 5:11 pm
Ditch the camera, go for ultrasonic and infrared sensors. Then you can use something simple like an HC11 or an aTMega for the brain and drastically reduce the cost of the robot. (Oh no, you’d have to write in C or Assembly!) If you want, you could also incorporate bluetooth communication to a PC so you can reprogram its AI on the fly, then you could indeed write in a high level language like Python
April 23rd, 2008 at 5:27 pm
Here’s my take on the robot…
Instead of a small square base for the camera, make a “cap” as I believe someone else mentioned. Make it four or five “octopus arms” and have a rare earth magnet on the tip of each. Put a ball bearing or a few near or around the magnet so that it will prevent friction (possibly out of a plastic or teflon type material so that the magnet doesn’t interfere with the rotation). Inside the ball make an “umbrella” of sorts to match up with the octopus cap on top of the sphere. The closer to the equator of the ball, the more stable the camera should be, in my eyes. In order to make the camera rotate you could use one of the mounts for those USB foam dart launchers they sell on thinkgeek.com (note: I have no affiliation with them. I just like the stuff they sell.) It already has a USB interface too so I’d imagine it should be too hard to modify it to hook to the RF transmitter. Plus it should be able to be utilized by the computer AI.
The bent section of the upright pillar should have a joint or hinge in it so that when you open the ball, the magnets will still hold the camera in place so you, ideally, won’t have to reposition anything just to get at the battery or PC. Also it would probably be a good idea to make a jack on the base so you could hook a wire to the battery to recharge it, rather than pulling it out altogether. Or you could rig up some kind of solar panel on the camera cap and transfer power through the ball via induction and have the robot be fairly self sustaining.
Now for the propulsion system I have a completely different idea. My physics may be off on this one so I apologize ahead of time. Please someone correct me if I’m off. For some reason the first thing that popped into my head while looking at this robot is the old demonstration in physics class for rotational forces. The one where you stand on a ball bearing platform and spin a bike wheel. When you turn the wheel left or right you move in that direction via rotational force. When I did it, I accidentally tilted it forward and almost fell on my face. This popped in my head. If we rig one or more gyros (beneath the umbrella but above the pivot/hinge joint) up with a gear to manipulate the direction of the spinning wheel it should generate a force that would try to topple the base. But since the base should have a low center of gravity, the ball would instead move via the rotational forces. The base could then be supported merely by casters or ball bearings and would remove the need for a complicated wheel system. This should also help keep the structure upright more easily than a friction based wheel assembly.
April 23rd, 2008 at 5:38 pm
Instead of using an eee pc, which is more prone to damage, I really think it would be simpler to use a microctrontroller system like Arduino. The robotics lab at my school uses arduinos-they’re great, they use AVR microcontrollers and you program them in C, and they have nice libraries for I2C, servos, stepper motors, etc. Also, the webcam on the outside’s a bad idea. It’ll be way too complicated to use magnets, that just wouldn’t work. Personally, I would forget the webcam since there’s no way you’re going to be able to do anything with it as a sensor-all it will be useful for is seeing where the robot is.
And as long as you’re using an eee pc, why not just use the webcam built into the laptop? It’s actually pretty good. (I have an eee pc)
April 23rd, 2008 at 6:00 pm
It looks a lot like ICARUS
http://www.uact.com/technology/icarus_project.aspx
April 23rd, 2008 at 6:02 pm
None…
None…
April 23rd, 2008 at 6:28 pm
How about another ball?
If the camera is secured with a strong magnet, you could simply mimic the structure of the whole robot, having the camera in a clear ball, with a low center of gravity. The ball itself would roll, and it would not pick up as much crud, as it wouldn’t be directly touching the ground. Also, it would look the coolest of all these ideas… A moving sphere, with another sphere that always stays on top of it.
April 23rd, 2008 at 8:33 pm
I really like that noone has uttered “Um yeah. But what would the robot be good for?” yet. :)
We just want to __ because we can.
April 23rd, 2008 at 8:34 pm
Great scott. He’s right.
“A moving sphere, with another sphere that always stays on top of it.”
April 23rd, 2008 at 8:40 pm
I’ve seen one a couple of years ago at Helsinki University of Technology (http://www.hut.fi/) It didn’t have a webcam though, and was remote controlled in “xy-plane”, you know what I mean, right? :)
April 23rd, 2008 at 9:49 pm
Let’s face it. You know that fan’s emulate the stuff you draw, like the [citation needed] sign, and the chess-coaster trick. So, you had a great idea: let’s see if I can get them to build a robot. Genius. And the best part is, someone will do it, too.
April 23rd, 2008 at 10:23 pm
How about an R/C car in a ball?
April 24th, 2008 at 12:10 am
Brilliant, each of you.
Regarding Barnabas’ idea for image wobble correction after the fact (even though it’s tangent to the “camera on top” ideal):
If embedding EXIFs in periodic snapshots doesn’t work, you could mount an ‘artificial horizon’ within the camera’s field of view and use it to correct the camera tilt. Just give make its sky contrast strongly with its ground. All the metadata is included in the pixels of the image. No extra space is wasted, and it’s continuous.
Granted, you’re blocking part of your robot’s vision, but with all the tumbling around, you’ll get to see whatever’s behind the artificial horizon in a moment or two…
Now, who’s working on a way to get this thing to climb back up the stairs? I know I’m missing the point of laughing at the poor thing, but c’mon, smug meatbag superiority only goes so far.
April 24th, 2008 at 12:50 am
wouldnt it be easier just to use actual omni wheels?
(http://en.wikipedia.org/wiki/Omni_wheel)
or, alternatively, you would have four ball bearing type contraptions for movement, think like a powered trackball, they could have motors to spin the ball, but the ball could still rotate freely in any direction
(like four miniature versions of the locomotion system in the ballbot
http://www.msl.ri.cmu.edu/projects/ballbot/)
great, now im thinking too much, and i cant go to sleep and im going to fall asleep in class again. i hope youre happy.
April 24th, 2008 at 12:53 am
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.
April 24th, 2008 at 1:36 am
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.
April 24th, 2008 at 2:07 am
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.
April 24th, 2008 at 2:11 am
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.
April 24th, 2008 at 2:26 am
>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 :D :P
April 24th, 2008 at 3:32 am
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.
http://i102.photobucket.com/albums/m84/serujni/spherebotDiagram.jpg
http://i102.photobucket.com/albums/m84/serujni/spherebot3x.jpg
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
April 24th, 2008 at 3:51 am
>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.
April 24th, 2008 at 5:06 am
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.)
April 24th, 2008 at 5:18 am
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?).
April 24th, 2008 at 5:19 am
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.)
April 24th, 2008 at 5:26 am
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.
April 24th, 2008 at 7:30 am
You realize Samus jumps by dropping a bomb underneath her, right?
April 24th, 2008 at 7:53 am
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.
April 24th, 2008 at 8:18 am
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.
April 24th, 2008 at 8:19 am
Excluding a camera setup, what would be the estimated cost of this project?
April 24th, 2008 at 12:44 pm
http://www.uat.edu/technology/icarus_project.aspx
This is the UAT project David was referring to. This has the camera mounted inside the clear acrylic ball.
April 24th, 2008 at 12:59 pm
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
April 24th, 2008 at 5:40 pm
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?
April 24th, 2008 at 6:45 pm
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…
April 24th, 2008 at 6:46 pm
*weighs more then the camera, naturally
April 24th, 2008 at 7:28 pm
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
April 24th, 2008 at 7:33 pm
I agree, a thermal or IR imaging thing from the inside of the ball would be MUCH cooler and is easily done with a modded web cam.
EEEPC+EVDO phone???
Would it need a GPS or Electric compass to keep it oriented?
http://todbot.com/blog/2008/02/18/wiichuck-wii-nunchuck-adapter-available/
could help
April 24th, 2008 at 9:03 pm
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.
April 24th, 2008 at 9:59 pm
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! :P … 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
April 25th, 2008 at 12:33 am
> 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.
April 25th, 2008 at 12:40 am
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.
April 25th, 2008 at 1:46 am
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:
April 25th, 2008 at 4:46 am
How about having the eeepc & apparatus on top of the ball like so?
http://i298.photobucket.com/albums/mm276/alexlol89/newer_pet.jpg
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.
April 25th, 2008 at 4:47 am
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.
April 25th, 2008 at 5:00 am
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…
April 25th, 2008 at 5:08 am
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.
April 25th, 2008 at 6:11 am
Similar thing has been done:
http://www.rotundus.se/main.html
Obviously not with and Asus Eee, which would give extra credit
April 25th, 2008 at 7:13 am
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.
April 25th, 2008 at 11:26 am
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!
April 25th, 2008 at 4:27 pm
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.
April 25th, 2008 at 5:08 pm
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)
April 25th, 2008 at 6:03 pm
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.
April 25th, 2008 at 6:09 pm
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?
April 25th, 2008 at 10:15 pm
Hmmmm.
Anyone think they can incorporate these sweet babies into the design?
http://scienceblogs.com/zooillogix/2008/04/robotic_jellyfish_that_move_au.php?utm_source=readerspicks&utm_medium=link
April 25th, 2008 at 11:13 pm
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
April 26th, 2008 at 12:57 am
@ 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…
Munroe
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)
April 26th, 2008 at 1:20 am
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.
April 26th, 2008 at 2:00 am
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?
namely:
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.
April 26th, 2008 at 4:53 am
@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.)
April 26th, 2008 at 10:00 am
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.
April 26th, 2008 at 1:56 pm
>-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.
April 26th, 2008 at 3:30 pm
@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.)
April 26th, 2008 at 4:09 pm
It might interest you that STEIM in Amsterdam had a project in the early 1990’s called Adelbrecht. Adelbrecht was also an automotive ball. It would detect when it would collide, say “Godverdomme!” (goddammit in Dutch) and then roll in a different direction.
STEIM: http://www.steim.org/steim/
Adelbrecht : http://www.cult-lab.de/priv/Charly/ADELBREC.JPG
I’m a regular visitor at xkcd, keep it up!
All the best,
Rolf
April 26th, 2008 at 4:44 pm
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.)