Specifications of a device interface for service-oriented automation control components

Service-oriented paradigm is being used to develop distributed and reconfigurable control solutions for factory automation environments. Since service-oriented automation control components are logical entities that provide and consume services, they may have an interface that maps the logical processes into the actions of the representative physical mechatronics. The inter-connection with the physical hardware devices, namely accessing I/Os, is a crucial issue to achieve the vertical IT-enterprise integration in these service-oriented systems, covering the shop floor device control level. This paper describes a device interface approach, in the context of a service-oriented control architecture, in which High-level Petri nets are used as the control description to access to the physical device. The outgoing features of the solution allow integrating the physical behavior into the control of automation components and consequently thereby incorporate it in the modular service-oriented control architecture

Software variability in service robotics

Robots artificially replicate human capabilities thanks to their software, the main embodiment of intelligence. However, engineering robotics software has become increasingly challenging. Developers need expertise from different disciplines as well as they are faced with heterogeneous hardware and uncertain operating environments. To this end, the software needs to be variable—to customize robots for different customers, hardware, and operating environments. However, variability adds substantial complexity and needs to be managed—yet, ad hoc practices prevail in the robotics domain, challenging effective software reuse, maintenance, and evolution. To improve the situation, we need to enhance our empirical understanding of variability in robotics. We present a multiple-case study on software variability in the vibrant and challenging domain of service robotics. We investigated drivers, practices, methods, and challenges of variability from industrial companies building service robots. We analyzed the state-of-the-practice and the state-of-the-art—the former via an experience report and eleven interviews with two service robotics companies; the latter via a systematic literature review. We triangulated from these sources, reporting observations with actionable recommendations for researchers, tool providers, and practitioners. We formulated hypotheses trying to explain our observations, and also compared the state-of-the-art from the literature with the-state-of-the-practice we observed in our cases. We learned that the level of abstraction in robotics software needs to be raised for simplifying variability management and software integration, while keeping a sufficient level of customization to boost efficiency and effectiveness in their robots’ operation. Planning and realizing variability for specific requirements and implementing robust abstractions permit robotic applications to operate robustly in dynamic environments, which are often only partially known and controllable. With this aim, our companies use a number of mechanisms, some of them based on formalisms used to specify robotic behavior, such as finite-state machines and behavior trees. To foster software reuse, the service robotics domain will greatly benefit from having software components—completely decoupled from hardware—with harmonized and standardized interfaces, and organized in an ecosystem shared among various companies

Off-line programming industrial robots based in the information extracted from neutral files generated by the commercial CAD tools

