Let's Make Robots!

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.


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

Select your preferred way to display the comments and click "Save settings" to activate your changes.

OKay, I'm starting to think servos are not the way forward with this. I can't seem to get much resolution on the speed of my continuous rotation servos.

I've observed that full speed one way is given by a pulse width of 1564us. Full speed the other way is 1436us. I just can get a decent range of speeds from my servos.

It takes a good 25us to perform the PWM comparison, so that makes for a resolutoin of about 5 forward and 5 reverse speeds. I was hoping for more like 30!!

Has anyone got a mechanism for finely controlling the speed of a continuous rotation servo?

The Seattle Robotics Society says here that the approach used to control the position of a standard servo (varying the "on" time of the pulse) cannot be done very finely in software and I'm in starting to agree. They go on to describe how more sucess can be obtained by varying the length of teh "off" pulse. this seems counter-intuitive, but the writer speaks authoritatively.

Has anyone seen this done? I'm thinking of moving to bigger rotational motors. Which means a horrible smelly messy speed controller. Yuck.


Not sure if this will work but if you say you have 2 speed settings that you can use from the standard PWM then maybe you can interpolate between them by switching between them according to the ratio you want. For instance like (SPEED 1, SPEED 2, SPEED 1, ...) should give a setting somewhere halfway between SPEED 1 and SPEED 2, and (SPEED 1, SPEED 1, SPEED 2, SPEED 1, SPEED 1, SPEED 2, ...) should give a setting somewhere about SPEED1 + 1/3*(SPEED 2 - SPEED 1) 

Did that make any sense? Of course this will eat more clock cycles so maybe it won't do any good at all.


SPEED1, etc. means nothing to me. I see what you mean, though. Chopping between speed 1 and speed 2 would give a halfway house. I hadn't considered it because on a regular servo that would produce a really bumpy movement and holding signal. However, on a continuous rotation servo, it might work. Unfortunately now I'm committed to a DC motor solution. I think I've taken servos about as far as I can.

Hey BOA, I have found that continuous rotation servos are hopeless for fine control. I have found that even the stop position changes with temperature. My recommendation is to remove the control circuits and drive the motors with "H" bridges and PWM. LM293's perhaps?
Yeah. I have a couple of LM298s, but if I'm going to use them, I'm switching to beefier motors.
Or, if you want to be reeeeeeaaaaaly exact: use steppers ther is a few boards out there, that translate pwm into a signal that stepper motors understand (please don't ask me where you can get those, I just know that they exist and they are out there), but steppers are also reeeeeeeeeaaaaly expensive (and hard to code if you don't want to use a "translator-board", and they suck a lot of current


Stepper motors driver and software is dead easy. I did one for this. You're right about the price of the steppers themselves, though AND the pigging big battery.

This is such crative way of making a robot move, I am really looking forward to see the results of this project

For inspiration not de-motivation


See BOA, your holding the torch of DIY  possibilities !

That is if you can complete your project for under $50,000 :D

I have to say, I like Fritsy's approach, but How hard could it be to copy this design? I'm thinking a bit of U-section aluminium and a cylidrical shaft. Turn down a couple of rollers onthe lathe... Boom. My target would be to knock them out for about $40 for a set of four.