Designing an Omnidirectional Mobile Robot Using NI LabVIEW and NI Single-Board RIO

Figure 1. Comparison of Differential Mobile Robot

and Omnidirectional Mobile Robot

"We chose the NI sbRIO-9632XT as the main controller for the

omnidirectional mobile robot for several reasons. It offers high-speed
computing for actuator speed and navigation control. The analog I/O
ports are sufficient for the omnidirectional robot, and the Ethernet ports
make it possible to connect the board to a laptop or PC via LAN
connection. The user can wirelessly access the board from his or her
computer where there is Internet access."
- Wei Kang Tey, Universiti Tecknologi Malaysia

The Challenge:
Developing an autonomous, omnidirectional robot that can replace current differential-driven robots for greater range of motion.

The Solution:
Creating a three-wheeled, omnidirectional mobile robot based on NI Single-Board RIO for instantaneous movement in any
direction at any angle, with or without changing the robots orientation.
Author(s):
Wei Kang Tey - Universiti Tecknologi Malaysia
Che Fai Yeong - Universiti Tecknologi Malaysia
Eileen Su - Universiti Tecknologi Malaysia
The most common autonomous mobile robot uses a differential-driven concept, where two separate motorized wheels propel the robot into motion. When both wheels rotate at the
same speed, the robot moves in a linear motion, either forward or backward. The robot changes direction by rotating each wheel at a different speed. This type of steering has
several disadvantages. First, the wheels can rotate only in a single direction at any one time, limiting the robots navigational capabilities. Second, the robot must change its
orientation to make a turning motion. This increases the complexity in path planning during navigation.
Conversely, an omnidirectional mobile robot uses omniwheels that can simultaneously rotate in two directions for lateral movement. This gives an omnidirectional mobile robot the
added advantage of navigating to any direction without altering its orientation.
Figure 1 shows a right-side parking comparison. A differential-drive robot makes a minimum of four separate movements: forward, backward right, backward left, and reverse. An
omnidirectional robot makes only one direct lateral motion to achieve the same result. In addition, the differential-drive robot requires more space for side parking, compared to the
omnidirectional robot. This example illustrates how an omnidirectional robot offers more economical movement, simplifies trajectories, and reduces time to arrive at a target location.

System Overview and Theory

We designed a three-wheeled omnidirectional mobile robot. To navigate to a desired location, the robot needs orientation feedback from the environment. The APM ArduPilot
gyroscope takes a fine orientation reading and sends the data to the NI sbRIO-9632XT main controller via serial communication.
The robot also needs to know the distance it travels. In this case, two external rotary encoders aligned 90 degrees apart detect the distance traveled in the X and Y directions,
respectively. By plugging the parameters into the navigation formula, the robot calculates the desired speed for the three motors. A proportional integral derivative (PID) controller
controls the motor speed. When the desired speed is sent to the PID controller, the system compares it with the actual speed obtained by reading and processing the data from the
internal encoders mounted on the motors (see Figure 2).

To calculate the desired speed required by those three motors for navigation, we needed a core formula. See Figure 3, where

, and

motors; R is the radius of the omniwheels;

,
, and are the speeds in the X and Y directions and the approach angle of the robot; and
from the reference axis and the distance from the center of the robot to the center of the wheel.

are the angular speeds of the three

and L are the angles of the wheel

The robot can navigate to any direction using the computed resulting vector from the speed of the three motors (see Figure 4).

