CORBA Navigationin the ASys Robot Control TestbedRicardo Sanz ∗

∗UPM Autonomous Systems Laboratory and Center for Automation and Robotics.

Proposals for a final grade research project

The Robot Control Testbed (RCT) is a research platform that is partof the the ASLab ASys project. This document summarily describesthe RCT as a framework for performing final grade projects like PFC,TFM or TFG. Some specific project proposals are also described thatoffer a wide spectrum of possibilities ranging from embedded con-trol systems to software engineering for distributed AI or machineconsciousness.

Keywords | autonomy | robotics | engineering | consciousness

This document summarily describes the Robot Controltestbed (RCT) research platform that serves as frame-

work for a collection of final grade, student-sized projects.This is part of the research on robotics platforms for test-ing the developments in the ASys long term project on au-tonomous systems.

If you are interested in doing your PFC/TFG/TFM inASLab, please read this document and feel free to ask anyquestion to the ASLab coordinator (ricardo.sanz@upm.es).If you have special, new, challenging, personal ideas of whatto do, feel also free to suggest them as research possibilitiesfor your project.

Please have in mind that ASLab is a research organisa-tion that tries to build novel and sophisticated systems; andthis requieres a wide spectrum of knowledge and ability todeal with the unknown that usually requieres some audacity,courage and boldness from the student.

Engineering Autonomy: the ASys ProjectIn ASLab we do research on autonomous systems. You canfind more information in our website www.aslab.org. Au-tonomous systems are systems that are capable of sustainedprovision of a particular service even in the presence of majoruncertainties in the service demand, the context of service ex-ecution and the disturbances that the system may be sufferingfrom outside or even inside.

The Autonomous Systems Project(ASys) of the UPM Autonomous Sys-tem Laboratory (ASLab) tries to de-velop universal control technology forautonomy.

ASys

Our autonomy technology evolves from early attempts toapply artificial intelligence to control systems (Sanz, 1990),using recent theoretical achievements in the conceptualisationthe domain of perception (Lopez, 2007), or developments thatformalise them into usable software assets, such as an ontologyfor the engineering of autonomous systems (Bermejo-Alonso,2010).

ASys Project Vision. The project intends the creation of sci-ence and technology for universal autonomy. In this context,”universal” means that the technology shall be effective inaugmenting the level of autonomy of any kind of artifact in

any kind of mission (Sanz et al., 2000). This implies a widerange of (autonomous) systems to be considered in the re-search, from robots to industrial process plants or comput-ing systems placed in the cyberspace. Additionally, the ASysscience may serve as a systems-centric substrate for theoriesof natural autonomy that can explain how the human mindworks (Collier, 2002).

Tools from the AI field have been extensively exploredfor intelligent control in the past few decades, improving theadaptivity and efficiency of systems. However, as it has beenpointed out, they are usually valuable only for a restrictedtype of problems. Besides, a not negligible amount of tuningfor their application to the specific system is usually required.This means that: i) an important part of the adaptivity isstill determined at the design stage, and ii) the achieved so-lution is only partially reusable for other systems, and hardlytransferable to other domains.

The underlying ideas of the ASys approach are: i) toovercome the previous issues by moving the responsibility foradaptation from design time to system’s run time —i.e. mak-ing the system responsible of its own adaptation—, and ii)provide the solution in an architectural form, rather than analgorithmic one, so as to meet the non-functional requirementsthat appear in these systems.

Model-based Autonomy.The strategy proposed to addressadaptation at run-time is that of exploiting cognitive self-control loops, which are control loops based on knowledge.This knowledge is realised in the form of different models: ofthe system, of the environment, and of its mission. This iswhat we call the model-based view of cognition.

The pervasive model-based approach in ASys is two-folded: i) an ASys system will be built using models of itand ii) an ASys system will also exploit models of itself todrive its operation or behaviour. Model-based engineering andmodel-based behaviour then merge into a single driving con-cept: model-based autonomy. The main goal: the modelsthe system will use to control its behaviour will eventually bethose very same models used by engineers to build it.

