Omniwheel Prototype 2

I made a second prototype for the omniwheel. The point was to test out a few things:

• Geared hub using http://www.thingiverse.com/thing:3575 instead of Inkscape gear render
• Tighter, more closed channel for the steel wire
• Longer beads
• Tires

The knurled shaft on these smaller set of motors is pretty long, so I made the gear the full length of that. That helps keep the fit straight. I will be increasing the channel length of the other press fit gears I print from now on, so that getting them straight isn't a matter of skill with the mallet or arbor press.

The 'tires' are made from inside-outed waterproof heat shrink. The inside is tackier, but you can only inside-out small pieces at a time. The adherence isn't great unless you get the plastic just melty enough to conform to the tire without collapsing/deforming. You have to hand carve away the excess. Not a good method. I've ordered some 'silicone heat shrink' on eBay that will arrive in November; hopefully that product is different than this one. This could work great for beads with larger surface area if it came with the tacky side out.

Previously I had tried Rustoleum Flexible Rubber, but the droplets were far too big and the whole thing ended up being a globby mess. FlexiDip sprayed on nicer with a fine droplet mist but it wasn't all that rubbery. Plastidip seemed similar but a little thinner (more solvent per less payload) but this needs more testing.

Here's a picture of my second desk. HobbyKing batteries arrived today and actually seem like a good fit and weight for my cart robot design. I've already redesigned the cart gearing system, so all that remains to be done for the cart live demo is to figure out a the small gear press fit going on sideways problem, and to resize and refine the motor mounts.

Omni Wheel Prototype

There was a plan this week to give a very small talk about my robot to a very small group of people. Then it grew into a much bigger event--university departmental computer science talk. Suffice to say, now I'm pretty amped up as well as reasonably nervous.

All this required me to think very hard about what I've been doing, what sets it apart, why it is useful, and to whom. And one thing that came out of that was me realizing that some omnidirectional wheels need to be part of my framework because some users in my talk audience will need them. Existing omnidirectional wheel designs on the web didn't fit my design principles and needs very well. So I designed the one below.

With beads assembled

Frame only

The key things about this design are as follows:

• It only requires one piece of hardware--some wire. I have some 16 or so gauge steel wire, but you can pick anything that feels right to you for your size of wheel, and input those dimensions into the OpenSCAD file.
• Everything can be changed easily in the OpenSCAD file. Number of beads, shape and size of the bead, gauge of the wire, etc. This will be more true after some cleanup on my part, when I get it ready for release on Thingiverse and elsewhere.
• Everything besides the steel wire is 3d printed. It is often easier to 3d print beads than to find beads that fit the wire closely.
• The 3d print does not have to be split in two in order to print. Assembly is simple and doesn't require any 'finicky steps.'
• This is because the channel for the wire is opened up, specifically at the point where printing more of the channel would break the 45 degree rule of thumb for 3d printing. It has a snap-in kind of feel.
• Hot glue can be used optionally to help tack down the wire where needed.
• The wheel hub/gear module will be added on top in the final version without any fuss. To illustrate how this can be a problem with other designs, consider the version where an enclosed channel is created by printing the wheel in halves split along the central X-Y plane of the wheel. In order to not break the 45 degree rule, you have to print the inside faces up. In order to print the wheel hub though, you need at least one outside face up. (My solution in that case would have been a triangular channel).

I'd like to come up with a few more variations on this, and maybe tackle a similarly informed design for Mecanum wheels or two-layered omni wheels.

Here's a first 3d print. The beads will be spray coated with Flexible Rubber, a product sold mostly for sealing up cars and boats. They'll be loaded on a skewer and finished in bulk, which is an important point when you have this many parts to finish. This will also make it more feasible for me to spend the time to apply multiple layers, to get a good thick rubber tire on each.

Looking good--only minor design changes and a little finishing work is needed for this particular mix of the OpenSCAD parameters to be more than a demonstration prototype.

Oh, and I should mention: this wheel cost about 63 cents! That's 60 cents of 3d printed plastic and a few cents worth of steel wire. The wheel is 6cm in diameter.

Robot Cart Progress -- It Drives!

First assembled prototype. Preliminary tests show that (a) it is capable of driving smoothly and (b) it doesn't draw too much current for the L298 motor driver. Spent yesterday evening hunting down flyback diodes at Sector and I even found two additional L298s, as well as a handful of extra large breadboard-compatible tactile switches (pictured left, in the background).

The Wixel code for the transmitter is done. Next up is integrating the PWM code to the receiver modules, and creating easy to use skeleton code for competition participants to come in and edit.

I still need to get additional batteries, a suitable USB camera with a good wide angle of view and OpenCV compatible drivers, and a few other parts. So far so good though.

Edit: Minor Setbacks
I bought these batteries from Adafruit and these batteries from Sparkfun. The Sparkfun batteries provide enough current to get the cart moving, but if it hits any obstacle and stalls, this triggers the overcurrent protection. Toggling the power on and off resets this protection. The Adafruit batteries can't even run the motors unloaded (wheels not in contact with the ground). They twitch, then die out (presumably, overcurrent protection). This is a shame, because I purchased them on the assumption that they would provide a maximum continuous 2C discharge rate, which they aren't, as far as I can tell. The datasheet seems to say that (bad formatting on it makes it hard to read).

In any case, Sparkfun's comment system and tendency to better document products on the page makes me feel a lot better about purchasing from them when they have the stock I want. Unfortunately neither battery will quite do for my needs, so I need to go back and rethink this.

Also, I wasn't able for whatever reason to get the wixel-pwm library by dpark83 working for me. It isn't particularly well commented which makes it difficult to use. I did find this simpler code, which works well enough for me to use instead.

Since the price for these robots is already quite high, I'm going to try and re-use some parts around Sector. Namely, a bin of old cheap lithium ion batteries without any protection circuits, and a bunch of scrapped prototypes for a battery board that has no documentation, but a ton of features (presumably). Or, in the interest of time, skip the reverse-engineering on the battery boards, and just triple check to make my circuits don't look too explode-y, and go protection-less. So far I haven't made any really serious mistakes with my wiring prototypes...

Robot platform in progress

Entire post got deleted while I tried to fix the alignment between the photos shown below. The Blogger WYSIWYG (what you see is what you get) editor is terrible for images, column layouts, etc. In short: I've been working on a lot of things recently, but haven't posted because posting takes time and effort and you need to get good photos of stuff and find a good stopping off point on those projects that never end.

The biggest thing I'm working on now is a robot platform that will be open source. The brain will be the Wixel and the cost will probably be in the $50-$60 to build it yourself. The gear/wheel/mounts prototype are shown below. To give you a sense of scale, the wheels are 9cm diameter and in the assembly shown below, the distance from the wheel to the motor terminals is about 7cm. The first goal for these will be to build seven of them myself and use them to run some fun programming competition aimed at adults/experienced programmers at Sector 67. Past that, I'll probably use these with an Arduino (in addition to, not instead of the Wixel) if I teach a robotics class this summer again.