Search Here

MISC
 Parts List
 Robot Forum
 Chat
 Member Pages
 Axon MCU
 Robot Books
 Shop
 Contact

SKILLS
 How To Build
  A Robot
  Tutorial
 Calculators
 Mechanics
 Programming
 Miscellaneous
 Robots
 Space

HARDWARE
 Actuators
 Batteries
 Electronics
 Materials
 Microcontrollers
 Sensors

SCIENCE
 Robot Journals
 Robot Theory
 Conferences

OMNI-WHEEL ROBOT - FUZZY

Omni-Wheels Holonomics 3 Wheels or 4? Control Disadvantages Construction Fuzzy features

What is an Omni-Wheel Robot?
A robot that uses omni-wheels can move in any direction, at any angle, without rotating beforehand. If you want a robot that can straff, use an omni-wheel robot. If you want a robot that can spin while translating forward at the same heading, then you want this type of robot.

Watch the video first!

The Omni-Wheel
So how does a robot that can move omni-directionally work? The trick is that it uses special wheels . . . The omni-wheel is not actually just a single wheel, but many wheels in one. There is the big core wheel, and along the peripheral there are many additional small wheels that have the axis perpendicular to the axis of the core wheel. The core wheel can rotate around its axis like any normal wheel, but now that there are additional wheels perpendicular to it, the core wheel can also move parallel to it's own axis.

Below are a few of the available omni-wheels on the market. The wheel size and diameter are dependent on things like expected robot speed, weight, etc.



You must also be concerned with wheel material. I originally built this omni-wheel robot using omni-wheels made entirely out of plastic - but apparently plastic was too smooth and the wheels were not getting much ground traction. Instead you should make sure the small peripheral wheels are made out of some high traction material, such as rubber or polyurethane. After realizing this mistake and getting new high traction wheels, the results greatly improved by several orders of magnitude. I used this omni wheel for my robot.

Omni-wheels also make great castor wheels. If you are interested in calculating what wheel diameter is best, you should read the tutorial on robot dynamics.

Holonomic vs Non-Holonomic Robots
There are only two types of mobile robots, holonomic robots and non-holonomic robots. Non-holonomic robots are ones that cannot instantaneously move in any direction, such as a car. This type of robot has to perform a set of motions to change heading. For example, if you want your car to move sideways, you must perform a complex 'parallel parking' motion. For the car to turn, you must rotate the wheels and drive forward. This type of robot would have '1.5' degrees of freedom, meaning that it can move in both the X and Y direction, but requires complex motions to achieve the X direction.



A holonomic robot however can instantaneously move in any direction. It does not need to do any complex motions to achieve a particular heading. This type of robot would have 2 degrees of freedom in that it can move in both the X and Y plane freely. A robot arm typically is omni-directly too, with many more degrees of freedom.



Now here is a question for you. Is my Taurus 2 robot holonomic or non-holonomic? To be honest, I am not entirely sure myself. It can move in any direction almost instantaneously - I say almost because there is the small delay time it takes for the wheels to change angles. Perhaps '1.75' DOF? Anyways . . .

3 Wheels vs 4 Wheels
Most omni-wheel robots consist of a triangular platform and three wheels. But it is possible, and often better, to use four wheels. There is only one good reason why three wheels are better - three wheels and three motors are cheaper than four of each.

There is however a problem inherent with four wheel vehicles, and that is the fact that four points are not guaranteed to be on the same plane. Three points are. If your four wheeled robot encounters uneven terrain, there is a good chance that one of those wheels will not be in contact with the ground - holy squirrels! But there are many simple solutions to this. My four wheeled Taurus 2 uses a rocker-bogey system. Cars use spring shocks. My omni-wheel design used a thin flexible aluminum base on which the servos were mounted, able to bend and flex with the terrain.

But I would argue that, with the exception of cost and a small increase in complexity, four wheel designs are better.

Firstly, four wheels are more efficient. With a three wheel design, it is impossible to get 100% efficiency from its wheels. This is because in three wheel designs, no more than one wheel will ever be aligned with the direction of motion. But with four, two wheels can move at 100% efficiency, while the other two remain idle, for full speed more efficient motion. All other angles will also be more efficient than with a three-wheeled omni-wheel robot.



As you can see, in the four wheel design, two wheels are rotating and contributing 100% to motion, while the other two are not moving at all and acting as castors. For this reason, a four-wheeled omni-wheel robot is faster, while using as much or less motor energy.

The other main reason why four wheels are easier is for computational reasons. Four wheels are at 90 degrees to each other, while three wheels are at 120 degree angles. What does this mean? Four wheel designs have wheels directly opposite of each other, meaning a pair of wheels just needs a single calculation, with one wheel receiving a negative number while the other positive. Three wheel designs have no wheel pairs, meaning three calculations are required.

