In the progress of manufacturing and the processes involving robotics technology historically have been defined by the automotive sector and have been very much driven by price and the need to automate specific tasks particular to large volume manufacturing. The new economy is much less focused on mass manufacturing, however and more concentrated on producing customized products as customer want. The model company is no longer a large entity such as Ford, Chrysler, GM, but small and medium enterprises as for example seen in the Fox Valley or in the suburbs of Chicago. The need in such an economy is more far dependent on higher degrees of adaptation, ease of use and other factors that enable small runs of made to order products. Although the United States has continue to lead the world over the last decade in increasing manufacturing productivity, it is becoming increasingly difficult for us to compete with companies in low salaries countries producing the same product using the same tools and processing.
Through the adoption and development of next robotics technology generation and the advancement of a more highly trained workforce, however, it is possible to continue to lead in manufacturing productivity especially in small and medium sized company.
Logistics
The efficiency logistics process is essential to most aspects of daily lives from mail delivery to the availability of food in grocery stores. Robotics technology is being used to automate the handling of containers at ports in Australia and elsewhere and has the potential to improve the inspection process as well. Once they leave the port or point of origin, the movement of goods usually entails multiple steps. The food distribution from farmers to grocery stores, involves several transportation phases and handling. Next generation robotics technology has the potential to enable greater optimization such as logistics processes and reduce the price of food and other goods by several percents.
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
Adaptable and Reconfigurable Robotics Assembly
Currently the time lag between the conceptual design of a new product and production on an assembly line is the US is unacceptably high. This lead time can be as high as twenty four months. Given a new product and a set of assembly line subsystems that can be used to make the product for a new car, we want to achieve the ability to adapt the subsystems, reconfigure them and set up work cells to produce the product. The roadmap for adaptable and reconfigurable accordingly assembly includes the following goals over the next fifteen years.
5 years: Achieve ability to set up, program and configure basic assembly line operations for new products with a specified industrial robot arm, tooling and auxiliary material handling devices in under 24 hours.
10 years: Achieve ability to set up, program and configure basic assembly line operations for new products with a specified industrial robot arm, tooling and auxiliary material handling devices in one 8 hour shift.
15 years: Achieve ability to set up, program and configure basic assembly line operations for new products with a specified industrial robot arm, tooling and auxiliary material handling devices in one hour.
Autonomous of navigation is a basic capability that will impact the mining automation and construction equipment, the efficient transportation of raw materials to processing plants, automated guided vehicles for material handling in assembly line, and supports operation of logistics like warehousing and distribution. A safe autonomous navigation in unstructured environments with static obstacles, human driven vehicles, animals and pedestrian will require significant investments in component technologies.
5 years: Autonomous of vehicles will be capable of driving in any modern town or city with clearly lit and marked roads and demonstrate safe driving comparable to a human driver.
10 years: Autonomous of vehicles will be capable of driving in any city and on unpaved roads, and exhibit capability for off-road environment that humans can drive in.
15 years: Autonomous of vehicles will be capable of driving in any environment in which humans can drive.
5 years: Achieve ability to set up, program and configure basic assembly line operations for new products with a specified industrial robot arm, tooling and auxiliary material handling devices in under 24 hours.
10 years: Achieve ability to set up, program and configure basic assembly line operations for new products with a specified industrial robot arm, tooling and auxiliary material handling devices in one 8 hour shift.
15 years: Achieve ability to set up, program and configure basic assembly line operations for new products with a specified industrial robot arm, tooling and auxiliary material handling devices in one hour.
Autonomous of navigation is a basic capability that will impact the mining automation and construction equipment, the efficient transportation of raw materials to processing plants, automated guided vehicles for material handling in assembly line, and supports operation of logistics like warehousing and distribution. A safe autonomous navigation in unstructured environments with static obstacles, human driven vehicles, animals and pedestrian will require significant investments in component technologies.
5 years: Autonomous of vehicles will be capable of driving in any modern town or city with clearly lit and marked roads and demonstrate safe driving comparable to a human driver.
10 years: Autonomous of vehicles will be capable of driving in any city and on unpaved roads, and exhibit capability for off-road environment that humans can drive in.
15 years: Autonomous of vehicles will be capable of driving in any environment in which humans can drive.
Surgical and Interventional Robotics
The surgical robots development is motivated by the desire to:
• Enhance the effectiveness of a procedure by information coupling to the action in the interventional suite or operating room.
• Transcend human physical limitations in performing surgery and other interventional procedures, while still affording human control over the procedure.
Two decades after reported the first robotic surgical procedure, surgical robotics now are being widely used in the interventional suite or operating room. Surgical robots are beginning to realize their potential in terms of improved visualization and accuracy, as well as enabling of new procedures.
Recently robots used in surgery are under the direct control of surgeon, often in a tele-operation scenario in which a human operator manipulates a master input device and patient side robots follows the inputs. Robots allow the surgeon to have dexterity inside the body, scale down operator motions from normal human dimensions to very small distances, and provide a very intuitive connection between the operator and the instrument tips, in contrast to traditional minimally invasive surgery.
The surgeon can cut, suture and cauterize with accuracy equal to or better than that previously available during only very invasive open surgery. A complete surgical workstation contains both real time imaging devices and robotic devices. The next surgical workstation generation will provide a wide variety of computer and physical enhancements, such as “no fly” zones around delicate anatomical structures, seamless displays that can place amounts of relevant data in surgeon’s field of view, and recognition of surgical motions and patient state to evaluate performance and predict health outcomes.
Many medical procedures can be planned ahead of time and executed in a reasonably predictable manner if the right information is available. By analogy to industrial manufacturing systems, this model is often referred to as “Surgical CAD/CAM” (Computer Aided Design and Computer Aided Manufacturing).
• Enhance the effectiveness of a procedure by information coupling to the action in the interventional suite or operating room.
• Transcend human physical limitations in performing surgery and other interventional procedures, while still affording human control over the procedure.
Two decades after reported the first robotic surgical procedure, surgical robotics now are being widely used in the interventional suite or operating room. Surgical robots are beginning to realize their potential in terms of improved visualization and accuracy, as well as enabling of new procedures.
Recently robots used in surgery are under the direct control of surgeon, often in a tele-operation scenario in which a human operator manipulates a master input device and patient side robots follows the inputs. Robots allow the surgeon to have dexterity inside the body, scale down operator motions from normal human dimensions to very small distances, and provide a very intuitive connection between the operator and the instrument tips, in contrast to traditional minimally invasive surgery.
The surgeon can cut, suture and cauterize with accuracy equal to or better than that previously available during only very invasive open surgery. A complete surgical workstation contains both real time imaging devices and robotic devices. The next surgical workstation generation will provide a wide variety of computer and physical enhancements, such as “no fly” zones around delicate anatomical structures, seamless displays that can place amounts of relevant data in surgeon’s field of view, and recognition of surgical motions and patient state to evaluate performance and predict health outcomes.
Many medical procedures can be planned ahead of time and executed in a reasonably predictable manner if the right information is available. By analogy to industrial manufacturing systems, this model is often referred to as “Surgical CAD/CAM” (Computer Aided Design and Computer Aided Manufacturing).
Robotics and Manufacturing Vignettes
It briefly discusses the motivating applications with vignettes and the critical capabilities required a dramatic positive impact on the applications. The vignettes serve to illustrate paradigm changes in manufacturing and as examples of integration across technology and capability.
Vignette1. Assembly line assistant robots
The experiences of automotive manufacturer a surge in orders for its new electric car design and needs to quickly merge its production capability with other earlier models already in production. Assembly tasks are reallocated rapidly to accommodate the new more efficient car model. An assembly line set assistant robots are brought in and quickly configured to work alongside the retrained human workers in the new tasks. One practice shift is arranged for the robot’s sensor systems and robot learning algorithm to fine tune parameters, and then the second shift is put it into operation, doubling plant output in four days.
Vignette 2. One of a kind, discrete part manufacture and assembly
A small job at a shop with 5 employees primarily catering to orders from medical devices companies is approached by an occupational therapist one morning to create a customized head controlled input device for a quadriplegic wheelchair user. Currently the production of such one of a kind device would be prohibitively expensive because of the time and labor required for setting up machines and for assembly. The job shop owner reprograms a robot using voice commands and gestures, teaching the robot when it gets stuck. The robot is able to get the stock to lathes and mills, and runs the machines. While the machines are running, the robot set up the necessary electronic and mechanical component asking for assistance when there is ambiguity in the instruction set.
Vignette 3. Rapid, integrated, model based design of the supply chain
The packaging for infant formula from a major supplier from a foreign country is found to suffer from serious quality control problems. An important aspect is the introduction of 20 robots to manufacture rapidly the redesigned package.
Vignette1. Assembly line assistant robots
The experiences of automotive manufacturer a surge in orders for its new electric car design and needs to quickly merge its production capability with other earlier models already in production. Assembly tasks are reallocated rapidly to accommodate the new more efficient car model. An assembly line set assistant robots are brought in and quickly configured to work alongside the retrained human workers in the new tasks. One practice shift is arranged for the robot’s sensor systems and robot learning algorithm to fine tune parameters, and then the second shift is put it into operation, doubling plant output in four days.
Vignette 2. One of a kind, discrete part manufacture and assembly
A small job at a shop with 5 employees primarily catering to orders from medical devices companies is approached by an occupational therapist one morning to create a customized head controlled input device for a quadriplegic wheelchair user. Currently the production of such one of a kind device would be prohibitively expensive because of the time and labor required for setting up machines and for assembly. The job shop owner reprograms a robot using voice commands and gestures, teaching the robot when it gets stuck. The robot is able to get the stock to lathes and mills, and runs the machines. While the machines are running, the robot set up the necessary electronic and mechanical component asking for assistance when there is ambiguity in the instruction set.
Vignette 3. Rapid, integrated, model based design of the supply chain
The packaging for infant formula from a major supplier from a foreign country is found to suffer from serious quality control problems. An important aspect is the introduction of 20 robots to manufacture rapidly the redesigned package.
Robotics Priorities for Manufacturing
Restructuring of US manufacturing is essential to future of economic growth, the creation of new jobs and ensuring competitiveness. This in turn requires investment in basic research, development of new technologies, and integration of the result into systems of manufacturing.
Federal Investment in research in manufacturing can revitalize American manufacturing. Investing a small portion of national resources into a science of cost effective, resource efficient manufacturing would benefit to consumers and support million of workers in this vital sector of the US economy. It will allow economy to flourish even as the ratio of workers to pensioners continuously decreases. Such a research and development program would also benefit the agriculture, healthcare and transportation industry, strengthen national resources in defense, energy, and security. The resulting flurry or research activity would improve greatly the quality and invigorate productivity of manufacturing for the next years.
Robotics is a key of transformative technology that can revolutionize manufacturing. American workers no longer aspire to low level factory jobs and the cost of US workers keeps rising due to insurance and healthcare costs. The next generation of the miniaturized, complex products with short cycles requires assembly adaptability, precision and reliability beyond the skills of human workers even when workers are affordable. Improved robotics and automation in manufacturing will; retain intellectual property and wealth that would go off shore without it; save companies by making them more competitive; provides jobs for developing, training, producing and maintaining the robots; allow factories to employ human-robot teams that leverage each other’s strength and skills e.g. human intelligent and dexterity with robot precision, strength and repeatability; improve working condition and reduce expensive medical problems ; and reduce manufacturing lead time for finished goods, allowing system to be more responsive to changes in retail demand. Indeed defective used of robotics will increase creation of new jobs, improve the quality of these jobs and enhance global competitiveness.
Federal Investment in research in manufacturing can revitalize American manufacturing. Investing a small portion of national resources into a science of cost effective, resource efficient manufacturing would benefit to consumers and support million of workers in this vital sector of the US economy. It will allow economy to flourish even as the ratio of workers to pensioners continuously decreases. Such a research and development program would also benefit the agriculture, healthcare and transportation industry, strengthen national resources in defense, energy, and security. The resulting flurry or research activity would improve greatly the quality and invigorate productivity of manufacturing for the next years.
Robotics is a key of transformative technology that can revolutionize manufacturing. American workers no longer aspire to low level factory jobs and the cost of US workers keeps rising due to insurance and healthcare costs. The next generation of the miniaturized, complex products with short cycles requires assembly adaptability, precision and reliability beyond the skills of human workers even when workers are affordable. Improved robotics and automation in manufacturing will; retain intellectual property and wealth that would go off shore without it; save companies by making them more competitive; provides jobs for developing, training, producing and maintaining the robots; allow factories to employ human-robot teams that leverage each other’s strength and skills e.g. human intelligent and dexterity with robot precision, strength and repeatability; improve working condition and reduce expensive medical problems ; and reduce manufacturing lead time for finished goods, allowing system to be more responsive to changes in retail demand. Indeed defective used of robotics will increase creation of new jobs, improve the quality of these jobs and enhance global competitiveness.
Robotics as a Key Economic Enabler
Robots have been used primarily to provide increased of accuracy and throughput for particular, repetitive tasks, such as painting, welding, and machining, in hazardous, high volume involved implementing customized solutions with relatively specific, near term value. Although a sizeable industrial robotic industry has developed as result, the applications for such first generation robotics solutions have proven to be relatively narrow and largely restricted to static, indoor environment due to enabling technology limitations.
However, tremendous advancements in robotics technology have enabled a new generation applications in field as diverse as agile manufacturing, medicine, healthcare, logistics and other commercial and consumer market segments within the past five years,. Further, it is becoming increasingly evident that these early, next generation products are a harbinger of numerous, global, large scale, robotics technology markets likely to develop in the coming decade. Owing to the inexorable aging of our population, the emergence of such a next generation, “robotech” industry will eventually affect the lives and have enormous social, economic, and political impact on the future.
The United States left behind other countries in recognizing the importance of robotics technology. While the European Union, Japan, Korea and the rest of the world have made significant R&D investments in robotic technology. Robotech clearly represents one of the few technologies capable in the near term of building new companies and creating new jobs and in the long run of addressing an issue of critical national importance.
Over 140 individuals from companies, laboratories, and universities from across the United States joined forces to establish a national robotech initiative that identifies the future impact of robotics technology on the social, economic, and security need of the nations, outlines the various scientific and technological challenges, and documents a technological roadmap to address those challenges. This effort was sponsored by the Computing Community Consortium (CCC) and led by the 12 world class researchers from the leading institutions of robotics academic.
However, tremendous advancements in robotics technology have enabled a new generation applications in field as diverse as agile manufacturing, medicine, healthcare, logistics and other commercial and consumer market segments within the past five years,. Further, it is becoming increasingly evident that these early, next generation products are a harbinger of numerous, global, large scale, robotics technology markets likely to develop in the coming decade. Owing to the inexorable aging of our population, the emergence of such a next generation, “robotech” industry will eventually affect the lives and have enormous social, economic, and political impact on the future.
The United States left behind other countries in recognizing the importance of robotics technology. While the European Union, Japan, Korea and the rest of the world have made significant R&D investments in robotic technology. Robotech clearly represents one of the few technologies capable in the near term of building new companies and creating new jobs and in the long run of addressing an issue of critical national importance.
Over 140 individuals from companies, laboratories, and universities from across the United States joined forces to establish a national robotech initiative that identifies the future impact of robotics technology on the social, economic, and security need of the nations, outlines the various scientific and technological challenges, and documents a technological roadmap to address those challenges. This effort was sponsored by the Computing Community Consortium (CCC) and led by the 12 world class researchers from the leading institutions of robotics academic.
Modular Robotics Interface
High mechanical retention force between two joined modules is provided by the interference fit of the eight interlocking pairs of ABS sockets and pins. 16 pairs of electrical sockets and pins provide 8 redundant channels of electrical connection for passing the ground, communications signals and power as well as dedicated processor inputs and outputs for robot orientation sensing relative.
Each of the two halves of every robotic module is equipped with one Atmel Mega 16 microprocessor. Both microprocessors are connected to the global TTL level half duplex RS232 bus, to which all other joined controller, actuator and other add on robotic modules are connected. There is another communication line of the same type inside the robot to which both processors and AX-12 servo are connected. Any of the two microprocessors can be used to control the servo motors, however both are necessary for complete and correct sensing of the module orientation relative to its neighbors.
The schematic of the intra module and inter module communications is given for both internal and external half duplex RS 232 busses, the speed of communication is programmable up to 1 Mbps.
All the necessary firmware for the embedded microprocessors will be provided to the user community through the dedicated user group website. Communication with the user PC will be implemented using a separate dedicated controller module. The controller module will not have any motion capabilities, instead it will be equipped with a more powerful microprocessor, for instance, 16/32 bit ARM Olimex LPC-H2148, that will support higher level control functions, such as higher level robot behaviors, behavior storage and exchange with the PC through either wireless, USB or Bluetooth connection.
It has developed a visual software interface that will provide with the means of initial robot design and simulation before the actual robot is built. It can also be used to identify the assemble structure of robots and for behavior design automation.
Each of the two halves of every robotic module is equipped with one Atmel Mega 16 microprocessor. Both microprocessors are connected to the global TTL level half duplex RS232 bus, to which all other joined controller, actuator and other add on robotic modules are connected. There is another communication line of the same type inside the robot to which both processors and AX-12 servo are connected. Any of the two microprocessors can be used to control the servo motors, however both are necessary for complete and correct sensing of the module orientation relative to its neighbors.
The schematic of the intra module and inter module communications is given for both internal and external half duplex RS 232 busses, the speed of communication is programmable up to 1 Mbps.
All the necessary firmware for the embedded microprocessors will be provided to the user community through the dedicated user group website. Communication with the user PC will be implemented using a separate dedicated controller module. The controller module will not have any motion capabilities, instead it will be equipped with a more powerful microprocessor, for instance, 16/32 bit ARM Olimex LPC-H2148, that will support higher level control functions, such as higher level robot behaviors, behavior storage and exchange with the PC through either wireless, USB or Bluetooth connection.
It has developed a visual software interface that will provide with the means of initial robot design and simulation before the actual robot is built. It can also be used to identify the assemble structure of robots and for behavior design automation.
Molecube Mechanics of Modular Robotics
In this article will be presented of Molecube mechanic of modular Robotic. The module design is inspired by earlier successful design that was used to demonstrate physical robotic self replication. The original Molecube design of 2004 has been miniaturized, ruggedized and simplified.
Each robot has a shape of a cube with rounded corners and comprises approximately two triangular pyramidal halves connected with their bases so that their main axes are coincident. These cube halves are rotated by the robot motor about a common axis relative to each other. Each of the six faces of a robot is equipped with an electromechanical connector that can be used to join two modules together. Symmetric connector design allows 4 possible relative orientations of two connected module interfaces, each resulting in different robot kinematics.
Each Molecube has six major structural parts are shown translucent and all can be manufactured from ABS plastic using the available design file and a fused disposition rapid prototyping machine, for instance Dimension SST or similar.
The remaining components are standard stock parts: the AX-12 servo, thin section X-type bearing and the electrical collector to enable continuous module rotation. The AX-12 servo occupies the largest volume inside of the module. Its body dimensions limit the smallest possible dimensions of the Molecube. To make the module as small as possible and improve the transmission torque from the servo to the robot haves, the servo was modified. The servo front wall is removed, and the output internal gear of the Molecube is meshed directly with the output spur gear of the robot that is located inside of the servo body. This type of meshing allows the servo output shaft to be supported in the bearings on both sides of the torque transmission point, thus reducing the gear deflection, and the chance of gear disengagement under load.
Each robot has a shape of a cube with rounded corners and comprises approximately two triangular pyramidal halves connected with their bases so that their main axes are coincident. These cube halves are rotated by the robot motor about a common axis relative to each other. Each of the six faces of a robot is equipped with an electromechanical connector that can be used to join two modules together. Symmetric connector design allows 4 possible relative orientations of two connected module interfaces, each resulting in different robot kinematics.
Each Molecube has six major structural parts are shown translucent and all can be manufactured from ABS plastic using the available design file and a fused disposition rapid prototyping machine, for instance Dimension SST or similar.
The remaining components are standard stock parts: the AX-12 servo, thin section X-type bearing and the electrical collector to enable continuous module rotation. The AX-12 servo occupies the largest volume inside of the module. Its body dimensions limit the smallest possible dimensions of the Molecube. To make the module as small as possible and improve the transmission torque from the servo to the robot haves, the servo was modified. The servo front wall is removed, and the output internal gear of the Molecube is meshed directly with the output spur gear of the robot that is located inside of the servo body. This type of meshing allows the servo output shaft to be supported in the bearings on both sides of the torque transmission point, thus reducing the gear deflection, and the chance of gear disengagement under load.
Molecubes is a Low Cost Modular Robotics
The modular robotics field aims to revolutionize modern conventional robotics and industrial automation by producing a set of modules capable of forming a variety of robots of different shapes and functionalities each performing equally well or better than conventional robot dedicated to one specific task. Recent modular robotics research still requires high entry level of expertise in engineering, robotics, and computer science. Moreover, over the current two decades research in modular robotics has remained quite expensive: if one module is constructed at a cost of a car and the usable set of modules can only be produced at a cost of a house, only few wealthy research labs and universities will be able to afford research in this area.
In other hand, one of the major challenges that limit the public interest to the area of modular robotics is the lack of demonstrable killer application as concluded by most of researchers in the field where modular technology could, beyond doubt, prove superior to the conventional robotics. Several attempts have been taken to find an answer to this challenge inside of the modular robotics community, while reaching attempts outside are complicated by limited physical robot or design availability, construction expenses, or insufficient level of end user expertise.
Molecubes is a low cost simplified and ruggedized reconfigurable modular robotic platform that is relatively easy to assemble, manufacture, and operate for hobbyists to undertake practical research in the area of modular robotics, thus broaden our community and elicit new ideas and insights into the future of the field, and develop new applications. It proposes to use Molecubes as an expandable robotic platform and invite any new enhancements and developments that may come from the volunteer community users and developers.
It will be presented in another article for the mechanics of the robot, module interface design, the software providing visual interface for modular robotic design, simulation and control, etc.
In other hand, one of the major challenges that limit the public interest to the area of modular robotics is the lack of demonstrable killer application as concluded by most of researchers in the field where modular technology could, beyond doubt, prove superior to the conventional robotics. Several attempts have been taken to find an answer to this challenge inside of the modular robotics community, while reaching attempts outside are complicated by limited physical robot or design availability, construction expenses, or insufficient level of end user expertise.
Molecubes is a low cost simplified and ruggedized reconfigurable modular robotic platform that is relatively easy to assemble, manufacture, and operate for hobbyists to undertake practical research in the area of modular robotics, thus broaden our community and elicit new ideas and insights into the future of the field, and develop new applications. It proposes to use Molecubes as an expandable robotic platform and invite any new enhancements and developments that may come from the volunteer community users and developers.
It will be presented in another article for the mechanics of the robot, module interface design, the software providing visual interface for modular robotic design, simulation and control, etc.
Distribution Options of RSS Projects
Let consider how different distribution options stack up with the respect to these requirements.
1. Within existing projects: one obvious option is to re-factor the software but to keep it within the existing of RSS projects. There are several problems with this approach. The current projects mostly have non-trivial dependencies e.g. communication middleware, which outsiders are understandably reluctant to install for the benefit of “a single useful library”. The interdependencies and dependencies within a large RSS project are often not documented well and have to be decoded by examining the build system. At the end there is a human factor; internal developers working on a library within an RSS project may not even be aware of the outside users and may unintentionally make frequent changes which break compatibility?
2. New modules within existing projects: a clear improvement is to create a new distribution module within an existing project, marked clearly as RSF independent. This imposes a certain discipline on the internal developers while maintaining the same level of control over development of the software. Among likely improvements are reduced number and better documentation of dependencies, a more stable API, and simpler installation.
3. New Projects: another step towards more independent DA code is to create a few stand alone projects dedicated, for instance, to particular types of drivers or algorithms (the OpenSLAM approach). A project separates from any RSS stats clearly the intention of developers to create RSF independent code and gives more assurances to the external users.
4. Common Robotic project: finally instead of each RSS project spinning off its own DA project, the community could agree to create a common repository of RSF independent DA libraries. Among additional advantages of this options are unified installation procedure and excellent accessibility for the end users. One of the attractions of the current all in one RSS projects is that to a certain extent they offer a one stop solution to the end users.
1. Within existing projects: one obvious option is to re-factor the software but to keep it within the existing of RSS projects. There are several problems with this approach. The current projects mostly have non-trivial dependencies e.g. communication middleware, which outsiders are understandably reluctant to install for the benefit of “a single useful library”. The interdependencies and dependencies within a large RSS project are often not documented well and have to be decoded by examining the build system. At the end there is a human factor; internal developers working on a library within an RSS project may not even be aware of the outside users and may unintentionally make frequent changes which break compatibility?
2. New modules within existing projects: a clear improvement is to create a new distribution module within an existing project, marked clearly as RSF independent. This imposes a certain discipline on the internal developers while maintaining the same level of control over development of the software. Among likely improvements are reduced number and better documentation of dependencies, a more stable API, and simpler installation.
3. New Projects: another step towards more independent DA code is to create a few stand alone projects dedicated, for instance, to particular types of drivers or algorithms (the OpenSLAM approach). A project separates from any RSS stats clearly the intention of developers to create RSF independent code and gives more assurances to the external users.
4. Common Robotic project: finally instead of each RSS project spinning off its own DA project, the community could agree to create a common repository of RSF independent DA libraries. Among additional advantages of this options are unified installation procedure and excellent accessibility for the end users. One of the attractions of the current all in one RSS projects is that to a certain extent they offer a one stop solution to the end users.
Commercial Software in Robotic
The ration of commercial software in robotics will increase. Open source will continue to provide support for exotic hardware and implement research algorithms but we hope that in the future there will be an option of obtaining commercially supported software for functionalities of basic robotic.
We would like to show this commercial software supplied in a form which can be integrated using an RSF of one’s choice. The proposed arrangement favors companies selling commercial DA software which is then integrated into competing open source, RSF’s and commercial. An alternative which is less attractive from our point of view is that a company entering the market chooses particular RSF and offers its driver or algorithm as a binary which works with only the RSF. We would prefer that the choice of the RSF just like with other tool, remain with the end user.
We believe that this structure of marketplace is an improvement compared to the one which exist today. The main advantage is in proving the architect of a robotic system with greater flexibility in all design aspects: the operating system, the middleware, the software framework, and the specific driver and algorithm implementations.
Below are the some recommendations:
1. To individual contributors: consider contributing and writing RSF independent code regardless of which project you primarily use.
2. To individual RSS projects: Consider re-factoring the existing DA code and distributing it separately from the CM and RSF code. The project administrators may decide to communicate to the developers that their project is focused on integration of software and all new contributions should be factored accordingly.
3. To all RSS projects as a community: consider the common benefits of robotic project. To be successful of project would require a certain critical mass. The entail significant level of commitment and support from at least s few of the existing RSS projects.
We would like to show this commercial software supplied in a form which can be integrated using an RSF of one’s choice. The proposed arrangement favors companies selling commercial DA software which is then integrated into competing open source, RSF’s and commercial. An alternative which is less attractive from our point of view is that a company entering the market chooses particular RSF and offers its driver or algorithm as a binary which works with only the RSF. We would prefer that the choice of the RSF just like with other tool, remain with the end user.
We believe that this structure of marketplace is an improvement compared to the one which exist today. The main advantage is in proving the architect of a robotic system with greater flexibility in all design aspects: the operating system, the middleware, the software framework, and the specific driver and algorithm implementations.
Below are the some recommendations:
1. To individual contributors: consider contributing and writing RSF independent code regardless of which project you primarily use.
2. To individual RSS projects: Consider re-factoring the existing DA code and distributing it separately from the CM and RSF code. The project administrators may decide to communicate to the developers that their project is focused on integration of software and all new contributions should be factored accordingly.
3. To all RSS projects as a community: consider the common benefits of robotic project. To be successful of project would require a certain critical mass. The entail significant level of commitment and support from at least s few of the existing RSS projects.
The Advantages of Separation DA Robotic Software
It proposes to extent possible, the DA software be separated from other type’s code in a way which is obvious to external users and invites reuse across multiple RSS projects. Now it lists potential benefits of this separation and responds to possible criticisms. Both drawbacks and benefits are viewed through the prism of the two objectives.
Potential advantages
1. Wider reuse: it expects that the proposed change would allow community wide library based software reuse in addition to existing framework wide component based reuse. More reusable code would be available to any given robotic practitioner regardless of the chosen RSF ultimately. It is the main advantage of the proposed change.
2. Separation of concerns: more manageable unit is common software engineering practice factoring software into simpler. The expected outcome is increased code quality because it is easier to understand, write and maintain. Without the DA and CM software, an RSS project would contain single purpose RSF code. The mission of such thin RSF project would be clear; enable integration of external code of DA into a complete robotic systems using an external CM. smaller and more uniform projects are easier to maintain overwhelming job in its current form.
3. Code stability: the RSF software tends to be in constant flux in practice. The DA code is shielded from this volatility when written in RSF independent form. A stable code base contains fewer bugs.
4. More users: debugging rate scale favorably with the number of users. More users for a given unit of DA software mean better software quality and fewer bugs.
5. More contributors: contributions do not scale as well as bug reports. Nevertheless, we hope that contributions may increase because of specialization in software.
6. Lower entry barrier: thin RSF can be numerous.
7. More meaningful evaluation: the three types of software are very different and should be evaluated using appropriate criteria separately.
Potential advantages
1. Wider reuse: it expects that the proposed change would allow community wide library based software reuse in addition to existing framework wide component based reuse. More reusable code would be available to any given robotic practitioner regardless of the chosen RSF ultimately. It is the main advantage of the proposed change.
2. Separation of concerns: more manageable unit is common software engineering practice factoring software into simpler. The expected outcome is increased code quality because it is easier to understand, write and maintain. Without the DA and CM software, an RSS project would contain single purpose RSF code. The mission of such thin RSF project would be clear; enable integration of external code of DA into a complete robotic systems using an external CM. smaller and more uniform projects are easier to maintain overwhelming job in its current form.
3. Code stability: the RSF software tends to be in constant flux in practice. The DA code is shielded from this volatility when written in RSF independent form. A stable code base contains fewer bugs.
4. More users: debugging rate scale favorably with the number of users. More users for a given unit of DA software mean better software quality and fewer bugs.
5. More contributors: contributions do not scale as well as bug reports. Nevertheless, we hope that contributions may increase because of specialization in software.
6. Lower entry barrier: thin RSF can be numerous.
7. More meaningful evaluation: the three types of software are very different and should be evaluated using appropriate criteria separately.
The Arguments of Separation DA Robotic Software
Inertia and a certain degree of project patriotism are serious factors which can not be overlooked. There are several technical and non-technical arguments of the proposal why the DA software needs to be separated.
1. More difficult to write: writing libraries used in the context of more than one RSF are potentially more difficult because fewer assumptions can be made about the way the libraries will be used. Writing generic code is harder in general but the extra effort is worthwhile if it is outweighed by the benefits.
2. More work without an immediate return: a person writes a new driver of hardware in order to use it for his or her application within a particular RSF. This developer probably will not benefit directly from making the driver reusable easily in another RSF and, the argument goes, would be reluctant to spend the extra effort required. It could be said that separating drastically different types of software is good design practice despite the overhead of partitioned implementation and upfront planning. Currently the effort required to maintain mixed DA/RSF code in the frequent presence RSF changes is nontrivial. Reduction in maintenance efforts within the existing RSS projects is an immediate benefit which is independent from any reuse potential.
There are other technical choices which would have to be made when refactoring code from RSS projects. For instance, choosing the interface style e.q. C++ vs C, error tracing in RSF independent fashion, handling configuration options, and possibly many others.
These problems could be resolved over time and probably in several ways. It does not see an absolute need for uniformity. It would perhaps be a mistake to attempt to standardize on certain library interfaces up front, it would restrict potential contributors.
It is a few criteria list commonly associated with reusable code to evaluate different distribution options.
• Consistent and stable API.
• Ease accessibility.
• Ease of installation.
• Minimum number of dependencies.
1. More difficult to write: writing libraries used in the context of more than one RSF are potentially more difficult because fewer assumptions can be made about the way the libraries will be used. Writing generic code is harder in general but the extra effort is worthwhile if it is outweighed by the benefits.
2. More work without an immediate return: a person writes a new driver of hardware in order to use it for his or her application within a particular RSF. This developer probably will not benefit directly from making the driver reusable easily in another RSF and, the argument goes, would be reluctant to spend the extra effort required. It could be said that separating drastically different types of software is good design practice despite the overhead of partitioned implementation and upfront planning. Currently the effort required to maintain mixed DA/RSF code in the frequent presence RSF changes is nontrivial. Reduction in maintenance efforts within the existing RSS projects is an immediate benefit which is independent from any reuse potential.
There are other technical choices which would have to be made when refactoring code from RSS projects. For instance, choosing the interface style e.q. C++ vs C, error tracing in RSF independent fashion, handling configuration options, and possibly many others.
These problems could be resolved over time and probably in several ways. It does not see an absolute need for uniformity. It would perhaps be a mistake to attempt to standardize on certain library interfaces up front, it would restrict potential contributors.
It is a few criteria list commonly associated with reusable code to evaluate different distribution options.
• Consistent and stable API.
• Ease accessibility.
• Ease of installation.
• Minimum number of dependencies.
Source Code Size Estimate of Robotic Software Reusable
The estimate is based on calculating the number of SLOC (Source Lines of Code) and it uses as a measure of the effort invested into code creation. The code is classified into one of five categories: the three “pure” and the two mixed intermediates. This classification is approximate because the authors have intimate knowledge of only one of the listed projects. It could be claimed that all projects contain libraries or other internal modules which are RSF independent. The fact that these libraries are not placed in DA category demonstrates an important point. To an outsider it is not obvious if such independent libraries exist and more important there is no indication that they will remain RSF independent in the future.
There is a notable exception within the reviewed RSS projects, the Kinematics Dynamic and Bayesian Filtering libraries distributed by the Orocos project and classified as pure DA code. The libraries which distributed by the OpenSLAM project the figure contain another block of DA code. These are shown as an example of robotic software which is not part of any specific RSS project.
The six RSS projects reviewed represent a significant portion of the global output of open source robotic software since the last 7 years. Put together they contain around 500 kSLOC. According to the classification, 67% of the total contains code which could be RSF independent and only 4% actually is.
Now it takes a step back from individual projects and tries to visualize how they all fit together. The marketplace of reusable robotics software as we see it today, While it has a layered horizontally structure at the level of operating system or OS and communication middleware, it is partitioned vertically at the level of robotic software. This partitioned structure reflects the common concern about the lack of inter-operation between different RSS projects.
There is a notable exception within the reviewed RSS projects, the Kinematics Dynamic and Bayesian Filtering libraries distributed by the Orocos project and classified as pure DA code. The libraries which distributed by the OpenSLAM project the figure contain another block of DA code. These are shown as an example of robotic software which is not part of any specific RSS project.
The six RSS projects reviewed represent a significant portion of the global output of open source robotic software since the last 7 years. Put together they contain around 500 kSLOC. According to the classification, 67% of the total contains code which could be RSF independent and only 4% actually is.
Now it takes a step back from individual projects and tries to visualize how they all fit together. The marketplace of reusable robotics software as we see it today, While it has a layered horizontally structure at the level of operating system or OS and communication middleware, it is partitioned vertically at the level of robotic software. This partitioned structure reflects the common concern about the lack of inter-operation between different RSS projects.
Source Code Make up of RSS Project
Each RSS recently is a self contained universe concerned with all aspects of building robotic systems. The observation is each RSS project contains a mix of three types of software:
1. DA (Driver and Algorithm Implementations).
2. CM (Communication Middleware).
3. RSF (Robotic Software Framework).
Most RSS projects contain a certain modularity of element, either at the level of run time components or as a plug in device driver architecture. The way in which these modules are defined, implemented and operated is captured in the RSF definition. The RSF style defines an individual RSS project more than anything else. Because of this, the code of RSF is not attractive in terms of reuse. This category includes the tool required to operate a robotic system, e.g. logging, visualization, simulation etc, in addition to the actual frame code. These tools are tied intimately to the RSF implementation and can not be reused across projects by necessity.
All reviewed projects are distributed and use some communication middleware, either general purpose off the shelf or custom. The custom communication libraries tend not to be reusable because they are coupled tightly to the RSF. The general purpose middleware, while highly reusable is used typically by the robotic community rather than maintained or written by it.
At the end, there is the part of the source code which encapsulates the domain knowledge of robotics. The two main categories of this software types are hardware drivers, i.e. for actuators and sensors, and algorithm implementations, i.e. algorithm for mapping, path planning, localization, etc. the critical property of this software category is that the underlying concept, algorithm specification and hardware protocols, are independent from software module definition and inter module communication.
Finally, we will argue that RSF independent DA code has the highest reuse value and we will examine its role in improving reuse between the RSS projects.
1. DA (Driver and Algorithm Implementations).
2. CM (Communication Middleware).
3. RSF (Robotic Software Framework).
Most RSS projects contain a certain modularity of element, either at the level of run time components or as a plug in device driver architecture. The way in which these modules are defined, implemented and operated is captured in the RSF definition. The RSF style defines an individual RSS project more than anything else. Because of this, the code of RSF is not attractive in terms of reuse. This category includes the tool required to operate a robotic system, e.g. logging, visualization, simulation etc, in addition to the actual frame code. These tools are tied intimately to the RSF implementation and can not be reused across projects by necessity.
All reviewed projects are distributed and use some communication middleware, either general purpose off the shelf or custom. The custom communication libraries tend not to be reusable because they are coupled tightly to the RSF. The general purpose middleware, while highly reusable is used typically by the robotic community rather than maintained or written by it.
At the end, there is the part of the source code which encapsulates the domain knowledge of robotics. The two main categories of this software types are hardware drivers, i.e. for actuators and sensors, and algorithm implementations, i.e. algorithm for mapping, path planning, localization, etc. the critical property of this software category is that the underlying concept, algorithm specification and hardware protocols, are independent from software module definition and inter module communication.
Finally, we will argue that RSF independent DA code has the highest reuse value and we will examine its role in improving reuse between the RSS projects.
The Standardization of Interoperation Robotic Software
The implicitly and explicitly stated goal of several past and present standardization initiatives is to increase reuse software by enabling inter-operation between software from different RSS projects.
One possible solution is to achieve complete inter-operation by standardizing on a single way of building systems. While this approach may be appropriate for the military, mandates like this are not as effective in academics environments, especially when none of the existing solution is superior clearly. The multiple operating system existence, programming language and communication middleware packages also suggest that a one size fits all solution to building robotic systems may be undesirable and unachievable.
Another option is to enable communication between software from different RSS projects without modifying the individual projects. This can be done with translators custom designed for each application or with a more general software bridge. However custom solutions of this type tend to be too specific to be reusable and a generic bridge between middleware instances is a technical challenge. Beside, this approach requires extra effort during system operation as the user is asked to execute several systems and different types of infrastructure simultaneously.
It tries to show that diversity or lack of standards in approaches to building robotic system is not a problem itself. In fact it can be advantageous as long as it does not stand in the way of reuse software. We will argue that the bulk of the robotic software can be written in a way which makes it independent from the specific particular RSS and therefore reusable across multiple projects.
It expresses the approach in long term objectives for the open source robotic community:
1. Achieve a dramatic increase in the quantity and quality of available software which can be readily recombined for a particular application.
2. Maintain flexibility in how this recombination can be achieved.
One possible solution is to achieve complete inter-operation by standardizing on a single way of building systems. While this approach may be appropriate for the military, mandates like this are not as effective in academics environments, especially when none of the existing solution is superior clearly. The multiple operating system existence, programming language and communication middleware packages also suggest that a one size fits all solution to building robotic systems may be undesirable and unachievable.
Another option is to enable communication between software from different RSS projects without modifying the individual projects. This can be done with translators custom designed for each application or with a more general software bridge. However custom solutions of this type tend to be too specific to be reusable and a generic bridge between middleware instances is a technical challenge. Beside, this approach requires extra effort during system operation as the user is asked to execute several systems and different types of infrastructure simultaneously.
It tries to show that diversity or lack of standards in approaches to building robotic system is not a problem itself. In fact it can be advantageous as long as it does not stand in the way of reuse software. We will argue that the bulk of the robotic software can be written in a way which makes it independent from the specific particular RSS and therefore reusable across multiple projects.
It expresses the approach in long term objectives for the open source robotic community:
1. Achieve a dramatic increase in the quantity and quality of available software which can be readily recombined for a particular application.
2. Maintain flexibility in how this recombination can be achieved.
Subjective Evaluation Result in Robotic Software Reuse
Systematic software reuse in general is not an easy task and the robotic field is no exception. Yet some of the RSS projects are over seven years old, long enough to draw some conclusions. There has been undeniable progress in both software availability and in understanding in the community needs. But the result, from the point of view of day to day experience working with the robots have been underwhelming. The following problems laundry list is the result of subjective evaluation.
1. Slow growth; the main measure success of a project dedicated to software reuse in the reusable amount software it contains. In this respect, the projects of RSS show steady but growing slowly.
2. Fragmentation and duplication of efforts; very few developers contribute to more than a project. Basic robotic functionality implementation is replicated in each RSS project and is not reused across projects.
3. Poor software quality; hardware drivers are often of lack functionality and substandard reliability. Algorithms are aged and are not optimized for performance.
4. Software lock-in; software written to the API (application programming interfaces) which are unique to a particular RSS project is lock in. an organization or an individual who has contributed to the one project can not easily move their investment to another one. Ironically, this drawback is associated typically with proprietary rather than open source software.
5. Difficulty in making comparisons; numerous report have tried to compare different ways of building the systems of robotic, which in practice reduces to a comparison between RSS projects. Given the complexity of the task and fundamental differences in solution approaches, this inevitably leads to a comparison between “oranges and apples”.
Nothing indicates the above problems mentioned will not continue into the future. It mentions two more negative trends which are relatively new: danger from commercial alternatives and danger of irrelevance to the state of the robotic art.
1. Slow growth; the main measure success of a project dedicated to software reuse in the reusable amount software it contains. In this respect, the projects of RSS show steady but growing slowly.
2. Fragmentation and duplication of efforts; very few developers contribute to more than a project. Basic robotic functionality implementation is replicated in each RSS project and is not reused across projects.
3. Poor software quality; hardware drivers are often of lack functionality and substandard reliability. Algorithms are aged and are not optimized for performance.
4. Software lock-in; software written to the API (application programming interfaces) which are unique to a particular RSS project is lock in. an organization or an individual who has contributed to the one project can not easily move their investment to another one. Ironically, this drawback is associated typically with proprietary rather than open source software.
5. Difficulty in making comparisons; numerous report have tried to compare different ways of building the systems of robotic, which in practice reduces to a comparison between RSS projects. Given the complexity of the task and fundamental differences in solution approaches, this inevitably leads to a comparison between “oranges and apples”.
Nothing indicates the above problems mentioned will not continue into the future. It mentions two more negative trends which are relatively new: danger from commercial alternatives and danger of irrelevance to the state of the robotic art.
Robotic Decisional Architectures
Components are blocks of software building, each with specific functionality, which the user can assemble to achieve the robot global functionality; they have a standardized way to exchange information between each other so that they can be connected together. Components are executables; they represent an encapsulation of the notion of threads and process. They will be dedicated typically to a particular actuator and sensor, but this is not mandatory. They can also provide high level services and abstract and rely on data produced by other components.
Components execute their functionality or “deliver their services” independently of the context in which they are used, e.g. without having to know during design and implementation who is going to use its service and how they are going to be used. The independence of the component is a guide to decide what functionality should be put in the “grain size”, but this is not absolute, this choice is left to developer.
The services provided by the components are activated by external entities according to the task requirement and the execution context in order to accomplish tasks. The sequences of services can be activated directly by a human operator, planned and triggered by decisional components or more generally by event generated elsewhere in the system. It is important to stress that this structuring does not presuppose any decisional architectures, the way components are connected together is not specified nor forced. The controllable components can be used for implementing any architectures of decisional form behavior based to supervised and planned approaches. The same set components can be served different purposes when reused in different architectures.
They have defined three main entities that compose them, an execution engine, a set of algorithms, and a communication library in order to make components implementation independent and hence portable either from one robot to another or between decisional architectures.
Components execute their functionality or “deliver their services” independently of the context in which they are used, e.g. without having to know during design and implementation who is going to use its service and how they are going to be used. The independence of the component is a guide to decide what functionality should be put in the “grain size”, but this is not absolute, this choice is left to developer.
The services provided by the components are activated by external entities according to the task requirement and the execution context in order to accomplish tasks. The sequences of services can be activated directly by a human operator, planned and triggered by decisional components or more generally by event generated elsewhere in the system. It is important to stress that this structuring does not presuppose any decisional architectures, the way components are connected together is not specified nor forced. The controllable components can be used for implementing any architectures of decisional form behavior based to supervised and planned approaches. The same set components can be served different purposes when reused in different architectures.
They have defined three main entities that compose them, an execution engine, a set of algorithms, and a communication library in order to make components implementation independent and hence portable either from one robot to another or between decisional architectures.
CoolBOT Demonstrates on Activ Media Robotics
CoolBOT has been conceived to promote incremental, integrability design and robustness of software developments in robotics. A simple demonstrator shown to illustrate how such principles manifest in systems built using CoolBOT. It has been implemented and tested using a pioneer 2DX robot from Activ Media Robotics. It illustrates how a mobile robot can be endowed with different capabilities by means of integrating components in an incremental way using CoolBOT. Thus initially the robot will only be able to avoid obstacles moving away from them and it will end up with a wanderer behavior with obstacle avoidance.
The demonstrator consists of two components: the PF Avoiding and the Pioneer components. The Pioneer component is a component that encapsulates the set of effectors and sensors provided by Activ Media Robotics Pioneer robot. The PF Avoiding component makes use of a potential approach using repulsive potential fields to perform obstacles avoidance using sonar robot reading as sensory information. When this component configuration is executed in the robot, the observable behavior is that the robot remains still if there are no obstacle close enough. The robot will move away in the event that an obstacle gets closer. This behavior could allow a people to herd the robot, as the robot behaves in order to keep itself far enough from obstacles.
In the second and last level of demonstrator which adds two components on top of avoiding level presented the Strategic PF and Wander components. The Strategic PF is a components that uses like the PF Avoiding, a potential field approach to implement several behaviors, namely “a move” behavior using an uniform potential field, a “go to” behavior making use of an attractive potential field, and a “docking” behavior utilizing a “docking” potential field. This component feeds periodically the PF Avoiding with strategic potential field vectors. The PF Avoiding adds these vectors of strategic to the repulsive potential field.
The demonstrator consists of two components: the PF Avoiding and the Pioneer components. The Pioneer component is a component that encapsulates the set of effectors and sensors provided by Activ Media Robotics Pioneer robot. The PF Avoiding component makes use of a potential approach using repulsive potential fields to perform obstacles avoidance using sonar robot reading as sensory information. When this component configuration is executed in the robot, the observable behavior is that the robot remains still if there are no obstacle close enough. The robot will move away in the event that an obstacle gets closer. This behavior could allow a people to herd the robot, as the robot behaves in order to keep itself far enough from obstacles.
In the second and last level of demonstrator which adds two components on top of avoiding level presented the Strategic PF and Wander components. The Strategic PF is a components that uses like the PF Avoiding, a potential field approach to implement several behaviors, namely “a move” behavior using an uniform potential field, a “go to” behavior making use of an attractive potential field, and a “docking” behavior utilizing a “docking” potential field. This component feeds periodically the PF Avoiding with strategic potential field vectors. The PF Avoiding adds these vectors of strategic to the repulsive potential field.
The Standardization of Framework Software Robotic
Particular aspects of robotics systems have been studied for about three decades: perception, locomotion, environment modeling, trajectory planning, reasoning and all AI aspects. The state of the art contains a really huge amount of contribution on those domains and some real robots are appearing progressively and making their way toward to general public. However, such systems remain most of the time prototypes of laboratory. If the feasibility of certain tasks is proven, it is still very difficult to share between labs or reuse the developments of software that have been done on those robots.
The reason for that is certainly the standard lack specification for robotic software developments. Indeed, robots are still very far from the standardization of traditional computer science engineering, workstation of PCs, that has undoubtedly permitted their development; although the same program would not run as is on different architectures, or format files change in almost every new application, POSIX or UNIX have done much regarding the API and portability and behavior of a large amount of kernels is known well and defined well.
Hence, an issue for robotic research is not only to develop particular functionalities, but also to define and conceive a generic robot, e.g. a robot that not only has a standard kernel, but also defined well model of components that will implement functionalities. This will not only permit the complex conception robots, but also to reuse, share and capitalize existing and known well functionalities.
Some robotic companies have proposed software frameworks to tackle this problem. Notable contributions are Adept and ABB, iRobot and their Mobility framework or Activ Media and Saphira. However these frameworks are not much opened for instance the code is often proprietary nor extensible, in the sense that they were made for the few robots sold by these companies. These frameworks can still let developers conceive very complex autonomous machines, but they would be fixed usually and pre defined in term of missions and sensors.
The reason for that is certainly the standard lack specification for robotic software developments. Indeed, robots are still very far from the standardization of traditional computer science engineering, workstation of PCs, that has undoubtedly permitted their development; although the same program would not run as is on different architectures, or format files change in almost every new application, POSIX or UNIX have done much regarding the API and portability and behavior of a large amount of kernels is known well and defined well.
Hence, an issue for robotic research is not only to develop particular functionalities, but also to define and conceive a generic robot, e.g. a robot that not only has a standard kernel, but also defined well model of components that will implement functionalities. This will not only permit the complex conception robots, but also to reuse, share and capitalize existing and known well functionalities.
Some robotic companies have proposed software frameworks to tackle this problem. Notable contributions are Adept and ABB, iRobot and their Mobility framework or Activ Media and Saphira. However these frameworks are not much opened for instance the code is often proprietary nor extensible, in the sense that they were made for the few robots sold by these companies. These frameworks can still let developers conceive very complex autonomous machines, but they would be fixed usually and pre defined in term of missions and sensors.
Robotic Reusable Software
Currently reusable robotics software is provided by several self contained open source projects with virtually no software reuse between them. Such partitioning leads to problems with software quality, quantity, ease evaluation and, ultimately, to poor end user experience. By reviewing of several of the projects it observes that all of them contain a mix of three types of software:
1. Driver and algorithm implementations.
2. Communication middleware.
3. Robotic software framework.
It shows that more than half of the combined code base contains software which could be reusable highly but only a small fraction of it actually is.
It argues that formal separation of the three groups in the existing and future software project would offer several potential advantages. Framework independent code availability would enable community wide library based software reuse in addition to the existing framework wide components based reuse. Another important benefit is related to procedure evaluation. The three software types are different and should be evaluated separately using different criteria. The first of two types allow quantitative comparisons which are documented well in the literature. The last one is the largest qualitative and therefore more subjective.
Software reuse in the field of robotic has been a popular topic for a number of reasons. The application domain is characterized and complex by large variability in software and hardware configurations. As a result, virtually every new system requires custom design. The sheer amount of software necessary for even the most basic competency is a quite large. These factors make reuse software attractive e.g. one hopes to integrate existing software modules within a software framework. Key of the success of the approach is reusable software availability.
The marketplace for reusable software robotic is dominated by open source offering primarily originating from and used by academic institutions. These efforts are organized into projects; Orocos, Player, Carmen, Orca, Yarp, several of which are hosted on SourceForge, net.
1. Driver and algorithm implementations.
2. Communication middleware.
3. Robotic software framework.
It shows that more than half of the combined code base contains software which could be reusable highly but only a small fraction of it actually is.
It argues that formal separation of the three groups in the existing and future software project would offer several potential advantages. Framework independent code availability would enable community wide library based software reuse in addition to the existing framework wide components based reuse. Another important benefit is related to procedure evaluation. The three software types are different and should be evaluated separately using different criteria. The first of two types allow quantitative comparisons which are documented well in the literature. The last one is the largest qualitative and therefore more subjective.
Software reuse in the field of robotic has been a popular topic for a number of reasons. The application domain is characterized and complex by large variability in software and hardware configurations. As a result, virtually every new system requires custom design. The sheer amount of software necessary for even the most basic competency is a quite large. These factors make reuse software attractive e.g. one hopes to integrate existing software modules within a software framework. Key of the success of the approach is reusable software availability.
The marketplace for reusable software robotic is dominated by open source offering primarily originating from and used by academic institutions. These efforts are organized into projects; Orocos, Player, Carmen, Orca, Yarp, several of which are hosted on SourceForge, net.
Software Components for Robotic Programming
The latest trends in software engineering are exploiting the software idea components as the basic units of development and deployment when building complex software systems, specially if modular composition, software reuse, an third party software integration are important issues. Out of multiple definitions for software components we can chose the following definition:
“A software component is a composition unit with contractually specified interfaces and explicit only context dependencies. A software component is subject to composition by third parties and can be independently deployed.”
A software component is a piece of software that has been independently developed from where it is going to be used. It should offer a well external interface that hides its internals, and it is independent of context. It can be deployed without modifications by third parties. It also needs to come with a clear specification of what it requires and provides to be composed with other components.
In here will introduce a component oriented framework for programming robotic system called as CoolBOT that allows designing systems in terms of integration and composition of software components. The framework provides means to design and build components and to compose and integrate them hierarchically and dynamically.
CoolBOT is a component oriented C++ framework where the software that controls a system is viewed as a unit dynamic network of execution inter-connected by means of data paths. Each one of these execution units is a software component which provides a given functionality, hidden behind an external interface specifying clearly which data it needs and which data it produces.
Components may be instantiated, integrated and used as many times as needed in other systems once defined and built. The framework provides the necessary infrastructure to support this concept of component software and the inter communication between them by data paths means which can be established and de-established dynamically.
“A software component is a composition unit with contractually specified interfaces and explicit only context dependencies. A software component is subject to composition by third parties and can be independently deployed.”
A software component is a piece of software that has been independently developed from where it is going to be used. It should offer a well external interface that hides its internals, and it is independent of context. It can be deployed without modifications by third parties. It also needs to come with a clear specification of what it requires and provides to be composed with other components.
In here will introduce a component oriented framework for programming robotic system called as CoolBOT that allows designing systems in terms of integration and composition of software components. The framework provides means to design and build components and to compose and integrate them hierarchically and dynamically.
CoolBOT is a component oriented C++ framework where the software that controls a system is viewed as a unit dynamic network of execution inter-connected by means of data paths. Each one of these execution units is a software component which provides a given functionality, hidden behind an external interface specifying clearly which data it needs and which data it produces.
Components may be instantiated, integrated and used as many times as needed in other systems once defined and built. The framework provides the necessary infrastructure to support this concept of component software and the inter communication between them by data paths means which can be established and de-established dynamically.
Robotic Software Programming
Currently, there are no clear programming paradigms programming robotic systems, according to some authors the programming techniques which are common use today are not adequate to seal with the complexity associated with these systems. One aspect where the complexity clearly come up is integration of software. It is necessary to integrate a wide variety of software in a given normally; software dealing with hardware (such as, effectors, sensors, and others hardware), third party software, software which is not very portable because it is specific to a particular machine or operating system (or both), software done in distinct programming languages. Traditional software integration has been an underestimated problem in robotics, and it is frequently a question to which it is necessary to invest much more effort than considered initially.
Integration of software system is a task demanding so many resources that only a few research groups can afford it. It seems evident that fostering cooperation and code reuse between different research groups would be the more convenient solution, but in a practice, it has been very seldom to see research groups importing systems or architectures that has been developed by others.
Recycling and reuse of code across laboratories is difficult and recently not very common. It is clear that robotics need to develop an experimental methodology that promotes the integration and reproduction of results and software between different research groups. The approaches originated by distinct groups have not been designed to be integrated together, and the software usually for control robotic system is not easy to use software. Its use and learning is not trivial, and getting to a level of expertise high enough to have productive results takes long time. All drives frequently to develop home made software the specific necessities of each group. Other authors have made similar considerations identifying the software architectures building as the way the robotics community has chosen mainly to address the problem.
Integration of software system is a task demanding so many resources that only a few research groups can afford it. It seems evident that fostering cooperation and code reuse between different research groups would be the more convenient solution, but in a practice, it has been very seldom to see research groups importing systems or architectures that has been developed by others.
Recycling and reuse of code across laboratories is difficult and recently not very common. It is clear that robotics need to develop an experimental methodology that promotes the integration and reproduction of results and software between different research groups. The approaches originated by distinct groups have not been designed to be integrated together, and the software usually for control robotic system is not easy to use software. Its use and learning is not trivial, and getting to a level of expertise high enough to have productive results takes long time. All drives frequently to develop home made software the specific necessities of each group. Other authors have made similar considerations identifying the software architectures building as the way the robotics community has chosen mainly to address the problem.
CoolBOT Port Automata
Components are modeled as Port Automata in CoolBOT. This concept establishes a clear distinction between the internal functionality a pf an active entity, its set of input and output port, the automation and its external functionality. The active components entities which carry out specific tasks and perform all external communication by means of their input and output ports. Components cat their own initiative, running in concurrently or parallel, and are normally weakly coupled, e.g. no acknowledgements are necessary when they communicate through their ports.
CoolBOT components inter communicate and interact each other by means of port connections established among their input and output ports. Data are transmitted through connections port in discrete units called port packets. Port packets are defined as units of discrete of information which can be received through input ports, and/or issued through output ports. Port packets are also classified by their type, and usually port of input and output can only accept a specific set of port packet types.
To establish a port connection both input and output ports must be compatible, e.g. both ports must match exactly the port packets type they can accept. Components should be observable enough to know whether they are working correctly or not and in that case they should be controllable to make some adjustment in their internal behavior to adjust and regulate their operation. CoolBOT introduces of two kind variables as facilities in order to support control and monitoring of components:
• Observable variables; represent components features that should be of interest from outside, they are externally observable and permit publishing aspects components which are meaningful in terms of control, or just for monitoring or observability purposes.
• Controllable variables; represent components aspects which can be externally controlled, such as modified or updated. The components internal behavior can be controlled.
CoolBOT components inter communicate and interact each other by means of port connections established among their input and output ports. Data are transmitted through connections port in discrete units called port packets. Port packets are defined as units of discrete of information which can be received through input ports, and/or issued through output ports. Port packets are also classified by their type, and usually port of input and output can only accept a specific set of port packet types.
To establish a port connection both input and output ports must be compatible, e.g. both ports must match exactly the port packets type they can accept. Components should be observable enough to know whether they are working correctly or not and in that case they should be controllable to make some adjustment in their internal behavior to adjust and regulate their operation. CoolBOT introduces of two kind variables as facilities in order to support control and monitoring of components:
• Observable variables; represent components features that should be of interest from outside, they are externally observable and permit publishing aspects components which are meaningful in terms of control, or just for monitoring or observability purposes.
• Controllable variables; represent components aspects which can be externally controlled, such as modified or updated. The components internal behavior can be controlled.
ARDev Mobile Robot Application
Developing mobile robot applications in the real world is difficult. ARDev is open source tool designed to create a shared perceptual space for human to see the world from a robots point view. This is achieved by augmenting a live video feed with virtual objects resulting in an Augmented Reality (AR) visualization toolkit used to visualize robot data. This project goal is to expand and improve ARDev so that it may become more widespread and ubiquitous within mobile robot development. The main contributions of this works are new features including runtime configuration of objects and views, control over a virtual camera and further modularization with the addition of plug-ins. Configuration of runtime allows the developer to change the visualized data depending on the particular sensor or visualization of interest. The virtual camera allows for different views of the same scene or data to increase the developers understanding of sensor data. Plug-ins provides a convenient extension point for further development. Overall the contributions have improved greatly ARDev for mobile robot development.
ARDev was initially built to interface with player and recently can visualize a core set of Player drivers. However with its modular software architecture, ARDev allows for other general augmented reality use. The AR system is intended to display visually robot data and provide an insight into the world from the robots perspective.
Player is a network device server oriented. Player provides transparent network access to various actuators and sensors. The Player modular architecture allows the creation of modules for any system that supports TCP/IP. Player provides a visualization tool which displays robot data, however this tool lacks the context of data for the visualizations and this limits its usefulness. The core functionality of ARDev show three lasers, color red, green, and blue overlaid on a camera feed. The pat of the robot is also shown in yellow.
ARDev was initially built to interface with player and recently can visualize a core set of Player drivers. However with its modular software architecture, ARDev allows for other general augmented reality use. The AR system is intended to display visually robot data and provide an insight into the world from the robots perspective.
Player is a network device server oriented. Player provides transparent network access to various actuators and sensors. The Player modular architecture allows the creation of modules for any system that supports TCP/IP. Player provides a visualization tool which displays robot data, however this tool lacks the context of data for the visualizations and this limits its usefulness. The core functionality of ARDev show three lasers, color red, green, and blue overlaid on a camera feed. The pat of the robot is also shown in yellow.
The Observation Result of Android Robot
Below are the results of observation to the android robot on the evaluation of gaze behavior and answers the questionnaire.
Uncanny valley
Many subjects mentioned that artificially of the android’s behavior, appearance and imbalance between behavior and appearance on the questionnaire. The artificiality of eye motion in particular may cause an increase the fixations number on the android’s eyes. The high of frequency of fixation could represent the uncanny valley. It is necessary to ascertain whether subjects provide fewer fixations on a robot that has robotic appearance to examine this prediction, such as ASIMO. The hypothesis that the frequency of fixations is represents the evaluation of communication, and the evaluation varies inversely with the frequency.
Eye contact
Some subjects mentioned that they could not make eye contact to the android robot. It is considered that the eye contact lack causes the uncanniness. Some psychological researchers show that eye contact can serve a function variety in human to human communication. It is estimated that eye contact and android’s appearance work synergistically to enhance communication. It will compare with a robot that has a robotic appearance and no eye contact behavior to ascertain this.
Contingent motion
One subject answered that the android with motion was uncanny than the still android because the motion was not contingent. Another subject mentioned that repeating same behavior was unnatural. It is possible that the lack contingent motion of android made no difference between the android with motion and the still android in the result. It is described as a contingent motion of non-human object varies an infant’s attitude. It is estimated that the android’s contingent motion provides an effect that work in synergy with its like human appearance.
Involuntary waving motion
One subject mentioned that it was uncanny that the still android was no moving only the head though human interlocutor, the android with motion was always moving the whole body slightly. It showed that the slight involuntary waving motion of a humanoid robot makes its behavior more natural.
Uncanny valley
Many subjects mentioned that artificially of the android’s behavior, appearance and imbalance between behavior and appearance on the questionnaire. The artificiality of eye motion in particular may cause an increase the fixations number on the android’s eyes. The high of frequency of fixation could represent the uncanny valley. It is necessary to ascertain whether subjects provide fewer fixations on a robot that has robotic appearance to examine this prediction, such as ASIMO. The hypothesis that the frequency of fixations is represents the evaluation of communication, and the evaluation varies inversely with the frequency.
Eye contact
Some subjects mentioned that they could not make eye contact to the android robot. It is considered that the eye contact lack causes the uncanniness. Some psychological researchers show that eye contact can serve a function variety in human to human communication. It is estimated that eye contact and android’s appearance work synergistically to enhance communication. It will compare with a robot that has a robotic appearance and no eye contact behavior to ascertain this.
Contingent motion
One subject answered that the android with motion was uncanny than the still android because the motion was not contingent. Another subject mentioned that repeating same behavior was unnatural. It is possible that the lack contingent motion of android made no difference between the android with motion and the still android in the result. It is described as a contingent motion of non-human object varies an infant’s attitude. It is estimated that the android’s contingent motion provides an effect that work in synergy with its like human appearance.
Involuntary waving motion
One subject mentioned that it was uncanny that the still android was no moving only the head though human interlocutor, the android with motion was always moving the whole body slightly. It showed that the slight involuntary waving motion of a humanoid robot makes its behavior more natural.
The Developed Android Robot
The Android robot that is developed as a prototype, named “Replied R1”. To make the appearance resemble humans closely, it made a mold of a girl, and chose a kind of silicon carefully that would make the skin feel human like. The appearance is a five years old Japanese girl. The prototype has nine DOFs in the head, one for mouth, five for the eyes, and three for the neck, and many free joints to make a posture. The motors (actuators) are all embedded inside the body.
The android robot uses the touch sensor is a strain rate force sensor. The mechanism is similar to human as it detects touch strength while the skin is deforming. The android robot has four sensors under the skin of the left arm. Only four sensors can measure the touch strength all over the left arm surface. These sensors of tactile enable various touch communications.
In the future, it will implement an android with the same number of joints as humans, vision sensors, auditory sensors and tactile sensors covering the whole body. The researchers investigated eye motion of people during a conversation with the android for quantitative evaluation of interaction. A semi-unconscious behavior evaluation such as eye motion can reveal facts that do not appear in qualitative evaluations, such as a questionnaire test.
To test the prediction, three types of interlocutors were prepared; A1. Human girl, A2 the android with mouth, eye, and neck motions, A3 the android too. The conversation was held in the small room, the experimenter behind the curtain controlled reactions of the android. A speaker produced the pre recorded voice of the android. A2 moves its mouth while talking and sometimes move its neck and blinked, but A3 was stationary when it was talking without any blinked or move its neck.
The android robot uses the touch sensor is a strain rate force sensor. The mechanism is similar to human as it detects touch strength while the skin is deforming. The android robot has four sensors under the skin of the left arm. Only four sensors can measure the touch strength all over the left arm surface. These sensors of tactile enable various touch communications.
In the future, it will implement an android with the same number of joints as humans, vision sensors, auditory sensors and tactile sensors covering the whole body. The researchers investigated eye motion of people during a conversation with the android for quantitative evaluation of interaction. A semi-unconscious behavior evaluation such as eye motion can reveal facts that do not appear in qualitative evaluations, such as a questionnaire test.
To test the prediction, three types of interlocutors were prepared; A1. Human girl, A2 the android with mouth, eye, and neck motions, A3 the android too. The conversation was held in the small room, the experimenter behind the curtain controlled reactions of the android. A speaker produced the pre recorded voice of the android. A2 moves its mouth while talking and sometimes move its neck and blinked, but A3 was stationary when it was talking without any blinked or move its neck.
Robotic Development on Behavior and Appearance
In current years, there has been much research and development of intelligent partner robots that can interact with humans in daily life, such as Honda ASIMO and Sony AIBO. Communications between the humans and the robots is emphasized in contrast to industrial robots performing specialized tasks. The intelligence of the robot is a subjective phenomenon that emerges during human-robot interaction. It is indispensable to reveal a principle of human-human and human-robot communication, that is, a principle of interaction for developing a partner robot and realizing its intelligence.
Some researchers have tackled this problem. For instance, Kanda and Scheeff evaluated how the behavior of their robots affects human-robot interaction by observing their interaction. These works have revealed gradually the effects of robot behavior on human-robot interaction. There is a possibility that robotic appearance distort our interpretation of its behavior. The appearance of the robot is one of its functions essentially; therefore the effect of appearance must be evaluated independently. It is generally difficult to isolate the effects of the behavior of robot. One way to discriminate is developing a robot whose appearance is same as humans.
To state the problem of the research, to tackle a fundamental problem of a robot behavior and appearance. It forms a fundamental hypothesis about the effect of a robot behavior and appearance using existing knowledge gained from practical or research experience. This research currently is in progress and only preliminary experimental results have been obtained.
The goal is to create a design methodology of robot appearance and behavior robot named “Robovie”. It is possible that the result depend on the appearance of Robovie because its robotic appearance influences the interaction.
There is a bottom-up approach to tackle this behavior versus appearance problem, in which the interaction is evaluated while enhancing incrementally the appearance or behavior of the robot. There is a top-down approach too, in which build initially a robot which has the same appearance and motion as humans and evaluate the interaction while removing some aspect of appearance or behavior.
Some researchers have tackled this problem. For instance, Kanda and Scheeff evaluated how the behavior of their robots affects human-robot interaction by observing their interaction. These works have revealed gradually the effects of robot behavior on human-robot interaction. There is a possibility that robotic appearance distort our interpretation of its behavior. The appearance of the robot is one of its functions essentially; therefore the effect of appearance must be evaluated independently. It is generally difficult to isolate the effects of the behavior of robot. One way to discriminate is developing a robot whose appearance is same as humans.
To state the problem of the research, to tackle a fundamental problem of a robot behavior and appearance. It forms a fundamental hypothesis about the effect of a robot behavior and appearance using existing knowledge gained from practical or research experience. This research currently is in progress and only preliminary experimental results have been obtained.
The goal is to create a design methodology of robot appearance and behavior robot named “Robovie”. It is possible that the result depend on the appearance of Robovie because its robotic appearance influences the interaction.
There is a bottom-up approach to tackle this behavior versus appearance problem, in which the interaction is evaluated while enhancing incrementally the appearance or behavior of the robot. There is a top-down approach too, in which build initially a robot which has the same appearance and motion as humans and evaluate the interaction while removing some aspect of appearance or behavior.
Fanuc Robotics of M-420iA and M-6iB/6S
Fanuc Robotics America, Inc. have built the flexibility and speed of its M-420iA and M-6iB/2HS material handling robots equipped with Fanuc’s V-500iA/2DV vision software and line tracking. The M-420iA robot is using Fanuc’s V-500iA/2DV vision to highlight the advantages of using visual line tracking to pick three location parts randomly from a moving conveyor. Visual line tracking gives the flexibility to handle multiple products on the same automation line, reducing changeover time, and eliminating the need for costly fixtures. The M6iB/2HS robot is using line tracking to pick parts one at a time at high speeds, and place each part into a chute. The parts are dropping from the chute back onto the conveyor at random orientations and locations.
Fanuc robotic has greater flexibility and speed. To meet that need, there is growing trend to equipped robots with vision systems. Vision reduces the cost significantly of fixturing and collating, and increase customer ability to change to a new product quickly.
Recently Fanuc robotics introduced the M-6iB/6S robot arm solution. The Solution Arm is the latest member of the popular series of M-6iB/6S, which offers several model variations and enhanced performance options to meet the needs of customers with high speed, light weight applications for assembly, picking and packing, and part transfer.
The variations and enhancements to the series of M-6iB/6S raise the bar for high speed motion. While computing the articulated robots may be able to achieve these rates for short duration bursts, the High Duty variation of the series of M6iB/6S allows it to maintain high speeds for extended periods.
The six axis of M6iB/6S is a better alternative to used high speed commonly SCARA and Cartesian robots. The speed combined with flexibility makes the great value of M-6iB/6S. The M-6iB/2HS is a high speed variant optimized for applications with weight of 2 kg that require extremely rapid pick and place operations, such as picking, packing or part transfer. This model variation is revised from drive trains and motors for best in class speed.
Fanuc robotic has greater flexibility and speed. To meet that need, there is growing trend to equipped robots with vision systems. Vision reduces the cost significantly of fixturing and collating, and increase customer ability to change to a new product quickly.
Recently Fanuc robotics introduced the M-6iB/6S robot arm solution. The Solution Arm is the latest member of the popular series of M-6iB/6S, which offers several model variations and enhanced performance options to meet the needs of customers with high speed, light weight applications for assembly, picking and packing, and part transfer.
The variations and enhancements to the series of M-6iB/6S raise the bar for high speed motion. While computing the articulated robots may be able to achieve these rates for short duration bursts, the High Duty variation of the series of M6iB/6S allows it to maintain high speeds for extended periods.
The six axis of M6iB/6S is a better alternative to used high speed commonly SCARA and Cartesian robots. The speed combined with flexibility makes the great value of M-6iB/6S. The M-6iB/2HS is a high speed variant optimized for applications with weight of 2 kg that require extremely rapid pick and place operations, such as picking, packing or part transfer. This model variation is revised from drive trains and motors for best in class speed.
Laboratory Activities with Robotic Control through Internet
It is difficult for those fields that require laboratory activities such as manufacturing, though distance education works for many fields of study. One usually has to travel to the lab investment of both time and expense of travel is a big concern for potential students in the field of manufacturing to be involved in laboratory activities.
The advancement of internet technology tools developed in 1990s made it possible to access a lab at long distance. It is called Online Laboratory. An online laboratory would be maximized by technology of remote control through internet. A major step in the control online came with experiments using the internet was done by Kuchlin at 1997 with Highrobot Telerobotics. A software model based on an object oriented concept that could interact remotely with program of robots.
Kuchlin also explored the extensive capabilities of Java with Internet Protocol and Transmission Control Protocol. The result was a Java program could run on arbitrary remote computer platforms interacting with a robotic control.
On 1998 Calkin and Parkin developed simulation tools for remotely controlled robots to access a remote manufacturing system through internet. The tools simulation for the robotic hardware were developed using Java and VRMWL 97 to create a desktop virtual reality environment. A VRML browser was developed by the researchers to enable a computer client to request transmission of web pages from the host computer.
Rodrigues and Bergerman attempted remote control operation on 1998 at the Automation Institute in Brazil. The Automation institute proposed the first Brazilian RCVVL (Robotics and Computer Vision Virtual Laboratory). The communication between the user and the remote laboratory was accomplished through an interface of graphical which was developed with Java and HTML (Hypertext Markup Language). By using it, users could access the remote laboratory without having to download executable source codes. The RCCVL utilized two cameras one on the ceiling laboratory and the other on top of the robot.
The advancement of internet technology tools developed in 1990s made it possible to access a lab at long distance. It is called Online Laboratory. An online laboratory would be maximized by technology of remote control through internet. A major step in the control online came with experiments using the internet was done by Kuchlin at 1997 with Highrobot Telerobotics. A software model based on an object oriented concept that could interact remotely with program of robots.
Kuchlin also explored the extensive capabilities of Java with Internet Protocol and Transmission Control Protocol. The result was a Java program could run on arbitrary remote computer platforms interacting with a robotic control.
On 1998 Calkin and Parkin developed simulation tools for remotely controlled robots to access a remote manufacturing system through internet. The tools simulation for the robotic hardware were developed using Java and VRMWL 97 to create a desktop virtual reality environment. A VRML browser was developed by the researchers to enable a computer client to request transmission of web pages from the host computer.
Rodrigues and Bergerman attempted remote control operation on 1998 at the Automation Institute in Brazil. The Automation institute proposed the first Brazilian RCVVL (Robotics and Computer Vision Virtual Laboratory). The communication between the user and the remote laboratory was accomplished through an interface of graphical which was developed with Java and HTML (Hypertext Markup Language). By using it, users could access the remote laboratory without having to download executable source codes. The RCCVL utilized two cameras one on the ceiling laboratory and the other on top of the robot.
ROTSE III Telescopic Robotic
The observation of a prompt optical flash from GRB 990123 demonstrated convincingly the value of autonomous robotic telescope systems. Pursuing a program of rapid follow up observation of gamma-ray bursts, the ROTSE (Robotic Optical Transient Search Experiment) has developed a next instrument generation, ROTSE III that will continue the search for fast optical transient. The entire of system was designed as an economical robotic facility to be installed at remote sites throughout the world. There are seven major system components: optical tube assembly, optics, CCD camera, telescope mount, environmental sensing and protection, enclosure, and data acquisition.
It was realized that progress in understanding GRBs (Gamma-Ray Bursts) would depend on accurate localizations only attainable at longer wavelengths. Following the failure of premature of the on board tape recorders on the Compton Gamma-Ray Observatory in 1992, to shift the real data transmission opened the window for ground base and fast response systems that could slew to designated targets within 10sec.
The first optical system to exploit this capability was the GROCSE-I wide field camera. The hardware was conceived originally under the aegis of the Strategic Defense Initiative as a bed of test for developing the technologies to locate rapidly hostile incoming missiles and launch appropriate countermeasures.
By the time the GROCSE collaboration obtained the use of this instrument in 1993, it had been neglected and abandoned for several years. The collaboration invested considerable effort in adapting this device to respond robotically to the GRB trigger messages relayed from the Goddard Space Flight Center alert system called the BACODINE (BATSE Coordinates Distribution Network), then it renamed with GCN (GRB Coordinates Network).
The device sensitivity was limited to m ~ 9 by the restricted angular acceptance of the fiber optic light guides that coupled the spherical focal surface to the image array intensifiers and the modest quantum efficiency of the intensifiers photocathode’s.
It was realized that progress in understanding GRBs (Gamma-Ray Bursts) would depend on accurate localizations only attainable at longer wavelengths. Following the failure of premature of the on board tape recorders on the Compton Gamma-Ray Observatory in 1992, to shift the real data transmission opened the window for ground base and fast response systems that could slew to designated targets within 10sec.
The first optical system to exploit this capability was the GROCSE-I wide field camera. The hardware was conceived originally under the aegis of the Strategic Defense Initiative as a bed of test for developing the technologies to locate rapidly hostile incoming missiles and launch appropriate countermeasures.
By the time the GROCSE collaboration obtained the use of this instrument in 1993, it had been neglected and abandoned for several years. The collaboration invested considerable effort in adapting this device to respond robotically to the GRB trigger messages relayed from the Goddard Space Flight Center alert system called the BACODINE (BATSE Coordinates Distribution Network), then it renamed with GCN (GRB Coordinates Network).
The device sensitivity was limited to m ~ 9 by the restricted angular acceptance of the fiber optic light guides that coupled the spherical focal surface to the image array intensifiers and the modest quantum efficiency of the intensifiers photocathode’s.
The Specification of Robotic Optical Transient Search Experiment-III
The optical design of ROTSE-III (Robotic Optical Transient Search Experiment-III) was strongly constrained by the demand for a compact instrument with a swing radius of not more than 29 inches, which could be well baffled against stray light and would be insensitive relatively to decollimation issues. A high premium was placed on anticipated and simplicity ease of optical manufacture, as the ROTSE-III program called for multiple copies to be constructed in a manner timely and at affordable cost.
Initial specifications for the camera or telescope outlined Cassegrain with a 450.0 mm diameter f/1.80 an all-refracting and primary mirror field corrector providing a final focal length of 850.0 mm with final focus located not more than 75.0 mm in front of the primary mirror vertex.
The specification also called for the inclusion of a flat broad pass-band colored glass space and filter for a Prontor magnetic E/64 shutter within the corrector field, as well as a flat fused silica vacuum Dewar window and a BFD (Back Focal Distance) not less than 7.7 mm. the image quality goal was to enclose 70% more of the incident energy inside a 13.5um diameter at all angles field and wavelength without refocus, with not more than 7 um of maximum rms lateral color over the full spectral range.
Optical optimization and modeling were done with his proprietary code, OARSA. Some of figures and subsequent image analysis presented here were computed with the available code commercially, ZEMAX, which provides a convenient independent assessment of the system.
The initial design exploration demonstrated that a refracting corrector composed of four free-standing powered lens element made of the same material would satisfy the requirements. Similar three element correctors were first suggested by R.A Sampson and algebraically pioneered by C.G Wynne. Aberration control as well as remarkable color corrections is achieved by adjusting the power ratios among the elements of lens.
Initial specifications for the camera or telescope outlined Cassegrain with a 450.0 mm diameter f/1.80 an all-refracting and primary mirror field corrector providing a final focal length of 850.0 mm with final focus located not more than 75.0 mm in front of the primary mirror vertex.
The specification also called for the inclusion of a flat broad pass-band colored glass space and filter for a Prontor magnetic E/64 shutter within the corrector field, as well as a flat fused silica vacuum Dewar window and a BFD (Back Focal Distance) not less than 7.7 mm. the image quality goal was to enclose 70% more of the incident energy inside a 13.5um diameter at all angles field and wavelength without refocus, with not more than 7 um of maximum rms lateral color over the full spectral range.
Optical optimization and modeling were done with his proprietary code, OARSA. Some of figures and subsequent image analysis presented here were computed with the available code commercially, ZEMAX, which provides a convenient independent assessment of the system.
The initial design exploration demonstrated that a refracting corrector composed of four free-standing powered lens element made of the same material would satisfy the requirements. Similar three element correctors were first suggested by R.A Sampson and algebraically pioneered by C.G Wynne. Aberration control as well as remarkable color corrections is achieved by adjusting the power ratios among the elements of lens.