In order for a robotic manipulator to perform useful work, it must be programmed to accomplish the desired task or motion cycle. Nowadays industrial robots generally require a tremendous amount of programming to make them useful. Their controllers are very sophisticated, the commercial robot programming environments are typically closed systems and the programming languages varies from manufacturer to manufacturer. Despite the great evolution of the industrial robots controllers, in the majority of the industrial applications, the robot programming is made, using one of the following ways: • Manual on-line programming; • Off-line programming; Manual on-line programming refers to physically teaching a robot the required trajectory, through interaction with teach pendant or other similar device (Lee & ElMaraghy, 1990). This programming kind presents the following disadvantages: very slow, it needs that the robot is available, difficulty in the handling of equipments, need some practice in the language used by the robot, and technical knowledge to understand the operation of the equipment. These disadvantages are very expensive in the industry because the productive process needs to stop for a long time. One simple approach to solve some disadvantages described above is the Off-line programming environments. These environments are based in graphical simulation platforms, in which the programming and execution process are shown using models of the real objects. Consequently, the robot programmer has to learn only the simulation language and not any of the robot programming languages. Other benefits in off-line programming environments include libraries of pre-defined high-level commands for certain types of applications, such as painting or welding, and the possibility to assess the kinematics feasibility of a move, thus enabling the user to plan collision-free paths. The simulation may also be used to determine the cycle time for a sequence of movements. These environments usually provide a set of primitives commonly used by various robots, and produce a sequence of robot manipulator language primitives such as ”move” or ”open gripper” that are then downloaded in the respective robot controllers. However, the off-line programming tools based in graphically 3D representation presents several problems in many industry applications, particularly, when the robot task or the robot trajectory needs frequent changes, for example: in welding applications where the configuration of the pieces to weld change frequently (the size, the shape, etc.); the robot painting and gluing applications can have similar problems. Nowadays, the CAD tools are often used in the industry to develop and to document the products and its manufacture. There are a lot of commercial CAD tools, like, AutoCAD, SolidWorks, Ideas and Cimatron, having each tool its own file format. However, it is possible to export the information of these pieces, in a neutral file format, namely: STL, IGES, STEP and SET formats. This work presents one solution for programming different robots based in the relevant information extracted from neutral files. The solution implemented was tested in the industrial robots Mitsubishi (Mitsubishi Move Master Industrial Robot) and ABB (model IRB 140 with IRC5 controller). This chapter is organized as follows: section 2 presents an overview about the format of neutral files (STL, IGS, STEP and SET); in the section 3, the algorithms for extraction of the relevant information from the neutral files are described; in the section 4, the developed tool for code generation for different industrial robots is presented; section 5 and 6 present the results and conclusions; section 7 presents future work.European Union Programme of High Level Scholarships for Latin America, Scholarship no. E04M033540BR - Programme ALBAN

Pushing the Boundaries of Spacecraft Autonomy and Resilience with a Custom Software Framework and Onboard Digital Twin

This research addresses the high CubeSat mission failure rates caused by inadequate software and overreliance on ground control. By applying a reliable design methodology to flight software development and developing an onboard digital twin platform with fault prediction capabilities, this study provides a solution to increase satellite resilience and autonomy, thus reducing the risk of mission failure. These findings have implications for spacecraft of all sizes, paving the way for more resilient space missions

Casier: Structures for Composing Tangibles and Complementary Interactors for Use Across Diverse Systems

International audienceCasiers are a class of tangible interface elements that structure the physical and functional composition of tangibles and complementary interactors (e.g., buttons and sliders). Casiers allow certain subsets of interactive functionality to be accessible across diverse interactive systems (with and without graphical mediation, employing varied sensing capabilities and supporting software). We illustrate examples of casiers in use, including iterations around a custom walk-up-and-use kiosk, as well as casiers operable across com- mercial platforms of widely varying cost and capability

Decoupling User Interface Design Using Libraries of Reusable Components

The integration of electronic and mechanical hardware, software and interaction design presents a challenging design space for researchers developing physical user interfaces and interactive artifacts. Currently in the academic research community, physical user interfaces and interactive artifacts are predominantly designed and prototyped either as one-off instances from the ground up, or using functionally rich hardware toolkits and prototyping systems. During this prototyping phase, undertaking an integral design of the interface or interactive artifact’s electronic hardware is frequently constraining due to the tight couplings between the different design realms and the typical need for iterations as the design matures. Several current toolkit designs have consequently embraced component-sharing and component-swapping modular designs with a view to extending flexibility and improving researcher freedom by disentangling and softening the cause-effect couplings. Encouraged by early successes of these toolkits, this research work strives to further enhance these freedoms by pursuing an alternative style and dimension of hardware modularity. Another motivation is our goal to facilitate the design and development of certain classes of interfaces and interactive artifacts for which current electronic design approaches are argued to be restrictively constraining (e.g., relating to scale and complexity). Unfortunately, this goal of a new platform architecture is met with conceptual and technical challenges on the embedded system networking front. In response, this research investigates and extends a growing field of multi-module distributed embedded systems. We identify and characterize a sub-class of these systems, calling them embedded aggregates. We then outline and develop a framework for realizing the embedded aggregate class of systems. Toward this end, this thesis examines several architectures, topologies and communication protocols, making the case for and substantial steps toward the development of a suite of networking protocols and control algorithms to support embedded aggregates. We define a set of protocols, mechanisms and communication packets that collectively form the underlying framework for the aggregates. Following the aggregates design, we develop blades and tiles to support user interface researchers