Models thus constitute the core for our autonomous sys-tems research programme. Unified functional and structuralviews are considered critical for our research as they provideknowledge about both the intended and the expectable be-haviours of the system.

The obtained models will be exploited by means of com-mercial application engines or customised model executionmodules. Models will be exercised during runtime to derivethe most suitable actions to do. Models are the knowledgethat the autonomous agent will use to act properly.

About ASLabThe Autonomous Systems Laboratory is a research group focused on the generation of science andtechnology for robust autonomy. This is a technical property of systems that make them capable ofsustained provision of a particular service even in the presence of major uncertainties in the servicedemand, the context of service execution and the disturbances that the system may be sufferingfrom outside or inside. Find us at www.aslab.org.

www.aslab.org/documents/controlled/A-2014-003.pdf ASLAB March 19, 2014 A-003 v01 1–5

Views

Model

Metamodel

ICeSpecification

ICeDocumentation

ICeDesign

ICeSynthesis

ICeAsset

Management

ICeDeployment

Model

Metamodel

Engine Engine

Asset Base

OAsysOntology

PatternPattern

Pattern

Component

ComponentComponent

DomainOntologyDomainOntologyDomain

Ontology

Requirements

Documentation

ICeOperation

ASys-Vision-04

Autonomous System

Figure 1 – Tasks and products in the overall ASys vision (adaptedfrom (Sanz et al., 2008))

The ASys Architectural Approach. Focusing on the system’sarchitecture is focusing on the structural properties that con-stitute the more pervasive and stable properties of the system(Shaw and Garlan, 1996). Architectural aspects are what crit-ically determine the final capabilities of any information pro-cessing technology, such as control systems.

ASys’ seek for an architectural solution derives from itsintention to address all the domain of autonomy, and there-fore for the developed technology to be of general applicabil-ity, so it be usable to develop control systems for any plant,e.g. continuous process plants, air-traffic control or mobilerobots; and to meet the critical demands for dependabilityand survivavility, because they critically depend on the sys-tem’s architecture.

In addition, architecture-based development offers the fol-lowing advantages:

• Systems can be built in a rapid, cost-effective mannerby importing (or generating) externally developed compo-nents.

• It is possible to predict global qualities of the final systemby analysing the architecture.

• The development of product lines sharing the same archi-tectural design is easier and cheaper.

• Restrictions on design variability make the design processmore productive and less prone to faults.

ASys is thus interested in domain variations of architec-tural designs for their application to different autonomous sys-tems. A reference architecture is an architecture where thestructures and respective elements and relations provide tem-plates to derive concrete architectures in a particular domainor in a family of software systems, and can be expressed in areference architecture model.

The ASys approach is strongly conceptual and architecture-centric. The suitability of extant control and cognitive controlarchitectures and how they match the ASys research ideas

and developed products (ontologies, models, views, engines)shall be determined and possible adaptations and extensionsshall also be considered. The definition and the consolida-tion of architectural patterns that capture ways of organisingcomponents in functional subsystems is critical. As a gen-eralisation strategy, the different elements considered in theASys research programme will be assessed in different testbedsystems: mobile robots, a chemical reactor, etc.

An integrated approach to engineering autonomy. The strat-egy to follow to materialise the ASys vision is the construc-tion of a systems engineering framework (Johnson, 1997) thatcan support the engineering processes associated with theconstruction of autonomous systems. Figure 1 summarilydepicts the entities, tooling and activities involved in thisprocess. It integrates the previously discussed ideas: anarchitecture-centric design approach, a methodology to en-gineer autonomous systems based on models, and an assetbase of modular elements to fill in the roles specified in thearchitectural patterns.

The engineering process covers from the initial capture ofapplication requirements and domain knowledge, to the imple-mentation of the final product —i.e. the autonomous system.

