# TOW - TriOmniWheeler

Holonomic Rover

Here's the latest from BOA-Labs: My first omni-wheeler.

It draws very little from the suggestion here. Most roving robots must turn to face their direction of travel. The plan with this one is that it should be able to move around in 2D space without having to turn to face "forward." It's called "holonomic" motion. It's annoying that so many variations on this have already made it to market. Other omni wheelers have a perceived flaw where they might slide off the sloped roof of your house. Not this one.

Programming it is going to be the entertaining bit. Have barely contemplated it. All ideas welcome.

I have reused the the controller from Harmenszoon. This controller was also used in my first biped. In fact, in modifyig the software to operate continuous rotation servos, I found a glitch in the biped code which may well re-ignite the project.

I'm seriously considering my old Psion Series 5 as a controller because it's got an RS-232 port and its own built-in high-level programming language (OPL). It looks like some clever bugger has already thought of that, although they use a Palm Pilot.

Video

The second video show the first signs of life. You're thinking "Cool, all he has to do it flip it over!" Not just yet. First I have to do the next bit....

The first video is the last video. It "does stuff."

Closeup Pictures

Some pics of the chassis. Here's the underside, showing the arrangement of the three continuous rotation servos.

Detail of the servo mounting.

The Maths

All the maths (discussed later in the threads) boils down to this:

d = SQRT(3)/2 (this also happens to be COS(30). Useful because 30+90 is the relative angle of each wheel to the chassis.

N1 = w - x

N2 = x / 2 - y * d + w

N3 = x / 2 + y * d + w

N1, N2 and N3 are the wheel speeds. w is the angular velocity (it can rotate as it travels).

The Conclusion

It's time to take this one apart for the motors. I wanted to get it to do "something" first, though, so here it is moving around in all the prescribed ways on the floor.

The wheels weren't good - they were too slippy.

The servos in continuous rotation mode were extremely difficult to control accurately for speed.

A pity, really. I will try coating them with liquid latex or something at some point to make 'em more sticky.

Case closed.

## Comment viewing options

Wow, how did you find that Doc BOA?  What an excellent reference !

How about this though?  If you went down to the local hardware store and found the smallest set of drawer handles with a round plastic covering - you could just buy a bunch and mount then around a cylindrical hub !  Or for that matter, the smallest fixed casters (without swivels)

My 45 degree orientation of the casters is not correct in the picture - but I imagine you get my drift - Large & Cheap (just the way I like em)

No special tools required.  The hub could be a ABS plastic pipe sawed and capped.  Boy, this could be fun.

I like your thinking as always, Grog - however, A note; The tiny experience I did get was that discs will work.. but you want cylenders for a controllable slide / an even result - specially if your floor is bumpy!
Yea. Those mecanum wheels (the ones at \$400 per set) have near-cylinrical wheels with sort of bullt-shaped ends so they roll really smooth. You know, when you look at them, you don't see \$400, but when you start dismantling it in your mind, you can see all the manufacturing costs start to mount up.

The cross section of one of those casters would be a rectangle @ 45 degrees and rotated would put it on its edge.

I was looking around for drawer pulls with a cylindrical rotating bead but none seemed very applicable.  I was thinking that maybe a sphere would be better, no matter what the angle the surface friction would be the same - probably a smoother ride too. Plastic beeds are already drilled in the center, but you would have to make the axel assembly etc. - I looked up "fixed ball caster" but did not find much. Ball casters are not usually of the fixed axel variety.

Large casters still seem like they would be fun...

I'm thinking it's time I went down to the car breaker to get a third Nissan Micra windscreen wiper motor.
I loving the design of the robot. I can't wait to see what it looks when you add a microcontroller to it.

Here's some formulas that can be used to calculate the direction and spin of a Killough platform robot like this.

And one robot similar, made for the Trinity Fire Fighting contest.

You know what confused me? The very first formula appears to be a dot product:

pn = v + (b•w)*Fn

...but b and w are scalars! Once I realised that later on there's:

wheel velocity = v•Fn + b*w and r*wn = v•Fn + b*w

then everything became much more clear.

I suppose there's arguably nothing wrong with the in the first formula, but there would have been a lot less confucklement if they had used a *.

It also took me several minutes to figure out that Fn was a vector containing x,y information NOT size and direction information as I had initially assumed.

So, if anyone is still following this, Pn, v and Fn are vectors, b and w are scalars, therefore b*w is scalar. PnFn produces a scalar (dot product of vectors).

If anyone can't remember how to do matrix multiplications, here's an example:

c=ab

a and b are vectors (matrices), c is scalar (just a regular number).

if a = [p q] and b = [m n] then ab = (p * m) + (q * n).

I'll expand the CMU formula in a bit. It's really convenient that the angluar component is a constant: sqrt(3)/2, because it means I don't have to do a sin/cos lookup table!

OKay, this took a couple of days, because I had to go to work to pay the bills and stuff, but, what all this crap boils down to is that if we want to demand a movement from the current location (0,0) to a location (x,y), the three motor speeds are:

N1 = (0 - x) / r

N2 = (x / 2 - y * 0.866) / r

N3 = (x / 2 + y * 0.866) / r

Where 0.866 = SQRT(3)/2 = COS(30) and r is the radius of the wheels.

Haven't quite worked out how far a distance of 1 is or what a speed of 1 equates to, but I don't think it matters as the components are all in the same terms.

There's an additional bit where if we want to robot to rotate, we can supply n angular velocity (w). If we wantt o spin it we also ned to supply the "wheel baseline" (the distance from the centre of teh chassis to the middle of the wheel).This is defined as 'b'.

If we want to add this, the equations for each wheel become:

N1 = (b * w - x) / r

N2 = (x / 2 - y * 0.866 + b * w) / r

N3 = (x / 2 + y * 0.866 + b * w) / r

I'm gonna translate this into integer maths and see if it will work.

This is a LabVIEW program which calculates the wheel velocities given the desired robot velocity in the co-ordinate frame and the angular velocity. I know not many of you read LabVIEW, but this is easy enough to follow.