The icub software architecture: evolution and lessons learned

The complexity of humanoid robots is increasing with the availability of new sensors, embedded CPUs and actuators. This wealth of technologies allows researchers to investigate new problems like whole-body force control, multi-modal human-robot interaction and sensory fusion. Under the hood of these robots, the software architecture has an important role: it allows researchers to get access to the robot functionalities focusing primarily on their research problems, it supports code reuse to minimize development and debugging, especially when new hardware becomes available. But more importantly it allows increasing the complexity of the experiments that can be implemented before system integration becomes unmanageable and debugging draws more resources than research itself. In this paper we illustrate the software architecture of the iCub humanoid robot and the software engineering best practices that have emerged driven by the needs of our research community. We describe the latest developments at the level of the middleware supporting interface definition and automatic code generation, logging, ROS compatibility and channel prioritization. We show the robot abstraction layer and how it has been modified to better address the requirements of the users and to support new hardware as it became available. We also describe the testing framework we have recently adopted for developing code using a test driven methodology. We conclude the paper discussing the lessons we have learned during the past eleven years of software development on the iCub humanoid robot

On Software Quality-motivated Design of a Real-time Framework for Complex Robot Control Systems

Frameworks have fundamental impact on software quality of robot control systems. We propose systematic framework design aiming at high levels of support for all quality attributes that are relevant in the robotics domain. Design decisions are taken accordingly. We argue that certain areas of design are especially critical, as changing decisions there would likely require rewriting significant parts of the implementation. For these areas, quality-motivated solutions and benefits for actual applications are discussed. We illustrate and evaluate their implementations in our framework Finroc - after briefly introducing it. This includes a highly modular framework core and a well-performing, lock-free, zero-copying communication mechanism. Finroc is being used in complex and also in commercial robotic projects - which evinces that the approaches are suitable for real-world applications

Developing an architecture for a test sequencer

