Robots are machines endowed with the information processing, sensing, and motor abilities. Information processing takes notably the form of perception, reasoning, planning, and learning, in addition to feedback signal processing and control in the robotic systems. The coordinated exercise of these abilities enable robotic systems to achieve adaptive behaviors and goal-oriented. The communication technologies enable robots to access networks of the software agents hosted by computer systems and other robotic. New generations of the robots are becoming increasingly proficient in coordinating their behaviors and pursuing shared goals with agents of heterogeneous teams which include other robots, humans, and software systems. The robots were mostly confined to industrial environments, and rigid protocols severely limited human-robot interaction (HRI) there during the last decades of the last century. Environments, which range from the extreme scenarios of deep sea explorations, space missions, and rescue operations to the more conventional human habitats of workshops, homes, offices, hospitals, museums, and schools. In the particular, research in a special area of service robotics called personal robotics is expected to enable richer and more flexible forms of HRI in the near future, bringing robots closer to humans in a variety of healthcare, training, education, and entertainment contexts.
Robot ethics is an applied ethics branch which Endeavour’s to isolate and analyze ethical issues arising in connection with present and prospective uses of robots. The below questions vividly illustrate the range of issues falling in the purview of robot ethics.
• Who is responsible for damages caused by personal and service robots?
• Are there ethical constraints on the control hierarchies design for mixed human-robot cooperative teams?
• Is the privacy right threatened by personal robots accessing the internet?
• Are human linguistic abilities and culture impoverished by extensive interactions with robots which are linguistically less proficient than human beings?
Blog about Robotics Introduction, news of the robot, information about the robot, sharing knowledge about the various kinds of robots, shared an article about robots, and others associated with the robot
Develop Robot Using BasicX Microcontroller
Controllers and processors continually improve at an exponential rate. Courses instructors in microcontrollers and microprocessors need constant exposure to the latest technologies available to ensure that their students remain on the cutting edge of our technological capability. This article focuses on how the BasicX (BX-24p) microcontroller may be utilized to control non-holonomic autonomous mobile robots.
This includes interfacing common robotic components such as: motors, sensors and end effectors. The BX-24p is a microcontroller industry grade that is very robust and powerful. It is also compatible with the microcontroller carrier boards of BASIC Stamp, the BASIC Stamp’s components and other components commonly found in technology and engineering classrooms. Many helpful BasicX control functions are discussed and explained that were utilized for the development of two mobile.
One of small-scale system that is often used as an introductory experience of microprocessor or microcontroller is the BASIC Stamp II (BS2) microcontroller by Parallax. The BS2 is an educational carrier board called the Board of Education (Boe) and a robotic chassis giving the whole system the nick name “Boe-Bot.” Parallax also makes a variety of sensors and add-on components, which in most cases have all the necessary circuitry prepackaged with the sensor. These low priced devices allow students the opportunity to develop robotic systems using microprocessors in an environment that is safe, easy to interface, cost effective and enjoyable.
The language of the BX-24p is called BasicX and is almost 100% compatible with the QBasic and Visual Basic. It also has the programming structure of other popular languages such as C++, C, Java, and Perl. This allows students to learn these languages and techniques and implement them in the classroom without having standard industrial equipment. Once students move beyond higher education, they will have knowledge of commonly used languages and techniques and not just theory. All of the capabilities of the BX-24p make it a good choice to control systems that need high-powered performance at a low cost.
This includes interfacing common robotic components such as: motors, sensors and end effectors. The BX-24p is a microcontroller industry grade that is very robust and powerful. It is also compatible with the microcontroller carrier boards of BASIC Stamp, the BASIC Stamp’s components and other components commonly found in technology and engineering classrooms. Many helpful BasicX control functions are discussed and explained that were utilized for the development of two mobile.
One of small-scale system that is often used as an introductory experience of microprocessor or microcontroller is the BASIC Stamp II (BS2) microcontroller by Parallax. The BS2 is an educational carrier board called the Board of Education (Boe) and a robotic chassis giving the whole system the nick name “Boe-Bot.” Parallax also makes a variety of sensors and add-on components, which in most cases have all the necessary circuitry prepackaged with the sensor. These low priced devices allow students the opportunity to develop robotic systems using microprocessors in an environment that is safe, easy to interface, cost effective and enjoyable.
The language of the BX-24p is called BasicX and is almost 100% compatible with the QBasic and Visual Basic. It also has the programming structure of other popular languages such as C++, C, Java, and Perl. This allows students to learn these languages and techniques and implement them in the classroom without having standard industrial equipment. Once students move beyond higher education, they will have knowledge of commonly used languages and techniques and not just theory. All of the capabilities of the BX-24p make it a good choice to control systems that need high-powered performance at a low cost.
BX-24p Robotic Motor Controller
Many difficulties controlling of mobile robots involve having a motion controller that is small enough to be on the mobile robot, powerful enough to control the device and simple enough to be programmed with ease. In this case, the BX-24p comes to the rescue.
Robotic motion control can be realized using a Motor Mind C carrier board (MMC_BS2) that is designed for use with the BS2, but since the BX-24p is backward compatible with the BS2, integration from one to another can be easily done. Some of this carrier board features include a place to insert a microcontroller chip (BX-24p), places to solder wires for I/O and a place to insert a motor controller. Typically, the motor controller used with the MMC_BS2 is the Motor Mind C (MMC) which is capable of driving two 12V DC motors. The 12V DC power supply and DC motors are wired directly to the MMC_BS2. The user control, almost all, is done through programming in the BasicX language which reduces greatly other types of integration. The BasicX program can drive each motor at different speeds in either direction allowing any combination of forward, reverse and turning motions at any speed desired to move a robotic vehicle.
One must understand how the MMC motor controller works to drive a motor using the BX-24p and the MMC. The controller uses a number of hexadecimal to set the speed of a motor. For instance “0000” means no motion, “03FF” stands for 100% forward and “FC01” stands for 100% reverse. This means that any full motion percentage in either direction can be achieved by taking that percentage of the maximum hexadecimal value. For instance, to find 28% of full speed first take 28% * 1023 (Decimal 1023 = Hexadecimal 03ff). Next take that product (286) and convert it back to the hexadecimal value (011E). 011E represents the hexadecimal value of 28% of full speed. The setup speed for the controller is placed in a queue in the program and sent from the BX-24p to the MMC as a command packet via a serial communication.
Robotic motion control can be realized using a Motor Mind C carrier board (MMC_BS2) that is designed for use with the BS2, but since the BX-24p is backward compatible with the BS2, integration from one to another can be easily done. Some of this carrier board features include a place to insert a microcontroller chip (BX-24p), places to solder wires for I/O and a place to insert a motor controller. Typically, the motor controller used with the MMC_BS2 is the Motor Mind C (MMC) which is capable of driving two 12V DC motors. The 12V DC power supply and DC motors are wired directly to the MMC_BS2. The user control, almost all, is done through programming in the BasicX language which reduces greatly other types of integration. The BasicX program can drive each motor at different speeds in either direction allowing any combination of forward, reverse and turning motions at any speed desired to move a robotic vehicle.
One must understand how the MMC motor controller works to drive a motor using the BX-24p and the MMC. The controller uses a number of hexadecimal to set the speed of a motor. For instance “0000” means no motion, “03FF” stands for 100% forward and “FC01” stands for 100% reverse. This means that any full motion percentage in either direction can be achieved by taking that percentage of the maximum hexadecimal value. For instance, to find 28% of full speed first take 28% * 1023 (Decimal 1023 = Hexadecimal 03ff). Next take that product (286) and convert it back to the hexadecimal value (011E). 011E represents the hexadecimal value of 28% of full speed. The setup speed for the controller is placed in a queue in the program and sent from the BX-24p to the MMC as a command packet via a serial communication.
Robot Tactile Sensing
The people involved number in research and development of tactile and haptic sensing and the number of reported works has increased particularly in the last couple of years, but the use of tactile sensors is still extremely low and fails to show momentum. Why? We think that basically there is no real market- oriented driving force boosting the tactile sensing domain: industrial automation aims efficiency at low cost. This generally means usage of well established reliable and as simple as possible technologies.
Robots with tactile sensing are not at that stage and some applications that could profit from them are implemented by forcing a structured environment and using simpler sensing devices like proximity sensors; other domains like medicine, particularly surgery, and service robotics have not been able to play that role until now. We must add two other considerations: tactile and particularly haptic sensing is quite demanding not only in terms of hardware but also of software.
The extraction of information from tactile sensors may require the implementation of complicated algorithms; the hardware and software available, even at an experimental level, are still not adequate for some already defined needs. The future vision in what tactile sensing is concerned is optimistic but only moderately. Assuming that the industry will not change very much its production style in the near future, we think that it will be up to scientists and engineers to go on developing new sensors suitable for other domains of applications.
We believe and expect that the technology will be able to overcome some of the current limitations of tactile sensing such as taxel dimension (resolution) and arrangement (array organized sensors suffer from crosstalk, i.e. several taxels can be excited by a very localized force), and integration of all components required to output tactile sensation (sensors, conditioning circuits, processing units, etc.). Nanotechnologies Nano-sciences and will probably provide answers to these problems but no one can assure if the solutions will have a major impact on tactile sensor usage.
Robots with tactile sensing are not at that stage and some applications that could profit from them are implemented by forcing a structured environment and using simpler sensing devices like proximity sensors; other domains like medicine, particularly surgery, and service robotics have not been able to play that role until now. We must add two other considerations: tactile and particularly haptic sensing is quite demanding not only in terms of hardware but also of software.
The extraction of information from tactile sensors may require the implementation of complicated algorithms; the hardware and software available, even at an experimental level, are still not adequate for some already defined needs. The future vision in what tactile sensing is concerned is optimistic but only moderately. Assuming that the industry will not change very much its production style in the near future, we think that it will be up to scientists and engineers to go on developing new sensors suitable for other domains of applications.
We believe and expect that the technology will be able to overcome some of the current limitations of tactile sensing such as taxel dimension (resolution) and arrangement (array organized sensors suffer from crosstalk, i.e. several taxels can be excited by a very localized force), and integration of all components required to output tactile sensation (sensors, conditioning circuits, processing units, etc.). Nanotechnologies Nano-sciences and will probably provide answers to these problems but no one can assure if the solutions will have a major impact on tactile sensor usage.
Approach to Robot Programming
The industrial robot programming task is done basically in two ways:
1. The programmer in task charged can use some modeling technique but, instead of thinking only about the problem, it is necessary to think about the robot that will run the program, and about its programming language. Both the language and the robot will limitate the specification of the problem; moreover it is not possible to reuse the same program in a different robot.
2. The programmer uses some environment of graphical development, where is possible to test the program before using it in the robot. It is also possible to develop programs for different robots, but it is necessary to have a library for each robot. Even with these facilities, these tools do not solve the programming problem of the robot to interact with its environment.
The programming languages of industrial robot did not evolved in the same manner as the computer languages. Those environments and languages have some drawbacks:
• The typical languages are low-level, imperative, or structured. Both of them are more closed to the robot specification than to the problem, difficult the problem modeling task and all other good practices that a correct software engineering should require.
• Each industrial robot has its own programming language, which difficulties, or even turns impossible, to reuse the source code.
There is the problem to be solved. It will be used an adequate modeling technique, responsible for decompose the problem into simple problems, that would be easily programmed; formal models are employed to describe data structures and operations necessary to solve the elements sub-problems. To describe formally the overall problem and the sub-problems, a truly high level language, closed to the specification instead of the robot, should be used. Then we advocate the use of an easy-to-use compiler front-end, like Grafcet, that can interpret the specification language and generate an intermediate description for the program specified. An intermediate representation is used because the front-end must be focused on the specification of the problem, and not on the robot.
1. The programmer in task charged can use some modeling technique but, instead of thinking only about the problem, it is necessary to think about the robot that will run the program, and about its programming language. Both the language and the robot will limitate the specification of the problem; moreover it is not possible to reuse the same program in a different robot.
2. The programmer uses some environment of graphical development, where is possible to test the program before using it in the robot. It is also possible to develop programs for different robots, but it is necessary to have a library for each robot. Even with these facilities, these tools do not solve the programming problem of the robot to interact with its environment.
The programming languages of industrial robot did not evolved in the same manner as the computer languages. Those environments and languages have some drawbacks:
• The typical languages are low-level, imperative, or structured. Both of them are more closed to the robot specification than to the problem, difficult the problem modeling task and all other good practices that a correct software engineering should require.
• Each industrial robot has its own programming language, which difficulties, or even turns impossible, to reuse the source code.
There is the problem to be solved. It will be used an adequate modeling technique, responsible for decompose the problem into simple problems, that would be easily programmed; formal models are employed to describe data structures and operations necessary to solve the elements sub-problems. To describe formally the overall problem and the sub-problems, a truly high level language, closed to the specification instead of the robot, should be used. Then we advocate the use of an easy-to-use compiler front-end, like Grafcet, that can interpret the specification language and generate an intermediate description for the program specified. An intermediate representation is used because the front-end must be focused on the specification of the problem, and not on the robot.
Modeling Techniques of Robotic Programming
The use of an adequate modeling technique will facilitate the programming system development, enabling the system developers and the system clients to express their ideas, allowing their communication in a known way. The modeling advantage is the creation of models from the system and its behavior that can be seen in different abstraction levels, before implementing it. So, it is very important to model the system.
If the programs are created directly, thinking on the problem and on the machine, this programs would be difficulty to read, to write, and consequently, to maintain. So, some techniques were created, like the structure analysis, that was the first modeling technique, where the problem is decomposed based on the data and the operations, that should be modeled separately. It is used the Entity Relationship Diagram (ERD) to model the data, and to model the operations it is used the Data Flow Diagram (DFD). Recently, there are some others modeling techniques, like Unified Modeling Language (UML), used to model object orienting systems. It is used the Class Diagram, that shows the classes and their relationships in a logical view (like ERD to structure analysis); the State Transition Diagram, that shows the events that causes transition from one state to an- other, with its resulting actions (like DFD to structure analysis); and the Use-Cases Diagram, that shows the system’s use cases and the actors that interact to them.
The robot programming has its modeling techniques. One modeling technique used in the development of mobile robots, the Subsumption Architecture, was used to model a manufacturing cell, composed by two robots and some others components. The subsumption architecture was the first behavior based modeling technique and, even it had been created to develop mobile robots, they can be used, as a high level abstraction, to model industrial applications. The analyst should choose the most adequate for such problem among various modeling techniques, to obtain the advantages of the software engineering.
If the programs are created directly, thinking on the problem and on the machine, this programs would be difficulty to read, to write, and consequently, to maintain. So, some techniques were created, like the structure analysis, that was the first modeling technique, where the problem is decomposed based on the data and the operations, that should be modeled separately. It is used the Entity Relationship Diagram (ERD) to model the data, and to model the operations it is used the Data Flow Diagram (DFD). Recently, there are some others modeling techniques, like Unified Modeling Language (UML), used to model object orienting systems. It is used the Class Diagram, that shows the classes and their relationships in a logical view (like ERD to structure analysis); the State Transition Diagram, that shows the events that causes transition from one state to an- other, with its resulting actions (like DFD to structure analysis); and the Use-Cases Diagram, that shows the system’s use cases and the actors that interact to them.
The robot programming has its modeling techniques. One modeling technique used in the development of mobile robots, the Subsumption Architecture, was used to model a manufacturing cell, composed by two robots and some others components. The subsumption architecture was the first behavior based modeling technique and, even it had been created to develop mobile robots, they can be used, as a high level abstraction, to model industrial applications. The analyst should choose the most adequate for such problem among various modeling techniques, to obtain the advantages of the software engineering.
Declarative Language Robotic Programming
It is important to use a modeling technique as it was said before, but is also important to have some language that would allow the programmer to express exactly what he intends to do.
Such a language should be simple, and as closed to the specification of the problem as possible. It must also have high level constructors that allow the definition of structured and complex abstract data types and mathematical operators over them for a language to be close to the specification.
Basically, there are two kinds of programming languages:
1. Imperative languages: the underlying principle or the operational semantics is very similar to the processor’s execution cycle, being necessary to understand its architecture; the kind of avail- able statements is also similar to the machine instructions. The programmer should also know how to manipulate memory elements to store the necessary data;
2. Declarative languages: instead of following the execution principles, those languages have as back- ground a mathematical theory that supports operations over that data and data representation. The explicit memory manipulation is not necessary; the programmer just manipulate, in a high level data, without being necessary to know where this data is stored.
Declarative languages are higher level than imperative languages, more closed to the problem specification. One example to show the difference between this two kind of languages is the file manipulation, that can be done in imperative languages (like C) and in declarative languages (like SQL).
Declarative languages are classified as functional or relational (logic) according to the style. The first group is supported by the principle that a program is just a function mapping the input data into the output results; while the second family relies upon the idea that a program is a set of assertions defining the relations that hold in some world. Typical declarative languages are: ML, Lisp, or Haskell (functional paradigm), and Prolog (logic paradigm).
Such a language should be simple, and as closed to the specification of the problem as possible. It must also have high level constructors that allow the definition of structured and complex abstract data types and mathematical operators over them for a language to be close to the specification.
Basically, there are two kinds of programming languages:
1. Imperative languages: the underlying principle or the operational semantics is very similar to the processor’s execution cycle, being necessary to understand its architecture; the kind of avail- able statements is also similar to the machine instructions. The programmer should also know how to manipulate memory elements to store the necessary data;
2. Declarative languages: instead of following the execution principles, those languages have as back- ground a mathematical theory that supports operations over that data and data representation. The explicit memory manipulation is not necessary; the programmer just manipulate, in a high level data, without being necessary to know where this data is stored.
Declarative languages are higher level than imperative languages, more closed to the problem specification. One example to show the difference between this two kind of languages is the file manipulation, that can be done in imperative languages (like C) and in declarative languages (like SQL).
Declarative languages are classified as functional or relational (logic) according to the style. The first group is supported by the principle that a program is just a function mapping the input data into the output results; while the second family relies upon the idea that a program is a set of assertions defining the relations that hold in some world. Typical declarative languages are: ML, Lisp, or Haskell (functional paradigm), and Prolog (logic paradigm).
Subscribe to:
Posts (Atom)