The ASys vision suggests that the self-x competences(Sanz et al., 2005) that are necessary to increase system au-tonomy and resilience, can be based on the models used inthe engineering of the system. As depicted in figure 1, theautonomous system Model is transformed, by synthesis, in 1)the Autonomous System and 2) the run-time Model of itselfthat it uses during its operation.

The central part of figure 1 shows this process where theModel is transformed into the Autonomous System. The In-tegrated Control Environment (ICe) toolset shall be used toexploit an asset base to sustain this engineering process. Theasset base contains :

ASys Ontology: An ontology of the domain of general au-tonomous systems. This serves as the core ontological sub-strate for all ASys elements.

Domain Ontologies: Domain ontologies focused in the dif-ferent application domains of ASys. The two domains thatare the current focus of the work are process control sys-tems and mobile robotics.

Design Patterns: Reusable functional designs of subsys-tems of the autonomous agent.

Components: Reusable software implementations that canbe used to play the roles specified by the patterns.

The ICe tool supports several activities:

Specification: The specification of the ASys concerns theintended use and autonomy properties for the agent.

Design: The design specifies the architectural organizationof the agent using the ASys pattern language as designvocabulary.

Synthesis: The synthesis produces both the agent implemen-tation —obtaining components for the pattern roles— andthe run-time model —by means of model transformationmethods.

Documentation: The capture of all reference material thatmay remain somewhat hidden due to the automated natureof some of the processes.

Deployment: Deployment of the ASys and run-time modelsin real operational conditions.

Operation: Operation of the ASys through an RCP-baseduser interface.

Asset Management: Management of the asset base includ-ing incorporation of new assets specifically developed forconcrete applications.

2 www.aslab.org/documents/controlled/A-2014-003.pdf R. Sanz

The Robot Control TestbedASys technology tries to be universal, i.e. of applicability todifferent applications in different domains. The Robot ControlTestbed (RCT) is a collection of mobile robot systems that areused to test the technologies that we develop. In parallel, theProcess Control Testbed (PCT) is a continuous process controlsystem that we use to test the applicability of the technologyin the domain of industrial chemical processes. Al the projectproposal described here are related to the RCT.

The main robot robot that we have selected for the PCTis a well known Pioneer 2AT8 robot (see Figure 2). We callit Higgs.

The Pioneer 2AT-8 is a mobile robot made by ActivMe-dia Robotics. It is a skid-steering vehicle with lightweightaluminium body and four pneumatic wheels propelled by fourreversible DC motors, equipped with high-resolution opticalencoders for precise position and speed sensing and advanceddead-reckoning. Electronic devices aboard are controlled bya Hitachi H8S microcontroller. Additional computing boardsprovide extra computing capabilities for open implementationof on-board software.

Figure 2.2: Pioneer 2-AT8 (Higgs) with onboard systems

14 of 45 R-2010-008 v 0.1 Draft / Higgs Manual / ASLab.org

Figure 2 – The Higgs Pioneer 2AT robot.

The Pioneer 2AT robot has also other equipment that isused for different technology evaluation missions:

• Two sonar arrays, each with eight transducers that pro-vide object detection and range information for collisionavoidance.

• Two —frontal and rear— bumpers.• An stereo camera —sometimes replaced by a monocular

camera to explore alternative designs.• A laser rangefinder.• A GPS positioning system.• A compass and accelerometers.• Wireless communications.

With this robot we explore to what extent our autonomysoftware improves the performance of the robot in the execu-tion of its missions. In particular we explore to what extent,making Higgs self-aware can improve the robustness and re-silience of the robot (Sanz et al., 2007; Hernandez, 2013).

Higgs NavigationThe focus of this PFC is the re-engineering of the navigationsystems of the Higgs robot to guid it using a different kindof technology. The current implementation is based on theROS middleware and the purpose of this project is to re-buildit using the CORBA middleware. The reasons for this aretwofold:

Instead of developing the navigation system for Higgs fromscratch we used ROS navigation stacks developed by Marder-Epstein1. This package gives us a number of components tonavigate to a desired position, knowing an occupancy map ofthe environment and the initial position of the robot relativeto this map. It uses odometric information and informationabout the obstacles got from different sensors including a laserrangefinder and a kinect sensor.

DISAM&UPM) ) )))))Alberto)González)Martínez) ) 49)

4.2.4 Nodos$que$forman$el$sistema$)

4.2.4.1'Move_base')Al) navegar,) únicamente) basándonos) en) información) interna) de) odometría) sin)ninguna) referencia) externa) el) robot) acabará) completamente) perdido.) El)problema)principal)es)que)los)pequeños)errores)de)odometría)se)acumulan)a)lo)largo) del) tiempo) y) estos) pequeños) errores) instantáneos) suponen) enormes)errores)acumulativos) con)el)paso)del) tiempo.)Afortunadamente)el)mundo)de) la)robótica)lleva)muchos)años)trabajando)con)varias)formas)de)incorporar)marcas)u)otras)referencias)externas)a)la)navegación)del)robot.)))Podemos) definir) el) nodo)move_base) como) el) nodo) encargado) de) planificar) el)movimiento)y)de)mover)al)robot)a)un)objetivo)dentro)de)un)marco)de)referencia)definido.)Utiliza)un)sistema)de)planificación)basado)en)mapas)de)coste.)El)valor)de) coste) es) asignado) a) cada) celda) del) mapa) dependiendo) de) su) estado) de)ocupación.))El)paquete)move_base)implementa)una)ROS$action)(acción)de)ROS))para)permitir)al) robot) llegar) a) un) destino) objetivo.) Estas) ROS) action) nos) proveen) la)realimentación)mientras)se)monitoriza)el)progreso)en)torno)al)destino)objetivo.)El)paquete)move_base) incorpora)el)base_local_planner)que)combina)los)datos)de)odometría)con)los)datos)de)tanto)el)global)y)local$cost$maps)(mapa)de)costes)local)y)global).)El)plan)global)se)calcula)antes)de)que)el)robot)comience)a)moverse)al)siguiente) destino,) teniendo) en) cuenta) las) zonas) desconocidas) y) los) obstáculos.)Para)ser)capaz)de)mover)el)robot)el)local$planner)monitoriza)los)datos)de)entrada)del) sensor) y) elige) las) velocidades) lineares) y) angulares) adecuadas) para) los)distintos) segmentos) que) configuran) el) local$ path.) La) manera) en) que) se)implementan) los)diferentes)segmentos)del) local$path) es)altamente)configurable)como)veremos)a)continuación.))

))

Figura(:)Se)muestra)el)esquema)del)nodo)move_base)y)su)interfaz)con)el)resto)de)los)nodos)que)forman)el)sistema)

de)navegación.))

Figure 3 – An overview of the ROS navigation system for Higgs.

Read for example the PFC by Alberto Gonzlez that ad-dressed the different issues in the Higgs testbed Gonzalez(2013).

CORBification of the Higgs Navigation SystemThe purpose of this project is to develop a pure-CORBA vari-ant of the navigation system for Higgs.

CORBA is an standard for object-oriented middleware from the ObjectManagement Group.

www.corba.org

Using CORBA technology we can build distributed con-trol applications with an increased level of transparency Sanzand Alonso (2001). Additionally, the use of advanced CORBAspecifications (esp. the Real-time CORBA Specification) wecan obtain better control over the execution of the applica-tion Segarra (2005). It is important concerning the potentialrequirements for QoS Hill and Gokhale (2008).

CORBA is a well known middleware. Middleware is aterm used in distributed systems to refer to the software layerthat lies between the operating system and the application,enabling the various components of a system to communicate

1http://wiki.ros.org/navigation

R. Sanz ASLab March 19, 2014 A-003 v01 3