Testing is an important aspect of developing systems and products. It ensures quality of the product and that it works as it has been specified to work. Testing is a very expensive and time consuming process. It can be made more effective by automating it using test automation tools. In this work a test automation tool called DriveTest2 is developed. DriveTest2 is a test sequencer that can be used to test different kinds of devices. A test sequencer is a program that controls a test setup by creating command sequences to device under test and other devices in the test setup. DriveTest2 will be capable of data acquisition during tests. This data is used for monitoring the sequence and for test reports. DriveTest2 can be used for different kinds of testing such as verification, reliability, accelerated lifetime and stress testing. DriveTest2 will replace an existing software called DriveTest. DriveTest is replaced because it is hard to maintain and update, and there is no documentation. The objective of this work is to find out what kind of software archi tecture a test sequencer should have. DriveTest2 and its architecture is developed using an iterative development process. Develop ment starts from gathering and analyzing requirements for the software which was done in pre vious work. The first iteration of the architecture is created from these requirements. Then the first design and implementation of DriveTest2 is created and given to users to get feedback. According to the feedback and requirements, refinements to the architecture and implementa tion are made. Then this process is repeated until we have software that we are satisfied with. DriveTest2 is developed using C# programming language. DriveTest2 uses Model-View-View Model architectural pattern to separate user interface and business logic. The business logic of DriveTest2 is designed to be object-oriented and is modelled using UML class diagrams. Throughout the iterations the architecture and design are refined with changes to the initial architecture and new functionalities like new interfaces to handle device specific functionalities. As a result of this work, we have an iteration of DriveTest2 that is used in test laboratories with success. The software architecture of DriveTest2 enables DriveTest2 to satisfies its critical func tional and non-functional requirements. We can conclude that a test sequencer software archi tecture should be able to enable the software to satisfy its requirements, have decoupled com ponents with clear responsibilities, be flexible enough to accommodate changes to the architec ture during the development and be extensible so that new functionalities can be added and make use of abstraction to abstract lower-level components and the actual hardware.Testaaminen on tärkeä osa tuotteiden ja systeemien kehityksessä. Sillä varmistetaan, että tuote pystyy tekemään sille määritetyt asiat ja, että se on laadukas. Testaaminen on hyvin kallis ja aikaa vievä prosessi. Sitä voidaan tehostaa automatisoimalla käyttäen testiautomaa-tiotyökaluja. Tässä työssä kehitetään testiautomaatiotyökalu nimeltä DriveTest2. DriveTest2 on testisekvensseri, jota voidaan käyttää erilaisten laitteiden testaamiseen. Testisekvenssi on ohjelma, jolla voidaan ohjata testiympäristön laitteita luomalla sekvenssejä, jotka muo-dostuvat komennoista. DriveTest2 pystyy keräämään dataa sekvenssin ajon aikana. Tätä da-taa käytetään sekvenssin ajon monitorointiin ja testiraportissa. DriveTest2:sta voidaan käyt-tää erilaisissa testeissä kuten verifikaatio-, luotettavuus-, elinikä- ja stressitesteissä. Drive-Test2 korvaa olemassa olevan testisekvensserin nimeltä DriveTest. DriveTest korvataan, kos-ka sitä on vaikea ylläpitää ja päivittää ja siihen ei ole olemassa dokumentaatiota. Tämän työn tavoite on selvittää millainen ohjelmistoarkkitehtuuri testisekvensseri pitää olla. DriveTest2 ja sen ohjelmistoarkkitehtuuria kehitetään iteratiivisella kehitysprosessilla. Kehi-tys alkaa vaatimusten keräämisellä ja analysoinnilla, joka tehtiin aikaisemmassa työssä. Näi-den vaatimusten perusteella luodaan ensimmäinen versio ohjelmistoarkkitehtuurista. Tämän ohjelmistoarkkitehtuurin perusteella luodaan ensimmäinen iteraatio DriveTest2:sen toteu-tuksesta ja se annetaan käyttäjille saadaksemme palautetta. Palautteen ja vaatimusten pe-rusteella arkkitehtuuria ja toteutusta hiotaan paremmaksi. Tätä prosessia sitten toistetaan, kunnes todetaan, että ohjelmisto on riittävän hyvä. DriveTest2 kehitetään C# ohjelmointikielellä. DriveTest2 käyttää Model-View-ViewModel arkkitehtuurimallia erottaakseen käyttöliittymän muusta logiikasta. DriveTest2:sen logiikka on tehty olio-ohjelmoinnilla ja se on mallinnettu UML luokkakaavioilla. Iteraatioiden aikana Dri-veTest2:sen ohjelmistoarkkitehtuuria hiottiin paremmaksi muuttamalla aikaisempaa arkki-tehtuuria ja lisäämällä uusia toiminnallisuuksia kuten uusia rajapintoja hoitamaan laitekohtai-sia toiminallisuuksia. Työn tuloksena saatiin luotua iteraatio DriveTest2:sta, jota pystytään käyttämään testilabora-torioissa hyvällä menestyksellä. DriveTest2:sen ohjelmistoarkkitehtuuri pystyy mahdollista-maan, että DriveTest2 pystyy toteuttamaan sille määritetyt toiminnalliset ja ei-toiminnalliset vaatimukset. Voidaan päätellä, että testisekvensserin ohjelmistoarkkitehtuurin on pystyttävä mahdollistamaan sille määritettyjen vaatimusten täyttäminen. Sillä on oltava komponentejä, joilla on selvät vastuualueet, ja sen on hyödynnettävä abstraktointia varsinkin laitetasolla. Arkkitehtuurin on oltava joustava, jotta sitä voidaan muokata ja kehittää kehityksen aikana sekä lisäämään uusia toiminnallisuuksia