An Introductory Robot Programming Tutorial
BY http://nursing.au.edu/cart.php?add=lertamine-d-generico-do-viagra how does zetia affect coumadin levels follow site poems essay mla format see follow does kamagra oral jelly work al maximo viagra online https://www.lapressclub.org/hypothesis/live-stream-hillary-speech/29/ phd thesis jobs 12 angry men essays juror 8 kamagra uk sellers https://ramapoforchildren.org/youth/harcourt-help-homework-math/47/ thesis statement in literary essays ntnu phd thesis 2 9 anthracene phenylethenyl reaction essay trans wittig viagra information in hindi source link https://homemods.org/usc/essay-bank/46/ appreciating life essay https://abt.edu/bestsellers/cialis-and-antifungals/22/ long term cialis use ok https://smartfin.org/science/does-viagra-increase-sperm/12/ analysis of looking backward 2000 1887 essay stanford filmbay 381 html cialis davidson follow https://thembl.org/masters/homework-for-3-year-olds/60/ paper on an occurance at owl creek bridge follow site source url NICK MCCREA – SOFTWARE ENGINEER @ TOPTAL. (Original article posted here)
Let’s face it, robots are cool. They’re also going to run the world someday, and hopefully at that time they will take pity on their poor soft fleshy creators (AKA robotics developers) and help us build a space utopia filled with plenty. I’m joking of course, but only sort of.
In my ambition to have some small influence over the matter, I took a course in autonomous robot control theory last year, which culminated in my building a simulator that allowed me to practice control theory on a simple mobile robot.
In this article, I’m going to describe the control scheme of my simulated robot, illustrate how it interacts with its environment and achieves its goals, and discuss some of the fundamental challenges of robotics programming that I encountered along the way.
The Challenge of the Robot: Perception vs. Reality and the Fragility of Control
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. We often see video of the latest research robot in the lab, performing fantastic feats of dexterity, navigation, or teamwork, and we are tempted to ask, “Why isn’t this used in the real world?” Well, next time you see such a video, take a look at how highly-controlled the lab environment is. In most cases, these robots are only able to perform these impressive tasks as long as the environmental conditions remain within the narrow confines of its internal model. Thus, a key to the advancement of robotics is the development of more complex, flexible, and robust models – advancement which is subject to the limits of the available computational resources.
[Side Note: Philosophers and psychologists alike would note that living creatures also suffer from dependence on their own internal perception of what their senses are telling them. Many advances in robotics come from observing living creatures, and seeing how they react to unexpected stimuli. Think about it. What is your internal model of the world? It is different from that of an ant, and that of a fish (hopefully). However, like the ant and the fish, it is likely to oversimplify some realities of the world. When your assumptions about the world are not correct, it can put you at risk of losing control of things. Sometimes we call this “danger.” The same way our little robot struggles to survive against the unknown universe, so do we all. This is a powerful insight for roboticists.]
The Robot Simulator
The simulator I built is written in Python and very cleverly dubbed Sobot Rimulator. You can find v1.0.0 here on GitHub. It does not have a lot of bells and whistles but it is built to do one thing very well: provide an accurate simulation of a robot and give an aspiring roboticist an interface for practicing control robot programming. While it is always better to have a real robot to play with, a good robot simulator is much more accessible, and is a great place to start.
The software simulates a real life research robot called the Khepera III. In theory, the control logic can be loaded into a real Khepera III robot with minimal refactoring, and it will perform the same as the simulated robot. In other words, programming the simulated robot is analogous to programming the real robot. This is critical if the simulator is to be of any use.
In this tutorial, I will be describing the robot control architecture that comes with v1.0.0 of Sobot Rimulator, and providing snippets from the source (with slight modifications for clarity). However I encourage you to dive into the source and mess around. Likewise, please feel free to fork the project and improve it.
The control logic of the robot is constrained to these files:
- the files in the
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.
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
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:
- Apply control signals.
- Measure the results.
- 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. The more times we can do this per second, the finer control we will have over the system. (The Sobot Rimulator robot repeats these steps 20 times per second, but many robots must do this thousands or millions of times per second in order to have adequate control.)
In general, each time our robot takes measurements with its sensors, it uses these measurements to update its internal estimate of the state of the world. It compares this state to a reference value of what it wants the state to be, and calculates the error between the desired state and the actual state. Once this information is known, generating new control signals can be reduced to a problem of minimizing the error.
A Nifty Trick – Simplifying the Model
To control the robot we want to program, we have to send a signal to the left wheel telling it how fast to turn, and a separate signal to the right wheel telling it how fast to turn. Let’s call these signals vL and vR. However, constantly thinking in terms of vL and vR is very cumbersome. Instead of asking, “How fast do we want the left wheel to turn, and how fast do we want the right wheel to turn?” it is more natural to ask, “How fast do we want the robot to move forward, and how fast do we want it to turn, or change its heading?” Let’s call these parameters velocity v and angular velocity ω (a.k.a. omega). It turns out we can base our entire model on v and ω instead of vL and vR, and only once we have determined how we want our programmed robot to move, mathematically transform these two values into vL and vR with which to control the robot. This is known as a unicycle model of control.
Here is the code that implements the final transformation in
supervisor.py. Note that if ω is 0, both wheels will turn at the same speed:
# generate and send the correct commands to the robot def _send_robot_commands( self ): ... v_l, v_r = self._uni_to_diff( v, omega ) self.robot.set_wheel_drive_rates( v_l, v_r ) def _uni_to_diff( self, v, omega ): # v = translational velocity (m/s) # omega = angular velocity (rad/s) R = self.robot_wheel_radius L = self.robot_wheel_base_length v_l = ( (2.0 * v) - (omega*L) ) / (2.0 * R) v_r = ( (2.0 * v) + (omega*L) ) / (2.0 * R) return v_l, v_r