System Software
The two LabVIEW VIs we used for the robot were the processor VI and the FPGA VI (see Figure 8). The FPGA VI interfaces the controller I/O with the environment changes as
detected by sensors. The FPGA VI has two components: the quadrature encoder interface (QEI) and pulse-width modulation (PWM). Inside the FPGA, we can program a clock pulse
generator using a single-cycle Timed Loop to generate precise 50 MHz clock pulses to trigger the peripherals, such as QEI and PWM.
To interface with the encoders, we can study the patterns of the output pulses from the encoders. By checking the input patterns from the QEA and QEB inputs, we can calculate the
direction of rotation of the encoder (see Figure 5).
Figure 6 shows the layout for processing input signals. We used six flip-flops represented by the blocks labeled DFF. The first four D flip-flops prevent metastability in the QEI blocks.
Metastability is a condition where output hovers between logic 0 and logic 1. It can happen if the input changes too close to the clock edge that triggers the flip-flop. These four DFFs
act as a synchronizer that samples an asynchronous input and then produces an output that meets the setup and hold times as required in a synchronous system.
To drive the motors, we designed a PWM block diagram to interface the main controller with the H-bridge motor drivers (see Figure 7). After receiving the triggered clock pulses from
the clock pulse generator, the PWM counter increases by 1. The system compares the counter to a constant value of 10,000. If it is greater than 10,000, the system resets to zero. By
doing this, the system achieves a constant period of 0.2 ms (equivalent to 5 kHz frequency). The system also compares the counter to a variable named PWM_1 to determine the
duty cycle of the generated PWM pulses. For example, if a 50 percent duty cycle is required, the user sets the value of 5,000 into PWM_1. When the counter is less than PWM_1, the
PWM output pin triggers ON. If the counter value is greater than PWM_1, the pin triggers OFF and generates a simple PWM pulse.

Advantages of NI Hardware and Software

1/8

www.ni.com

We chose the NI sbRIO-9632XT as the main controller for the omnidirectional mobile robot for several reasons. At 400 MHz, with 256 MB nonvolatile storage and 128 MB dynamic
RAM for deterministic control and analysis, this controller offers high-speed computing for actuator speed and navigation control. The analog input and output ports are sufficient for
the omnidirectional robot, and the Ethernet ports make it possible to connect the board to a laptop or PC via local area network (LAN) connection. The user can wirelessly access the
board from his or her own computer where there is Internet access.
An additional advantage to using this controller is that the NI Single-Board RIO controller seamlessly integrates with LabVIEW, which offers functional block diagrams, such as PID
controller and serial communication VIs. We can quickly and effectively implement these VIs because the graphical programming method of LabVIEW makes it easy to design
applications. In the debugging process, LabVIEW gives us a simple, easy-to-use GUI to easily access the main controller. To read data from the controller, LabVIEW provides useful
indicators and graph functions for tuning the PID parameters.
The main controller houses two major components, including the FPGA and the processor. In the FPGA, we programmed several peripherals, including QEI functional blocks and
PWM functional blocks (see Figure 9). The QEI interface is the main display of the distance sensor and the shaft encoder value, including the logic level on each particular pin and
the accumulated pulses from each sensor. The PWM output shows the real-time PWM output pulses on that particular PWM pin.
For navigation, the robot can accurately travel to the desired coordinate with the desired orientation (see Figure 10).
Future Potential
We used NI Single-Board RIO and LabVIEW to successfully create an omnidirectional mobile robot and navigation system. We can navigate the robot in any direction with or without
changing its orientation, surpassing the conventional differential-drive method to propel a mobile robot. Potential applications for this robot are vast and include automated guided
vehicles for transport, commercial automobiles, and even surveillance systems.
Author Information:
Wei Kang Tey
Universiti Tecknologi Malaysia
Universiti Teknologi Malaysia, Skudai Johor
81310
Malaysia
Tel: 0176665417
twk4v@hotmail.com

Figure 1. Comparison of Differential Mobile Robot and Omnidirectional Mobile Robot

2/8

www.ni.com

Figure 2. System Overview

3/8

www.ni.com

Figure 3. Navigation Formula

4/8

www.ni.com

Figure 4. Movements of the Omnidirectional Mobile Robot

Figure 5. Encoder Input Sequences

5/8

www.ni.com

Figure 6. QEI Block Diagram

6/8

www.ni.com

Figure 7. PWM Block Diagram

Figure 8. Core Formula Implemented in LabVIEW

Figure 9. GUI

7/8

www.ni.com

Figure 10. Omnidirectional Mobile Robot

Legal
This case study (this "case study") was developed by a National Instruments ("NI") customer. THIS CASE STUDY IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT
TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE ( http://ni.com/legal/termsofuse/unitedstates/us/).

8/8

www.ni.com