ni casestudy mobile robot tricycle / omnidirectional

7/21/2019 NI CaseStudy Mobile Robot Tricycle / Omnidirectional

1/81/8 www.ni.c

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

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 main controller via serial communication.sbRIO-9632XT

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 are the angular speeds of the three

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 and L are the angles of the wheel

from the reference axis and the distance from the center of the robot to the center 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 VIs we used for the robot were the processor VI and the VI (see Figure 8). The FPGA VI interfaces the controller I/O with the environment changes asLabVIEW FPGA

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

"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 LANconnection. 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.

Figure 1. Comparison of Differential Mobile Robot

and Omnidirectional Mobile Robot
http://sine.ni.com/nips/cds/view/p/lang/en/nid/205899http://www.ni.com/labview/i/http://www.ni.com/fpga/http://www.ni.com/fpga/http://www.ni.com/labview/i/http://sine.ni.com/nips/cds/view/p/lang/en/nid/205899


2/8


3/83/8 www.ni.c

Figure 2. System Overview


4/84/8 www.ni.c

Figure 3. Navigation Formula


5/85/8 www.ni.c

Figure 4. Movements of the Omnidirectional Mobile Robot

Figure 5. Encoder Input Sequences


6/86/8 www.ni.c

Figure 6. QEI Block Diagram


7/87/8 www.ni.c

Figure 7. PWM Block Diagram

Figure 8. Core Formula Implemented in LabVIEW

Figure 9. GUI


8/8

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/
http://ni.com/legal/termsofuse/unitedstates/us/http://ni.com/legal/termsofuse/unitedstates/us/

ni casestudy mobile robot tricycle / omnidirectional

Documents