and manage data —ideally in a transparent fashion. Middle-ware is a complex layer that is used to simplify the develop-ment of complex distributed systems by making communica-tion easier while enabling software developers to focus on thecore implementation of the application (the so-called businesslogic). There are many software pieces —e.g. web servers, ap-plication servers, object request brokers, messaging systems,data distribution services, etc- that are called middleware be-cause they can support distributed application developmentand deployment.

CAlternatives to CORBAWe focus on CORBA due to its technological capabilities, butit is not the only possibility. Two alternatives to evaluate arei) the use of DDS (Pardo-Castellote, 2003) and ii) the use orReal-time Java (Basanta-Val and Garcia-Valls, 2014).

ReferencesBasanta-Val, P. and Garcia-Valls, M. (2014). A distributed

real-time java-centric architecture for industrial systems.Industrial Informatics, IEEE Transactions on, 10(1):27–34.

Bermejo-Alonso, J. (2010). OASys: An Ontology for Au-tonomous Systems. PhD thesis, Departamento de Au-tomatica, Universidad Politecnica de Madrid.

Collier, J. (2002). What is autonomy? International Journalof Computing Anticipatory Systems, 12:212–221.

Gonzalez, A. (2013). Implementacion de un banco de prue-bas para el marco de la arquitectura OM (the operativemind architecture). Proyecto Fin de Carrera. UniversidadPolitecnica de Madrid - Autonomous Systems Laboratory.

Hernandez, C. (2013). Model-based Self-awareness Patternsfor Autonomy. PhD thesis, Escuela Tecnica Superior de In-genieros Industriales - Universidad Politecnica de Madrid.

Hill, J. H. and Gokhale, A. (2008). Model-driven specifi-cation of component-based distributed real-time and em-bedded systems for verification of systemic QoS properties.In Parallel and Distributed Processing, 2008. IPDPS 2008.IEEE International Symposium on, pages 1–8.

Johnson, R. E. (1997). Frameworks = (components + pat-terns). Commun. ACM, 40(10):39–42.

Lopez, I. (2007). A Framework for Perception in AutonomousSystems. PhD thesis, Departamento de Automatica, Uni-

versidad Politecnica de Madrid.Pardo-Castellote, G. (2003). Omg data-distribution service:

architectural overview. In Distributed Computing SystemsWorkshops, 2003. Proceedings. 23rd International Confer-ence on, pages 200–206.

Sanz, R. (1990). Arquitectura de Control Inteligente de Pro-cesos. PhD thesis, Universidad Politecnica de Madrid.

Sanz, R. and Alonso, M. (2001). CORBA for control systems.Annual Reviews in Control, 25:169–181.

Sanz, R., Gomez, J., Hernandez, C., and Alarcon, I. (2008).Thinking with the body: Towards hierarchical scalable cog-nition. In Handbook of Cognitive Science: An EmbodiedApproach. Elsevier.

Sanz, R., Lopez, I., and Bermejo-Alonso, J. (2007). A ratio-nale and vision for machine consciousness in complex con-trollers. In Chella, A. and Manzotti, R., editors, ArtificialConsciousness, pages 141–155. Imprint Academic.

Sanz, R., Lopez, I., Bermejo-Alonso, J., Chinchilla, R., andConde, R. (2005). Self-x: The control within. In Proceedingsof IFAC World Congress 2005.

Sanz, R., Matıa, F., and Galan, S. (2000). Fridges, elephantsand the meaning of autonomy and intelligence. In IEEE In-ternational Symposium on Intelligent Control, ISIC’2000,Patras, Greece.

Segarra, M. J. (2005). CORBA Control Systems. PhD thesis,Universidad Politecnica de Madrid.

Shaw, M. and Garlan, D. (1996). Software Architecture. AnEmerging Discipline. Prentice-Hall, Upper Saddle River,NJ.

Ricardo SanzUPM Autonomous System Laboratorywww.aslab.orgwww.rsanz.com

Contact: ricardo.sanz@upm.es

aslab

4 www.aslab.org/documents/controlled/A-2014-003.pdf R. Sanz