Control of an Omni Wheel Robot
For an omni-wheel robot to translate at a particular angle, each wheel must rotate at a particular rotational velocity and direction. Since the robot is moving at angles, it will need to do trigonometric calculations to determine these wheel speeds. However trigonometric calculations are not always possible, since control of an omni-wheel robot very much depends on your robots computational processing ability. If you are using a PC or palmpilot as the robot controller, your robot could do thousands of trig calculations per second. However most microcontrollers cannot. A microcontroller (such as a PIC or AVR), not doing anything else, can do about three trig calculations per second. But unfortunately your robot also needs to read from sensors, drive servos, interpret data, and many other things. Instead, you will need to use what is called a trigonometric lookup table. Basically you do the trig calculations before hand and save them in memory, and the program just references a list. It wont be 100% accurate, or as elegant in code, but it will be much much faster - its a balance of speed and accuracy. An accuracy within 10 degrees worked fairly well.

As for position control, this is impossible with an omni-wheel robot. The omni-wheel works on the basis of wheel slippage, so using things like encoders for position will not work. You must have the robot detect it's surroundings to track its motion accurately - IMU's, gyros, visual tracking, etc. will work.

Optimization of actuator control is a little complicated. There are several things you need to consider:


Angle control. For an omni-wheel robot to translate at a certain angle, each motor needs to go at a certain speed with relation to the others. The speed doesnt matter, just the ratios.

Motor speed. The faster the motors go, the faster the robot goes.

Rotational control. For an omni-wheel robot to rotate at some particular speed, it must add or subtract equally from the motor speed of each motor.

Maximum motor speed. Motors can only go so fast, so when you do ratios, and rotational control additions, you must make sure that you are not commanding a motor to go faster than it can.

Global angle. You may or may not want to control for the angle of the robot to it's surroundings.

So how do you do this? Well you do these calculations in this order:

1) Calculate motor ratios to determine translation angle. Do this using the trig lookup tables.

2) Calculate rotational velocity constant. Just add or subtract some constant to the translation motor speeds to rotate clockwise or counterclockwise.

3) Check and correct to make sure maximum motor speed isnt exceeded. Suppose maximum speed is 100, but your four-wheel calculations call for motor speeds at 50, -50, -110, and 110. Well the ratio is 50/-50/-110/110. It must be X/-X/-100/100, with an unknown X value, based on a maximum speed of 100. Using algebra, your equation then becomes:

50/110 = X/100
X = 45.45 =~46

The motor speeds become 46/-46/-100/100.

Again, this calculation is more difficult for a three-wheeled omni-wheel robot, but the calculation can be done in the same manner. You can also slow the robot down by changing the maximum velocity in software.

Disadvantages of Omni Wheel Drive
There are unfortunately several disadvantages to omni-wheel drive. Omni-wheels have poor efficiency because not all wheels rotate in the direction of robot movement. There are high losses from friction too. Position control will not work because of high slip. And there is the high computational loss by calculating angles with trigonometry.

Construction Steps to Building an Omni-Wheel Robot
If you would like to have your own four-wheeled omni-wheel robot, the below images show typically how to construct one.

Firstly, this is how I attached the omni-wheel to my servos. I drilled holes into the wheel, and attached the servo horn with screws:



Below are the images taken during production, helpful if you wish to build a similar omni-wheel robot of your own. Note that the white plating is HDPE and the metal is thin sheets of aluminum. I used long spacers to connect the top and bottom. I used two 6V NiMH batteries, one to power motors, the other to power sensors and the microcontroller.

As also seen in the video, the last two images are modifications I made for the CMU MOBOT line following competition. The big giant fan was used to blow away dust that kept mysteriously clogging up the IR sensors. Three omni-wheels were removed because they couldn't scale the large cracks in the cement on the competition course, 2 large foam wheels were added, and the last one was kept as a castor wheel.

Additional Features on Fuzzy (the Robot)
(unrelated to omni-wheel robots, but still interesting)
Fuzzy, for fuzzy logic, was my first attempt towards a robot with AI. I basically reasoned the more sensors I had on the robot, the more 'intelligent' the decisions it could make. I was going to give it a set of 'emotions':

tired: slow speed
bored: randomly activate other emotions
afraid: hide, avoid things that move
claustrophobic: stay out in lighted, open areas
hungry: low battery alert, be more efficient
wanderlust: explore a lot
frustration: try something new to acheive a goal

Sensors Used
Three scanning Sharp IR rangefinders mapped everything in front of it. 2D Mapping was done at 180 degrees, picking up objects at a distance of up to 20ft, and with an update rate of 3Hz. It successfully made intelligent navigation decisions, as seen in the video. It can identify all objects, and the size of the objects, in front of it to determine if there is enough room between objects to pass through or if it must go around.

Three sonar, used mainly as bumper sensors to compliment the Sharp IR. It was my first time using sonar, so it was a good educational experiment. Looking back, I think two wide angle sonar would have been more than sufficient though.

Two infrared emitter detector pairs were used for the line following modification.

The results of the experiment? Well, lets just say the PIC16F877 doesnt have enough memory to do AI. It ran out of memory after programming most of the sensor's into it. I had plans for a digital compass and photoresistors too, but that didnt work out. It did mapping, did intelligent obstacle avoidance, could do all of its movements properly, etc. But sadly, no emotions.

Source Code:
PIC 16F877 source code for omni-wheel robots
note: there is a minor uncorrected bug for motion planning that I never got around to fixing

Get Your Ad Here