M.tech EST LabVIEW based file of robotics

1. EXPERIMENT 13
AIM:
To study and design the implementation of Robotic Simulator: Goalkeeper.
Apparatus Used:
Microsoft Windows XP, Professional Version 2002, Intel® Pentium® Dual CPU. E2180 @2.00
GHz, 2.00 GHz, 199 GB of RAM, Lab VIEW Robotics 2011 SP1
Theory:
LabVIEW (short for The Laboratory Virtual Instrumentation Engineering Workbench) is a platform
and development environment for a visual programming language from National Instruments in
which you create programs using a graphical natation (connecting functional nodes via wires through
which data flows), in this regard, it differs from traditional programming languages like C, C++, or
Java in which you program with text. However LabVIEW is much more than a programming
language. It is an interactive program development and execution system designed for people, like
scientists and engineers, who need to program as part of their jobs. The LabVIEW development
environment works on computers running Windows, Mac OS X, or Linux. LabVIEW can create
programs that run on those platforms, as well as Microsoft Pocket PC Microsoft windows CE, Palm
OS, and a variety of embedded platforms, including Field Programmable Gate Arrays (FPGAs),
Digital Signal Processors (DSP), and Microprocessors.
Procedure:
Execution is determined by the structure of a graphical block diagram on which the programmer
connects different function nodes by drawing wires. These wires propagate variables and any node
can execute as soon as all its input data become available. LabVIEW ties the creation of user
interface (front panels) into the development cycle. LabVIEW programs/subroutines are called
virtual instruments (VIs). Each VI has three components; a block diagram, a front panel, and a
connector panel. The last is used to represent the VI in the block diagram of other, calling VI.
Controls and indicators on the front panel allow an operator to input data into or extract data from a
running virtual instrument. However, the front panel can also serve as a programmatic interface.
Thus a VI can either be run as a program, with the front panel serving as a user interface, or when
dropped as a node onto the block diagram, the font panel defines the inputs and outputs for the given
node through the connector pane. This implies each VI can be easily tested before being embedded
as a subroutine into a larger program. The graphical approach also allows non-programmers to build
programs simply by dragging and dropping virtual representation of lab equipment with which they
are already familiar.

2. Execution of VI’s and Sub –VI’s:
Main VI:
 Create Manifest File.vi—Generates Goalkeeper.xml using the VIs on the Offline
Configuration palette.
 Goalkeeper.vi—Serves as the master simulation VI of this example.
 Goalkeeper.xml—Serves as the manifest file for the environment of this example.
When simulation starts, user can set the shooting direction and click shoot button. The ball
will be kicked to the left side of ground. Through reading distance and angle data from
simulated LIDAR sensor, the Starter Kit 1.0 can get the real time position of ball and move to
the right direction every 10 ms.

3. Block Diagram:
Sub VIs:
Create Manifest File:

4. Block Diagram:
Algorithms:
Check Obstacle:
This VI differs the ball from walls. If the calculated position of candidate obstacle is out of the
ground then it is part of the wall, else, it is the ball.
Robot position: position (x, y, z) of the robot.
Distance: distance of current candidate obstacle.

5. Block Diagram:
Guard:
The closest "ball obstacle" and its angle.
This VI read the current LIDAR data and output the correct velocity for goalkeeper.
Obstacle distances (m): the magnitude array from LIDAR sensor.
Obstacle angles (rad): the direction array from LIDAR sensor.
Robot position: position (x, y, z) of the robot.

6. Block Diagram:
Move robot in the direction of the ball with velocity proportional to angle away from center.
Result:
Cooperative Robotics is a fast developing field, with applications to areas such as building
surveillance, transportation of large objects, air and under water pollution monitoring, forest fire
detection, transportation systems, and rescue after large scale disaster. In short, a population of
cooperative robots behaves like a “distributed” robot to accomplish tasks that would be difficult, if
not impossible, for a single robot. Many reasons can be learned from the fast developing multi-agent
systems field of artificial intelligence concerning relevant topics for cooperative robotics, such as
distributed continual planning, task allocation, and communication language or coordination
mechanisms.
The base setup used to model the GK task was explained, including all the environment, action and
task models. The experimental setups used to compare the GK task performance in different
situations were described, including the differences from the base setup for each model as well as the
differences in the stochastic transition ring rates. Finally, in this section we will present all the
analysis results of the GK task performance for each one of the experimental setups. The initial
predicate state is the same for all the analysis setup and it is defined, with the GK initial position in
the own goal and the ball starting away from the goal.
Precaution:
 To avoid hanging the user interface with front panel locking, configure all events you want a VI
to handle in a single Event structure or always make sure there is only one Event structure in a
loop.
 Additionally, make sure there is always an Event structure available to handle events as they
occur.