The Challenge of the Robot

The Challenge of the Robot

The fundamental challenge of all robotics is this: It is impossible to ever know the true state of the environment. A robot can only guess the state of the real world based on measurements returned by its sensors. It can only attempt to change the state of the real world through the application of its control signals.

                           Thus, one of the first steps in control design is to come up with an abstraction of the real world, known as a model, with which to interpret our sensor readings and make decisions. As long as the real world behaves according to the assumptions of the model, we can make good guesses and exert control. As soon as the real world deviates from these assumptions, however, we will no longer be able to make good guesses, and control will be lost. Often, control once lost can never be regained. (Unless some benevolent outside force restores it.)

This is one of the key reasons that robotics programming is so difficult.

A key to the advancement of robotics is the development of more complex, flexible, and robust models.

The Robot Simulator

Robot simulation is an essential tool in every roboticist's toolbox. A well-designed simulator makes it possible to rapidly test algorithms, design robots, perform regression testing, and train AI system using realistic scenarios.

Benefits of simulation

§  Reduce costs involved in robot production;

§  Diagnose source code that controls a particular resource or a mix of resources;

§  Simulate various alternatives without involving physical costs;

§  Robot or components can be tested before implementation;

§  Simulation can be done in stages, beneficial for complex projects;

§  Demonstration of a system to determine if is viable or not;

§  Compatibility with a wide range of programming languages;

§  Shorter delivery times.

Disadvantages of simulation

§  An application can simulate just what it is programmed to simulate – it will not simulate internal or external factors which are overlooked in the development phase;

§  A robot can encounter many more scenarios in the real world than there can be simulated.

New versions of simulation software platforms offer increasingly more features that make simulation easier and also very close to real life. Most simulation tools are compatible with programming languages like C/C++, Perl, Python, Java, LabVIEW, URBI or MATLAB, however they offer broadly varied feature sets depending on their purpose or focus areas.

A list of the known robot simulators are;

1.     Player Project (2D simulator - Stage - 3D simulator - Gazebo - and control interface - open source, part of the ROS project)

2.     MORSE (general purpose indoor/outdoor 3D simulator)

3.     Microsoft Robotics Studio (simulator + control interface)

4.     KiKS (Matlab plugin, only for Khepera + control interface)

5.     MobotSim (for point like robots, more of algorithm implementation )

6.     Karel (Pretty Kiddish, I guess it is Pascal/Logo like)

7.     Peekabot (Looks really cool ! )

8.     MRPT (looks very nice, will try it soon)

9.     Carmen (Robot Vision etc is easy to implement in it (?))

10.   Webots (closed source)

11.    Simbad (2D/3D simulator in Java and Jython)

12.   Robocode (A Java/ .NET suit)

13.   Rossum's Playhouse (C/C++ suit)

14.    V-REP (3D, source available, Lua scripting, APIs for C/C++, Python, Java, Matlab, URBI, 2 physics engines, full kinematic solver, etc.)

Some more generic platforms/middlewares also offer simulation tools:

1.     ROS (currently the largest integration of such platforms)

2.     URBI

3.     YARP

4.     OROCOS

Different capabilities of robots

Every robot comes with different capabilities and control concerns. Let’s get familiar with our simulated robot.

       The first thing to note is that, in this guide, our robot will be an autonomous mobile robot. This means that it will move around in space freely, and that it will do so under its own control. This is in contrast to, say, an RC robot (which is not autonomous) or a factory robot arm (which is not mobile). Our robot must figure out for itself how to achieve it’s goals and survive in its environment, which proves to be a surprisingly difficult challenge for a novice robotics programmer.

Control Inputs - Sensors

There are many different ways a robot may be equipped to monitor its environment. These can include anything from proximity sensors, light sensors, bumpers, cameras, and so forth. In addition, robots may communicate with external sensors that give it information the robot itself cannot directly observe.

       Our robot is equipped with 9 infrared proximity sensors arranged in a “skirt” in every direction. There are more sensors facing the front of the robot than the back, because it is usually more important for the robot to know what is in front of it than what is behind it.

          In addition to the proximity sensors, the robot has a pair of wheel tickers that track how many rotations each wheel has made. One full forward turn of a wheel counts off 2765 ticks. Turns in the opposite direction count backwards.

Control Outputs - Mobility

Some robots move around on legs. Some roll like a ball. Some even slither like a snake.

 Our robot is a differential drive robot, meaning that it rolls around on two wheels. When both wheels turn at the same speed, the robot moves in a straight line. When the wheels move at different speeds, the robot turns. Thus, controlling movement of this robot comes down to properly controlling the rates at which each of these two wheels turn.

API

In Sobot Rimulator, the separation between the robot “computer” and the (simulated) physical world is embodied by the file robot_supervisor_interface.py, which defines the entire API for interacting with the “real world” as such:

·         read_proximity_sensors() returns an array of 9 values in the sensors’ native format

·         read_wheel_encoders() returns an array of 2 values indicating total ticks since start

·         set_wheel_drive_rates( v_l, v_r ) takes two values, in radians-per-second

The Goal

Robots, like people, need purpose in life. The goal of programming this robot will be very simple: it will attempt to make its way to a predetermined goal point. The coordinates of the goal are programmed into the control software before the robot is activated.

     However, to complicate matters, the environment of the robot may be strewn with obstacles. The robot MAY NOT collide with an obstacle on its way to the goal. Therefore, if the robot encounters an obstacle, it will have to find its way around so that it can continue on its way to the goal.

A Simple Model

First, our robot will have a very simple model. It will make many assumptions about the world. Some of the important ones include:

·         the terrain is always flat and even

·         obstacles are never round

·         the wheels never slip

·         nothing is ever going to push the robot around

·         the sensors never fail or give false readings

·         the wheels always turn when they are told to

The Control Loop

A robot is a dynamic system. The state of the robot, the readings of its sensors, and the effects of its control signals, are in constant flux. Controlling the way events play out involves the following three steps:

1.     Apply control signals.

2.     Measure the results.

3.     Generate new control signals calculated to bring us closer to our goal.

These steps are repeated over and over until we have achieved our goal.