Farzan Yazdi Motlagh
email: farzan.yazdi@ias.uni-stuttgart.de

Peter Göhner
email: peter.goehner@ias.uni-stuttgart.de

Adaptive Human-Machine-Interface of Automation Systems

Keywords: human-machine-interaction, usability, adaptive user interface, context of use, context sensitive user interface, automation systems

Automation systems are inseparable part of everyday life; heating systems, ticket vending machines or blood glucose meters are few examples of such systems, showing the diversity of their application domain. This diversity implies the variety of different user groups with assorted capabilities interacting with such systems in different contexts. Hence, the requirements of the humanmachine interfaces of such systems are strongly varying, depending on the context of use. Attempts in developing high interactive systems, such as user centered development or universal design have failed; either they are costly or system specific. Furthermore, many context-relevant aspects are only known at run-time. In this paper, we propose a generic concept, which adapts the humanmachine interfaces of automation systems at run-time, according to the context of use. It addresses not only the representational aspects but also the semantics and the connection to the underlying technical system. The concept is implemented as an evaluating prototype.

Introduction

The application growth of automation systems has brought a wider range of users among those who interact with such systems. Hence, future-oriented automation systems must satisfy a broad range of expectations. Furthermore, the demographic changes bring new requirements on automation systems to be used by users with limited capabilities. The new trends in the domain of automation systems are "Have-It-Your-Way" solutions for better usability [START_REF] Nivethika | Personalized and adaptive user interface framework for mobile application[END_REF] and cost reduction in maintenance, training, support, etc. [START_REF] Cooke | Connecting usability education and research with industry needs and practices[END_REF]. Usability is "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use" [START_REF]ISO 29249 -Ergonomics of Human System Interaction[END_REF]. This definition abstractly frames out the guidelines of ergonomics and usability of human-machine-interaction. Similar definitions used in the literature point out the same aspects as effectiveness, efficiency and satisfaction. While usability has been long discussed in the domain of web and smartphone applications, it is quiet new in automation systems domain. In some cases, the provided guidelines for the web applications can be adopted to automation system [START_REF] Rabin | Mobile Web Best Practices 1.0 -Basic Guidelines[END_REF], however, automation systems have different requirements, imposed by their software-hardware architecture.

Automation systems are systems consisting of a technical process running in a technical system that is automated by components necessary for automation. These components can be sensors, actors and directly wired components to interact with the technical system. The automation functionality is realized on automation computers that are interconnected by a communication infrastructure. Finally, there are components to display information and to input user interventions to interact with the users of the system [START_REF] Maga | Requirements on Engineering Tools for Increasing Reuse in Industrial Automation[END_REF]. We refer to the last component as User Interface (UI). It includes not only the graphical UI but also the modalities, hardware and the interconnections with the technical system. The UI is exposed to the environmental conditions, HW/SW-circumstances and the users, referred to as Context of Use (CoU).

Addressing the usability issues, the researchers and engineers -both in academic and industrial areas -investigate methods, concepts and technologies to increase the usability of automation systems and to provide more intuitive and flexible interaction to the users. Principally, two categories of solutions can be determined:

• Development process-oriented for correct integration of usability requirements;

• Run-time-oriented to provide suitable interaction methods on demand.

Consideration of the development process has the advantage of providing the necessary system architecture, required for integrating the usability requirements. However, it can be very costly and cannot fully allow sensibility to all aspects that affect human-machine interaction at run-time. Furthermore, predefinition of different UIs suitable for different user groups and environmental conditions is impossible. Therefore, the run-time solutions is the reasonable alternative and the new trend in this field [START_REF] Blumendorf | Bridging models and systems at runtime to build adaptive user interfaces[END_REF]. It has the advantage of being able to react to demands that are only known at run-time without the necessity to undergo costly analysis procedure of anticipating and forecasting different run-time situations.

Relationship to Collective Awareness Systems

This research project addresses the domain of automation systems and focuses on the enhancement of the usability of such systems. It refers to both industrial plant automation systems and product automation systems. The proposed concept adapts the UI of such systems according to the CoU. The development of such systems and the new trends and visions affect the proposed concept. The concept contributes to the development of computational and perceptional systems of collective awareness platforms. It provides the automation system with the intelligence to perceive the CoU and to react upon different circumstances. Furthermore, it proposes methods and technologies of industrial informatics for the necessary infrastructure.

Survey on Usability Issues and Existing Solutions in the Domain of Automation Systems

Automation system are in their operation very dependent on run-time parameters. Depending on the user's individual properties the quality of interaction can differ; e.g., user's experience or his/her disabilities. Additionally, environmental effects, such as background light or noise, can influence the interaction. These factors are examples of the CoU. CoU includes the user's profile, the tasks, means of work (hardware, Software and material) and the physical and social environment [START_REF]Ergonomic requirements for office work with visual display terminals (VDTs) --Part 11: Guidance on usability[END_REF].

In order to increase the usability of automation systems, it is necessary to react upon different states of CoU [START_REF] Vanderdonckt | A Design Space for Context-Sensitive User Interfaces[END_REF]. One challenge is that the CoU can change dynamically at run-time; the computing platform might change, network bandwidth may alter and user role or capabilities can differ. Hence, a remedy at run-time is required. This has initiated a trend towards context-sensitive UIs. However, the categorization and capturing of the CoU, in a way that is readable for the machine is not trivial; the details of the affecting factors are domain and system specific. For instance, the affecting parameters in the domain of e-learning systems are different from those of automation systems. Many solutions regarding the capturing and representing the CoU have been proposed [START_REF] Calvary | Embedding Plasticity in the Development Process of Interactive Systems[END_REF][START_REF] Crease | Caring, Shar-ing Widgets: A Toolkit of Sensitive Widgets[END_REF]. However, there are no uniform and generic solution for reflecting the dynamic changes of CoU onto the UI [START_REF] Vanderdonckt | A Design Space for Context-Sensitive User Interfaces[END_REF]. Moreover, this reflection leads to unstable representation of UI. Therefore, the maintenance of usability is another important task to carry out [START_REF] Vanderdonckt | A Design Space for Context-Sensitive User Interfaces[END_REF]. Realization of context-sensitive UIs is another effort, which is often limited to the used technologies in the underlying automation system and the interaction tasks. Finally, the semantic clarity of the interaction tasks should be sustained in the adapted system.

The hardware-software architecture of the automation system is, besides CoU, relevant to the usability of the system, since it provides the interaction means. While at run-time the system architecture is hard to manipulate, often reconfigurations and deployment of system modalities can account for improvement of usability.

The existing run-time solutions can be divided into model-based, migratory or optimization approaches. Model-based approaches attempt to reduce the complexity of the CoU by abstracting it into models [START_REF] Vellis | Model-Based Engineering of Multi-platform, Synchronous and Collaborative UIs -Extending UsiXML for Polymorphic User Interface Specification[END_REF][START_REF] Da Silva | Object modelling of interactive systems: the UMLi approach[END_REF][START_REF] Traetteberg | A hybrid tool for user interface modelling and prototyping[END_REF]. The models are structured with meta rules, defining the expected parameters. The models are then specified at runtime and are used by an automated component to generate the suitable UI. Some solutions predefine different configurations of UI and decide at run-time which configuration to use. This has the advantage that the implementation of such systems is simple and less computations are required. However, it requires thorough analysis of the CoU and is not flexible to new situations. Another method for generating the UI is by models that describe different aspects of UI [START_REF] Meixner | Model-Driven Useware Engineering[END_REF]. The advantage here is the fact that depending on the amount of models used, the details of a UI can be defined to the granularity level needed. The problem here is that there is no unified approach to model UI. Specifically, in the domain of automation systems where real-time requirements are often the case, modeling of temporal behavior of the UI is nontrivial [START_REF] Nóbrega | Mapping ConcurTaskTrees into UML 2.0[END_REF]. Moreover, generation of such models at run-time is a tremendous effort.

Migratory approaches deal with allocation and configuration of different system modalities and available interaction components [START_REF] Bandelloni | Dynamic discovery and monitoring in migratory interactive services[END_REF]. With the popularity of smartphone, it is nowadays very common to perform tasks using multi-devices. Hence, an infrastructure to support cross-device and cross-platform interaction is necessary. Often web or cloud technologies are employed for exchanging data [START_REF]Raising the Floor Community, Global Public Inclusive Infrastructure (GPII)[END_REF]. The migration can be done partially or fully, according to the requirements of the specific system [START_REF] Ghiani | User Interface Migration Based on the Use of Logical Descriptions[END_REF]. Usage of multimodal concepts and embedding devices, which come along with the user (e.g. smartphones), are the advantages of these solutions. Users already know these devices; hence, the interaction is much simpler. However, the existing solutions are limited to software applications. Our tests on Programmable Logic Controller (PLC)-based and Controller Area Network (CAN)-based interaction systems, which are very common in the field of automation systems, showed that manipulation of the technical system from uncoupled devices are very hard to achieve. The platform dependencies and security issues make this even harder.

The optimization solutions are popular among computer science researchers. They mainly focus on the representation of the UI and according to CoU calculate all possible configurations/compositions of the UI. An optimization function traverses the possibilities and find the best solution to be exposed. The UI can be provided either using modelling techniques or using run-time interpreters, e.g. [START_REF] Gajos | Automatically Generating Personalized User Interfaces[END_REF] or the smart toolbar grouping in Microsoft-Office 2007 or later. This category of approaches is scalable and very precise in its results. However, since they are very computation intensive, they are less suitable for the automation domain. Moreover, design of the optimization function is not trivial for so many parameters of the CoU.

Context of Use in Adaptive User Interfaces

The CoU in its initial definition from the ISO-Norm [START_REF]ISO 29249 -Ergonomics of Human System Interaction[END_REF] is not specific enough. Regarding the goals of the concept and after thorough survey of the state of the art, we have summarized the following aspects of CoU, relevant for automation systems:

User tasks: User tasks characterize the semantics of the interaction. They stand for the elements used on a UI and construct the sequence of activities needed to be done in order to complete a task [START_REF] Paternò | ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models[END_REF]. There are four types of tasks [START_REF] Paternò | Past, present, and future of model-based user interface development[END_REF]: User tasks, system tasks, Interaction tasks and Abstract tasks (A set of tasks, which can be grouped together in accordance to their semantic goals). This categorization is important, when reallocation of tasks by the user and by the automation system is necessary [START_REF] Schweitzer | Mechatronics for the Design of Human-Oriented Machines[END_REF].

User Role: An automation system specifies a set of tasks (and consequently system functions) to a certain user role. Different user roles affect directly the type of tasks a user might probably intend to perform. For instance, maintenance staff, operator and system administrator are three user roles, which can indicate what a user belonging to a certain user role group would perform and what experience he/she has.

Users' individual properties (user profile): [START_REF] Maguire | Context of Use within usability activities[END_REF] classifies user properties, regarding the context of use, in three categories: User role, user experience, knowledge and skills and personal attributes. [START_REF] Hentschel | Analysis of the application of the assemblyspecific evaluation method EAWS for the ergonomic evaluation of logistic processes[END_REF] contemplates the human factor in its actions to perform everyday tasks. Here the user activities are divided into three abstract steps: receiving information, processing information and realizing the information. For receiving information, regarding the current technological possibilities, three human senses sight, hearing and touch are used. The cognitive capabilities of the user (fluid and crystallized intelligence) contribute to processing information and individual power, endurance and coordination capabilities correspond to realizing information. [START_REF]Human Factors Division: FAA Human Factors Awareness Web Course[END_REF] investigates in a similar way as above the human factors in Human Machine Interaction (HMI). It sets categories of human factors and attempts to provide value ranges that define the normal values and their extents, using statistics and anthropometrics.

Environment: It is often in literature distinguished between physical environment and organizational environment. The environment (place) in which the interaction occurs is referred to as workspace. The physical environment characterizes the workspace conditions (i.e. atmospheric, auditory, thermal and visual conditions and the environmental instability), the workspace design (i.e. space and furniture, user posture and location) and the workspace safety (i.e. health hazards and required protective clothing and equipment) [7][23]. The organizational environment defines aspects such as the organizational structure or attitude and culture. These aspects can affect the HMI from a social and psychological point of view, hence, it will not be delved into any deeper here. [START_REF]Ergonomics of human-system interaction -Part 20: Accessibility guidelines for information/communication technology (ICT) equipment and services[END_REF] references five typical examples of environment influences, which can strongly affect the usability: Glare caused by bright light, environmental noise, physically limited workplaces, distractions and the tasks with special concentration demands.

The Concept of Adaptive User Interfaces

Based on the previous discussions and identified deficiencies of existing solutions, the concept has to fulfill the following requirements: 1) It must adapt the UI to the CoU.

2) The adaptation should occur at run-time and aims at existing systems (released systems). 3) It must consider the characteristics of automation systems. 4) It must be generic. The derived requirements stipulate abstractly the boundaries of the approach required to fulfill them. The concept has the goal to consider the existing automation system, i.e. automation systems on the market and to adapt and alter the user interface according to the CoU. Based on the definition of CoU given above, the adaptation should be Task-oriented, User specific and Environment specific. As mentioned earlier, the new trend to use mobile devices for the purpose of interaction is essential for the concept to be useful for current and future systems. We refer to the interaction devices -coupled or uncoupled to/from automation system -as Interaction component, hence, the adaptation should also be interaction component specific.

The task-oriented adaptation necessitates the computer-based analysis of the tasks at run-time. The challenges here are that the semantic description of tasks are difficult to capture at run-time [START_REF] Vanderdonckt | A Design Space for Context-Sensitive User Interfaces[END_REF] and that a description methods covering the requirements mentioned previously, including all necessary details and generic for the domain of automation systems does not exist. For the description method, we have proposed an XML-based description. Each task corresponds to an XML tag. The composite tasks are described as interlaced tags. Each tag have an ID and a task type as properties. For each task type -user tasks, system tasks, interaction tasks and abstract tasks -a keyword is dedicated. The temporal behavior of the tasks is adopted from [START_REF] Paternò | ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models[END_REF], since it thoroughly describes all possible compositions of the tasks. The applicability of this proposed method has been evaluated using the prototype of a ticket vending machine. In addition to the tasks, the description of the original UI (UI before being adapted) is necessary for the adaptation; e.g., it is necessary to know which tasks belong to which UI-dialogue. UIML [START_REF] Abrams | UIML: An Appliance-Independent XML User Interface Language[END_REF] is suitable for this purpose, since it not only describes the representation of the UI but also the connection to the underlying system functions.

is specifically interesting for event-based realizations of UI, which is often the case in automation system; e.g. refreshing a sensor value upon an interrupt. In addition, the discussed parameters of the CoU in previous chapter are the basis for the proposed concept.

System's performance can affect the usability when the interaction flow is disturbed. Therefore, the adaptation process has been divided into two stages: static and dynamic adaptation. This separation allows a pre-adaptation process to take place, before the high computational tasks start. The static adaptation refers to those parameters of CoU, which are static during an interaction session; e.g. user individual properties or user role. The dynamic adaptation takes care of parameters changing during an interaction session; e.g. light intensity or the interaction component. Figure 1 illustrates an overview on the concept, its components and the CoU. A rule-based logic projects the situation constraints onto the UI arrangement. The rules are designed in three levels: 1) Modalities and their configuration; e.g. when user is visually impaired then visual interaction is not applicable. 2) Tasks and semantics; e.g. when user role x then load task set y or if user experience x then separate task y into sub-tasks. 3) Representation and layout; e.g. if display resolution less than x then group widgets. In the design of the rules, we have used the existing standards and guidelines on usability, e.g. [START_REF]World Wide Web Consortium W3C, Web Content Accessibility Guidelines[END_REF]. The representation decisions rely on the method used to describe the original UI. It traverses the original UI and adapts each element of the description to the CoU. The result of the adaptation process is an adapted description of UI, which should be interpreted at run-time for different goal platforms. This makes the concept generic to different automation systems. To provide a multiplatform solution, we have proposed an interpreter, which from one side receives a unified description of UI, specified by the concept. From the other side it must be adapted to each goal platform, once in an initialization phase. In an HTMLbased platform, a standard web-browser could act as an interpreter. The details of the interpreter is outside the scope of this paper. Hence, it will not be further explained.

Summary and Outlook

In this paper, the basics of usability of human machine interaction and CoU in the domain of automation systems were discussed. The deficiencies and shortcomings of the existing solutions has been used to motivate the investigations for a new solution. A view on relevant aspects of CoU provide the basis of the concept. The proposed concept of adaptive user interfaces is described. Various decisions on used methods in the concept has been made, based on experiments or implemented scenarios. The plausibility and conformity of the concept has been assessed using the prototype ticket-vending machine. It realizes multimodal/multiplatform interaction in two scenarios (operation and maintenance). The supported modalities are touch-LCD, speech input/output and gesture/mimic control. It provides evaluation of a broad range of interaction concepts. The platforms used in the system are Java, C#.NET and HTML5 with Jscript. In addition to the evaluation of the concept, regarding its plausibility and applicability, the prototype confirmed the necessity of a component to maintain the usability at run-time, upon changes of UI to the CoU.

The proposed concept assumes that the information on CoU are available. However, it is interesting, if the concept could work with incomplete information on CoU, which is often the case in reality. One idea to compensate the missing data would be to employ usage history or statistical information. This aspect is one of the milestones of our future works. Furthermore, it is interesting to compare the evaluation results with another system, with different characteristics, e.g. minimal performance systems or systems with complex internal communication system.

Fig. 1 .

 1 Fig. 1. Illustration of the concept its components and the CoU.


Dariusz Rumiński
email: ruminski@kti.ue.poznan.pl

Krzysztof Walczak
email: walczak@kti.ue.poznan.pl

CARL: A Language for Modelling Contextual Augmented Reality Environments

Keywords: Augmented reality, AR, AR services, contextual services, CARL

The paper describes a novel, declarative language that enables modelling ubiquitous, contextual and interactive augmented reality environments. The language, called CARL -Contextual Augmented Reality Language, is highly componentised with regards to both the structure of AR scenes as well as the presented AR content. This enables dynamic composition of CARL presentations based on various data sources and depending on the context. CARL separates specification of three categories of entities constituting an AR environment -trackable markers, content objects and interfaces, which makes the language more flexible and particularly well suited to building collective awareness systems based on ubiquitous AR-based information visualisation.

Introduction

Augmented reality (AR) technology enables superimposing rich computer generated content, such as interactive 3D animated objects and multimedia objects, in the real time on a view of a real environment. Augmented reality enables building advanced localised information visualisation systems and therefore forms a solid basis for the development of collective awareness systems.

Widespread use of the AR technology has been enabled in the recent years by remarkable progress in consumer-level hardware performance, in particular, in the computational and graphical performance of mobile devices and quickly growing mobile network bandwidth. Education, entertainment, e-commerce and tourism are notable examples of application domains in which AR-based systems become increasingly used.

There are a variety of tools available for authoring AR content and applications. These tools range from general purpose computer vision and graphics libraries, requiring advanced programming skills to develop applications, to easy-to-use pointand-click packages for mobile devices, enabling creation of simple AR presentations. However, the existing tools are designed for manual authoring of AR presentationseither through programming or visual design. To enable more widespread use of AR technology for visualisation of different kinds of up-to-date data, needed in collective awareness systems, a different paradigm is required. The interactive presentations must be created automatically based on the available data sources, through selection of data and automatic composition of AR scenes. A key element enabling selection of information for visualisation is context, which incorporates aspects such as user location, time, privileges, preferences, device capabilities, environmental conditions and others. To enable meaningful contextual selection and automatic composition of non-trivial interactive AR interfaces, semantic web technologies may be used.

In this paper, we present foundations of a novel high-level programming language, called CARL -Contextual Augmented Reality Language, which enables building ubiquitous, contextual and interactive AR presentations. In the presented approach, the AR content that is presented to users is created by selecting and merging content and rules originating from different service providers, without the necessity to explicitly switch from one to another. Moreover, in CARL, the rules for tracked markers (where the information will appear), content objects (what will be presented) and interfaces (how the information will be accessible) are separated, enabling flexible composition of presentations meeting real business requirements.

The reminder of this paper is organised as follows. Section 2 presents related works in the context of building AR environments, in particular focusing on the use of AR for building collective awareness systems. Later, in Section 3, the concept of building ubiquitous contextual AR presentations is explained. In Section 4, the CARL language is presented. In Section 5, the current implementation of CARL is outlined. Finally, in the last section, conclusions and directions for future research are presented.

AR Environments and Collective Awareness Systems

A number of research works have been devoted to the problem of modelling and building AR environments combining the view of real-world objects with multimedia content. One of well-known toolkits that supports rapid design and implementation of AR applications is DART -Designer's Augmented Reality Toolkit [START_REF] Macintyre | DART: A Toolkit for Rapid Design Exploration of Augmented Reality Experiences[END_REF]. Many AR systems are based on the ARToolKit library, which however requires advanced programming skills and technical knowledge to create AR applications [START_REF] Artoolkit | [END_REF].

GUI-based authoring applications that enable mixing virtual scenes with the real world have been presented in [START_REF] Anagnostou | Square AR: Using Augmented Reality for urban planning[END_REF][START_REF] Lee | Immersive authoring: What You eXperience Is What You Get (WYXIWYG)[END_REF][START_REF] Aaa Wang | An Easy to Use Augmented Reality Authoring Tool for Use in Examination Purpose[END_REF][START_REF] Seichter | ComposAR: An Intuitive Tool for Authoring AR Applications[END_REF][START_REF] Grimm | AMIREauthoring mixed reality[END_REF][START_REF] Zauner | Authoring of Mixed Reality Applications Including Multi-Marker Calibration for Mobile Devices[END_REF]. These systems provide user-friendly functionality for placing virtual objects in mixed reality scenes without coding and can be used for building AR environments, but they target only desktop computer environments and do not provide functionality to build open, interoperable and dynamic AR systems.

Since mobile devices have gained popularity, a number of mobile AR toolkits and applications have been developed. For example, ComposAR-Mobile is a crossplatform content authoring tool for mobile phones and PCs based on an XML scene description [START_REF] Wang | An Authoring Tool for Mobile Phone AR Environments[END_REF]. Lee and Seo have presented the U-CAFÉ framework, which can be used to build ubiquitous AR environments [START_REF] Lee | A Context-Aware and Augmented Reality-Supported Service Framework in Ubiquitous Environments[END_REF]. It supports contextual presentation and collaboration between users on various devices. However, it does not provide means for combining content from different services and modelling user interactions within the AR presentations.

Stiktu is a mobile AR authoring application that enables attaching ("sticking") simple content, such as text messages and images, to particular views of real places [START_REF] Stiktu | [END_REF]. It enables users to express and exchange opinions with other users who have created virtual objects. The main limitation of this application is the lack of a possibility of creating complex objects, such as interactive 3D models.

Aurasma is an application that enables augmenting arbitrary real-world views using a mobile device's camera and then sharing the created AR content with other users [START_REF]Aurasma[END_REF]. Layar, Junaio and Wikitude are other examples of AR applications that enable users to share AR content [13][14][START_REF]Wikitude Developer --Devzone[END_REF]. These platforms are good examples of collective awareness systems, where users contribute to "augmenting" the real world with virtual objects. Growing popularity of such applications indicates that there is public interest in new forms of information visualisation, even if the functionality of these systems is still highly limited.

Several studies have been performed in the domain of declarative languages for building virtual environments. InTml is an XML-based language for describing 3D interaction techniques and hardware platforms in VR applications [START_REF] Figueroa | InTml: A Description Language for VR Applications[END_REF]. MPML-VR enables describing multimodal presentations in 3D virtual spaces [START_REF] Okazaki | A Multimodal Presentation Markup Language MPML-VR for a 3D Virtual Space[END_REF]. VR-BML is a high-level XML-based behaviour programming language developed as a part of the Beh-VR approach [START_REF] Walczak | Beh-VR: Modeling Behavior of Dynamic Virtual Reality Contents[END_REF]. These languages, however, have been designed for 3D/VR applications without taking into account AR-specific functionality.

A number of high-level languages have been also designed specifically for building AR applications. APRIL is an XML-based scripting language for authoring AR presentations within the Studierstube framework [START_REF] Ledermann | APRIL: a high-level framework for creating augmented reality presentations[END_REF]. SSIML/AR is a language for structured specification and development of AR applications [START_REF] Vitzthum | Modeling augmented reality user interfaces with SSIML/AR[END_REF]. AREL is a JavaScript binding of the Metaio/Junaio SDK API allowing development of AR applications based on web technologies, such as HTML5, XML and JavaScript [START_REF]AREL -Augmented Reality Experience Language[END_REF]. MR-ISL is a high-level language for defining mixed reality interaction scenarios [START_REF] Walczak | Dynamic Creation of Interactive Mixed Reality Presentations[END_REF].

A common motivation for developing novel platforms and declarative AR languages is to simplify the process of programming AR applications. However, the existing languages are not intended for building dynamic contextual AR information visualisation systems. In such systems, different types of data must be retrieved in the real time from distributed sources and automatically composed into interactive AR scenes.

Contextual Augmented Reality Environments

Existing AR platforms support two main forms of augmentation. In the first form of augmentationdirectional augmentation -information is associated with points of interest in physical locations in the real world and is presented on mobile devices as directions on how to navigate to these locations (e.g., hotels and restaurants in Wikitude or Junaio). Coordinates of a mobile device are monitored through GPS or other sensors. This form of augmentation is usually functionally and graphically very simple -it rarely goes beyond displaying simple graphical objects with textual descriptions and the content is not geometrically registered in the real environment.

The second form of augmentationnatural augmentation -is more powerful. Position and orientation of content to show is identified directly through a device's camera by tracking known markers (patterns) in the captured images. This kind of augmentation can be based on complex interactive 3D content, which can additionally incorporate other multimedia objects, such as images, sounds and videos. The presented content can be geometrically integrated with particular objects in the real environment extending them with presentation of additional virtual objects or information. However, a common problem with the development of systems based on natural augmentation is their limited scope with regards to the number of markers tracked and -consequently -content objects presented. Systems of this type can be successfully used as interactive extensions to printed advertisements or AR additions to video games, but their wider applicability, in particular for building information visualisation and collective awareness systems, is largely limited.

As a solution to this problem, we propose the notion of CARE -Contextual Augmented Reality Environment (Fig. 1). CARE is a new approach to building AR applications, which combines the advantages of both directional and natural augmentation systems. In CARE, the AR scenes that are presented to users are based on natural augmentation, but they are dynamically composed in the real time based on a number of data sources and the current context, which includes such elements as location, time, user privileges and preferences, device capabilities and environmental conditions. Contextual approach to AR application development is a necessity to enable access to a variety of data sources, guarantee scalability and provide for seamless operation. In CARE, the same AR application can be used to display elements coming from different content-and service-providers. Moreover, due to the use of semantic linking, content coming from different sources can be geometrically and functionally combined into integrated AR scenes. To enable implementation of CARE environments, a language is required that would enable passing augmentation information from distributed service providers to the AR browser. Such a language must be designed to support dynamic composition of complex interactive AR scenes, and must enable passing information about different entities: trackable markers, content objects and interfaces. In practical applications, these aspects may be separated. For example, trackable markers may come from municipal services, content objects from AR service providers, while interfaces from application developers. Only in such heterogeneous environment, practical ubiquitous AR environments may be realised.

AR Service Catalogue

In the next section, we present a language, called CARL -Contextual Augmented Reality Language, designed to meet these criteria.

The CARL Language

CARL enables specification of three types of entities that form an AR presentation: Trackables, Content Objects and Interfaces. The independence of trackables, content objects and interfaces in connection with the dynamism of each of these elements requires the use of loose coupling between descriptions of these entities. The problem can be solved by the use of semantic modelling and semantic linking, which is however out of the scope of this paper. Below, the main elements of the CARL language are presented.

Trackables

The Trackables element, shown in Listing 1, groups Trackable elements that are used for describing all real-world objects that an application can detect and track in 3D space. Every Trackable element has its unique URI, which identifies associated binary resource data used in the tracking process. The Trackable element has three child elements: Begin, Active and End. <Trackables> <Trackable uri="…"> <Begin> <ContentObjectBegin id="1"/> <ContentObjectBegin id="2"/> <InterfaceMessage value="…"/> </Begin> <Active> <DistanceChanged change="0.1" distanceMin="2" distanceMax="5" angleMin="30" …> <ContentObjectAction id="1" action="show"/> <ContentObjectAction id="1" action="playAnimation"/> </DistanceChanged> </Active> <End> <ContentObjectEnd id="1"/> <ContentObjectEnd id="2"/> </End> </Trackable> <Trackable uri="…" />… Listing 1. Specification of trackables in CARL In the runtime, when an application detects a trackable object, the Begin section is executed. In the presented example, it initializes content objects using the ContentObjectBegin command and displays a message using the InterfaceMessage command. The Active section contains rules of user interaction when the trackable is visible. In the example, the DistanceChanged event is detected and appropriate action is performed. The End section is executed when the trackable object disappears from the camera view.

Content Objects

The second element of AR environment specification in CARL are ContentObjects, containing multimedia content to be shown to end-users while augmenting real-world objects (Listing 2a). Each ContentObject has an id, which is used while calling object actions. The id can have the form of a fixed literal or a semantic expression to enable loose coupling with other elements of the dynamically created AR scenes.

Content objects support states. The initial object state is specified by the initialState attribute. The state can be changed by the use of the ContentObjectState command in actions. The Resources element contains information about particular Components and Locations of component resources. Several locations can provide alternative URIs for components meeting particular criteria, e.g., regarding the model complexity or language.

The Actions element specifies actions that can be called on this content object. An action is declared within the Action element, which has a mandatory name attribute and an optional state attribute. If the state is specified, the action (if called) will be executed only when the object is in the given state. Within the Action element, commands based on the VR-BML [START_REF] Walczak | Beh-VR: Modeling Behavior of Dynamic Virtual Reality Contents[END_REF] language are used. These commands can be used to load, manipulate and animate object components, change object state, execute interface operations and control other objects. <ContentObjects> <ContentObject id="1" initialState="hidden"> <Resources> <Component id="c1"> <Location details="low" uri="..." /> <Location details="high" uri="..." /> </Component> </Resources> <Begin/> <Actions> <Action name="show" state="hidden"> <SetPosition component="c1" value="…"/> <Activate component="c1" active="true"> <ContentObjectState value="shown"/> </Action> </Actions> <End/> </ContentObject> … <Interface> <TouchSingle target="…"> <ContentObjectAction action="highlight"> </TouchSingle> <TouchSingle target="…"> <ContentObjectAction id="1" action="hide"> <ContentObjectAction id="2" action="show"> </TouchSingle> <Pan target="…"> <ContentObjectRotate> </Pan> <Pinch target="…"> <ContentObjectScale> </Pinch> </Interface> a) b)

Listing 2. Specification of content objects (a) and interfaces (b) in CARL

Interfaces

The third main part of a CARL environment specification are interfaces (Listing 2b). An Interface element contains specification of possible interactions on an end-user device. Listing 2b shows an example of an interface specification, in which touch, pan and pinch gestures can trigger actions. An interface can recognize interactions with objects and interactions with trackables. Interaction with objects enables activation and manipulation of objects. Interaction with trackables can be used, e.g., to display objects associated with the tracked markers (e.g., information about a known product).

Implementation

CARL has been implemented within the Mobile Augmented Reality Authoring Tool (MARAT) for virtual museum exhibitions [START_REF] Rumiński | Creation of Interactive AR Content on Mobile Devices[END_REF]. Currently the application enables only playback of CARL presentations, but the intention is to implement also content authoring directly on a mobile device within MARAT.

The following figures show examples of CARL usage in the MARAT application. Figure 2a presents an example when an end-user moves his/her finger on a device screen. A Pan event triggers an action responsible for object rotation (ContentObjectRotate -c.f. Listing 2b). In turn, Figure 2b shows example of using a Pinch gesture, which triggers an action responsible for object scaling (ContentObjectScale).

Conclusions

In this paper, the overall concept of Contextual Augmented Reality Environments and fundamentals of the CARL language, designed to support creation of such environments, have been presented. CARL enables modelling ubiquitous, contextual and interactive AR environments. The language is highly componentised with regards to the structure of the AR scenes as well as the presented content, enabling dynamic composition of complex AR environments. The CARL language can support building ubiquitous AR-based data visualisation and collective awareness systems. Future research will incorporate several facets. First, the method of semantic coupling of elements of dynamic AR environments will be elaborated. Second, techniques for combining CARL specifications from independent sources will be investigated, with particular focus on security. Finally, methods of automatic creation of CARL specifications through WYSIWYG actions on mobile devices, to enable direct on-site authoring of AR environments, will be designed.

Fig. 1 .

 1 Fig. 1. Architecture of the CARE environment

Fig. 2 .

 2 Fig. 2. Triggering the ContentObjectRotate action on a Pan event (a) and the ContentObjectScale action on a Pinch event (b)


Eduardo Pinto

Pedro Santana

Francisco Marques

Ricardo Mendonça

André Lourenço

José Barata

On the Design of a Robotic System Composed of an Unmanned Surface Vehicle and a Piggybacked VTOL

Keywords: cooperative robots, unmanned aerial vehicles, UAV, autonomous surface vehicles, ASV, environmental monitoring, riverine environments

This paper presents the core ideas of the RIVERWATCH experiment and describes its hardware architecture. The RIVERWATCH experiment considers the use of autonomous surface vehicles piggybacking multi-rotor unmanned aerial vehicles for the automatic monitoring of riverine environments. While the surface vehicle benefits from the aerial vehicle to extend its field of view, the aerial vehicle benefits from the surface vehicle to ensure long-range mobility. This symbiotic relation between both robots is expected to enhance the robustness and long lasting of the ensemble. The hardware architecture includes a considerable set of state-of-the-art sensory modalities and it is abstracted from the perception and navigation algorithms by using the Robotics Operating System (ROS). A set of field trials shows the ability of the prototype to scan a closed water body. The datasets obtained from the field trials are freely available to the robotics community.

Introduction

The monitoring of riverine and maritime environments has been shown in the last years as one of the most important activities to reveal the negative impact of human activities in Nature [START_REF] Balog | Extreme Ice Survey[END_REF], [START_REF] Church | A 20th century acceleration in global sea level rise[END_REF], [START_REF]Updating the World on the Latest Climate Science[END_REF], and increase the awareness of people regarding climatic changes. The unattractiveness and difficulty of monitoring remote aquatic environments by humans render the automation of the process highly valuable.

A fine spatiotemporal mapping of environmental variables across extensive water bodies hampers the application of typical fixed sensor networks. Furthermore, such a solution is unable to return samples for laboratorial analysis, which is a requirement for several monitoring procedures. Several projects had dealt with these limitations by introducing autonomous surface vehicles [START_REF] Sukhatme | Design and Development of a Wireless Robotic Networked Aquatic Microbial Observing System[END_REF], [START_REF] Bhadauria | A Robotic Sensor Network for monitoring carp in Minnesota lakes[END_REF], [START_REF] Tokekar | robotic system for monitoring carp in Minnesota lakes[END_REF]. These projects, however, are still unable to cope with inherent limitations of a surface-level perspective of the environment. The major limitation concerns the ability to properly perceive the far field, which ultimately limits the autonomy of the vehicle when facing cluttered and shallow water bodies. Previous work capitalized on the benefits of multi-robot systems to overcome this problem by relying on a helicopter to provide the human operator with improved situation awareness [START_REF] Tokekar | robotic system for monitoring carp in Minnesota lakes[END_REF]. The RIVERWATCH1 experiment, a part of the EU funded FP7 project ECHORD2 , takes this idea up to the next level, i.e., without demanding the presence of a human operator. Concretely, RIVERWATCH considers an autonomous surface vehicle (ASV) with a multi-rotor unmanned aerial vehicle (UAV) piggybacked, which is deployed when a higher vantage point is required. Hence, the surface vehicle benefits from the aerial vehicle to extend its field of view. Conversely, the aerial vehicle benefits from the surface vehicle to ensure long-range mobility. Although the use of aerial images to help surface-level navigation has been explored in a parallel work, the actual acquisition process has not been considered [START_REF] Heidarsson | Obstacle detection from overhead imagery using self-supervised learning for autonomous surface vehicles[END_REF].

This paper provides both an overview of the RIVERWATCH experiment and the details of the practical aspects related to the hardware and software architectures. Details regarding high-level software components, such as those enabling perception and safe navigation, will be published elsewhere.

Relationship to Collective Awareness Systems

We consider that the perception of the environment shared by both surface and aerial vehicles implements a form of collective awareness. The environment monitoring products generated by the system contribute to an ecological global awareness.

3

The RIVERWATCH Architecture Fig. 1 depicts the major computational and communications hardware components selected for the RIVERWATCH system. These have been selected in order to ensure large computational and communications capacity and, thus, openness to future demands. From the software perspective, this openness is ensured by the use of the Robotics Operating System (ROS) as backbone. ROS3 offers a cross-language interprocess communication system and several state-of-the-art software components freely available.

The Multi-Rotor UAV

Several commercial multi-robot aerial platforms had been evaluated, namely, AirRObot, Asctec, Microdones, Draganfly, and Cyberquad. These products are patented and closed, which limits considerably their interest for research activities. This issue can be avoided by recurring to open source solutions, such as MikroKopter, Mikro's Aeroquad, NG-UAVP, UAVX, UAVP, OpenPilot, Arducopter, Multipilot 32, and VBrain. From these, the VBrain commercialized by the Italian company Virtualrobotix4 , was selected as the base for the RIVERWATCH's aerial platform. This solution is fully open sourced, including the mission control software and hardware, and it is provided with the most powerful microcontroller from all the evaluated possibilities.

Regarding the mechanical design, a six-rotor configuration was preferred to the common four-rotor solution. First, a six-rotor solution, a hexacopter, provides more lifting capability. Second, it endows the system with graceful degradation, as it is able to land with one motor off, without yaw control though. Moreover, it may still be able to fly with two motors off, provided that they stand on the neutral torque bar. Fig. 2, illustrates the designed hexacopter and its supporting hardware architecture.

3.2

The ASV

The ASV is based on a 4.5 m Nacra catamaran, which has received special carbon fibre reinforcements for the roll bars and motor supports. The hulls have been filled with special PVC closed cells foam, making it virtually unsinkable. The trial tests here presented have been done with the propulsion in a differential locomotion configuration using a Haswing Protuar 2 Hp motor in each hull. The motors can be driven manually for safety reasons and if required for debugging purposes. A docking station with an H-marked for facilitated detection and tracking from aerial images taken by the UAV was fitted to the ASV's deck. A net was set around the docking station as lateral protections to the UAV when docked. Fig. 3 depicts the ASV's hardware architecture. Aiming at autonomous behaviour, the ASV is equipped with a set of state-of-the-art navigation-related sensors. Concretely, it is equipped with a GPS-RTK (Proflex 800 from Ashtec SAS), an IMU (PhidgetSpacial 3 axis from Phidgest Inc), a long range tilting laser scanner (LD-LRS2100 from Sick), a fixed underwater sonar (DeltaT 837B from Imagenex), and a multi-camera vision system (Ladybug3 from Pointgrey).

The Operations Control Centre

The operations control centre is a web-based application that allows the remote operator to perform offline missions planning and online missions execution monitoring. This section describes briefly the hardware and software aspects related to the maintenance of the communication channels between control centre and robots (see Fig. 4). Two communications strategies were implemented. The first strategy assumes that the robots are relatively close to the control centre (roughly 1 Km radius in line of sight), which enables a direct wireless link and, consequently, high throughput communications. Hence, in this mode the operator is able to directly control the robots at the several levels of autonomy, from direct motor control up to mission specification.

The second strategy imposes neither range limit nor synchronisation between control centre and robots, provided that both are able to connect to the internet via, for instance, a GPRS or a 3G modem. In this case communications are done indirectly and asynchronously via a third-party file sharing service, such as DropBox. By not relying on peer-to-peer communications, accessing the products generated by the robotic system by remote clients becomes easily configurable and easily maintainable in the presence of communications dropouts.

Preliminary Field Trials

To validate the proposed system, a large set of field trials was carried out with the robots in autonomous and tele-operated modes. The autonomous mode is based on a set of navigation and coordination algorithms. The goal of the tests, in what regards this paper, is to show that the hardware architecture and the robots mechanical design fits the purpose of robust navigation in riverine environments. The tests were carried out in a private lake in the Sesimbra region in Portugal, with an area of roughly 1.5 Km 2 . This site offered in a single place most of the environmental traits that can be found in riverine environments, such as narrow passages, open space areas, deep and shallow waters, margins with disparate kinds of vegetation ranging from sander dunes to large trees passing by zones of extreme vegetation density. Fig. 5 depicts several results obtained throughout the field trials. It highlights the ability of the described system to provide the reliability necessary for the perceptual and navigation algorithms to autonomously scan the environment that will be published in future articles. Fig. 6 also depicts a situation in which the UAV is taking off the ASV. All sensory data produced throughout the field trials are publicity available as ROS-enabled log files.

Conclusions and Further Work

Although the use of heterogeneous robots working as a collective is an old idea, only in RIVERWATCH it has been realised in the context of aquatic-aerial robotic teams for environmental monitoring. This approach serves the purpose of enabling longlasting robust operation. Long lasting from using the ASV as energy supplier and robust from using the UAV to provide far field navigation cost information. This paper focused on the hardware and technological aspects of the RIVERTWATCH experiment with the expectation of fostering the development of new prototypes for the execution of related experiments. Our future work will be centred in making RIVERWATCH a full autonomous system, and so is necessary to solve problems as:

Energy harvesting by the ASV and charge of the UAV; Full tests and evaluation of the landing algorithms; Full characterization of the innovative dual propulsion system; Consider seriously the development of a smart "catch" mechanism that is vital for safe landings in adverse meteorological conditions.

Fig. 1 .

 1 Fig. 1. Computational and communications hardware in RIVERWATCH.

Fig. 2 .

 2 Fig. 2. The UAV's hardware architecture.

Fig. 3 .

 3 Fig. 3. The ASV's hardware architecture.

Fig. 4 .

 4 Fig. 4. Operations control centre's hardware architecture.

Fig. 5 .

 5 Fig. 5. Field trials: autonomous navigation. Top-left: Resulting occupancy grid from surface (red) and underwater range data (blue). Top-right: Cost map overlaid in red on satellite imagery of the trials site. Lines correspond to autonomous navigation paths. Bottom-Left: The path of the robot when navigating autonomously across a narrow passage. Bottom-Right: A view from the ASV of the narrow passage.

Fig. 6 .

 6 Fig. 6. Field trials: UAV taking off the ASV. Left: moment right after the taking off takes place. Right: A few moments after the take off onset.

RIVERWATCH homepage: http://riverwatchws.cloudapp.net

ECHORD homepage: http://www.echord.info/

ROS homepage: http://wiki.ros.org

http://www.virtualrobotix.com/

Acknowledgments. This work was co-funded by EU FP7 ECHORD project (grant number 231143) and by the CTS multi-annual funding, through the PIDDAC Program funds.


Mohamed Sorour

Andrea Cherubini

Robin Passama

Philippe Fraisse

Kinematic Modeling and Singularity Treatment of Steerable Wheeled Mobile Robots with Joint Acceleration Limits

Keywords:

published or not. The documents may come

L'archive ouverte

I. INTRODUCTION

Mobile robots equipped with fully steerable wheels are usually described as pseudo-omnidirectional (or nonholonomic or quasi onmi), providing a distinction from the omnidirectional ones, that employ either castor or omnidirectional (swedish) wheels. Since steerable wheels are usually characterized by higher load carrying capacity than castor or omni-wheels, pseudo-omni platforms are more adequate for industrial applications. Although these platforms possess only one degree of mobility (i.e., the directly controllable degree of freedom, here the rotation about the instantaneous center of rotation -ICR), they can perform complex three-dimensional trajectories in the plane, only after reorienting the steer joints to the proper initial conditions. Thus, they do not require special maneuvers, and are more suitable than less complex systems (e.g., differential drive, car) for limited footprint applications.

Kinematic modeling of steerable (centered or offcentered) mobile robots is usually done using the Cartesian coordinates of the ICR [START_REF] Dietrich | Singularity avoidance for nonholonomic omnidirectional wheeled mobile platforms with variable footprint[END_REF], the polar coordinates of the ICR [START_REF] Connette | Control of an pseudoomnidirectional nonholonomic mobile robot based on an ICM representation in spherical coordinates[END_REF][START_REF] Thuilot | Modeling and feedback control of mobile robots equipped with several steering wheels[END_REF][START_REF] Schwesinger | A novel approach for steeringwheel synchronization with velocity/acceleration limits and mechanical constraints[END_REF], or by considering the Cartesian coordinates of the robot frame [START_REF] Giordano | On the kinematic modeling and control of a mobile platform equipped with steering wheels and movable legs[END_REF][START_REF] Betourne | Kinematic modeling of a class of omnidirectional mobile robots[END_REF]. Each of these methods has its own mathematical singularities, indicated in the literature as representational 1 Interactive Digital Human group IDH, Laboratory for Computer Science, Micro-electronics and Robotics LIRMM -University of Montpellier CNRS, 860 rue de Saint Priest, 34090 Montpellier, France. first.lastname@lirmm.fr.

2 PSA Peugeot-Citroen, Velizy Villacoublay, France.

singularities. This type of singularity results from two distinct situations, namely having null angular and/or linear velocity.

Employing the Cartesian coordinates is less prone to such singularities, especially if 3 or more wheels are used [START_REF] Giordano | On the kinematic modeling and control of a mobile platform equipped with steering wheels and movable legs[END_REF]. Kinematic (or structural) singularity also exists. This refers to cases where the ICR passes by (or nearby) any of the steering axes. Then, the steer angle is not uniquely defined (infinite solutions respect the kinematic constraints). In the neighborhood of such singularity, the steering rate grows unbounded. Different approaches have been employed to deal with structural singularities. The admissible velocity space has been constrained in [START_REF] Thuilot | Modeling and feedback control of mobile robots equipped with several steering wheels[END_REF]. Repulsive potential fields have been constructed at the steering axes in [START_REF] Dietrich | Singularity avoidance for nonholonomic omnidirectional wheeled mobile platforms with variable footprint[END_REF][START_REF] Schwesinger | A novel approach for steeringwheel synchronization with velocity/acceleration limits and mechanical constraints[END_REF][START_REF] Connette | Singularity avoidance for overactuated pseudo-omnidirectional wheeled mobile robots[END_REF]. Although such techniques reduce the available velocity space, they suffice in static environments. However, in the emerging industrial applications involving human robot collaboration, the environment can change suddenly, due to moving operators. Then, all the available velocity workspace should be exploited, including worst-case scenarios with 1) ICR passing by and/or 2) ICR stopping at a steering axis (kinematic singularity). Besides, the controller must respect joint acceleration limits and mechanical constraints [START_REF] Schwesinger | A novel approach for steeringwheel synchronization with velocity/acceleration limits and mechanical constraints[END_REF][START_REF] Oftadeh | Time optimal path following with bounded velocities and accelerations for mobile robots with independently steerable wheels[END_REF][START_REF] Chamberland | Motion planning for an omnidirectional robot with steering constraints[END_REF].

Such issues have recently drawn researchers' attention. In [START_REF] Connette | Singularity-free state-space representaion for non-holonomic omnidirectional undercarriages by means of coordinate switching[END_REF], a complex formulation provides a locally singular-free representation, by switching between several state space representations of the twist. In [START_REF] Oftadeh | A novel time optimal path following controller with bounded velocities for mobile robots with independently steerable wheels[END_REF], a time optimal controller is developed to account for the joint velocity limits. Such controller is shown to be successful in passing by singular configurations, while respecting the actuator velocity limits. Acceleration limits were further taken into account in [START_REF] Oftadeh | Time optimal path following with bounded velocities and accelerations for mobile robots with independently steerable wheels[END_REF]. However, the methods developed in [START_REF] Oftadeh | A novel time optimal path following controller with bounded velocities for mobile robots with independently steerable wheels[END_REF] and [START_REF] Oftadeh | Time optimal path following with bounded velocities and accelerations for mobile robots with independently steerable wheels[END_REF] result in the maximum steering/driving velocity for the axis passed by the ICR. While they can handle the scenario 1 mentioned above, they are not suitable for scenario 2. The simulations in [START_REF] Connette | Singularity-free state-space representaion for non-holonomic omnidirectional undercarriages by means of coordinate switching[END_REF] do not provide information on joint axes rates in the vicinity and at the singular configurations.

In this work, we propose a simple, yet numerically robust, treatment of the kinematic model. Such treatment introduces a damping effect, to oppose the singular behavior. Consequently, it solves not only the aforementioned 2 worstcase scenarios, but also provides a promising candidate to the joint limits issue encountered in [START_REF] Schwesinger | A novel approach for steeringwheel synchronization with velocity/acceleration limits and mechanical constraints[END_REF]. We provide a formula for online tuning of the damping effect, which maintains the joint accelerations below their limits. Additionally, we propose a benchmark test trajectory for evaluating, at all singular conditions, the performance of novel kinematic controllers for this class of mobile robots.

This paper is organized as follows: Section II presents the forward and inverse kinematic models, along with the joint initialization strategy. Section III and IV respectively detail the proposed treatment of kinematic singularities, and the benchmark testing scenario. The experimental results are provided in section V, and we conclude in section VI.

Kinematic Modeling and Singularity Treatment of Steerable Wheeled Mobile Robots with Joint Acceleration Limits

Mohamed Sorour 1, 2 , Andrea Cherubini 1 , Robin Passama 1 , and Philippe Fraisse 1

II. KINEMATIC MODEL

The kinematic model developed in this section is inspired by the pioneering work of Muir et al. [START_REF] Muir | Kinematic modeling of wheeled mobile robots[END_REF], Campion et al. [START_REF] Betourne | Kinematic modeling of a class of omnidirectional mobile robots[END_REF], [START_REF] Muir | Kinematic modeling of wheeled mobile robots[END_REF] and Low et al. [START_REF] Low | Kinematic modeling, mobility analysis and design of wheeled mobile robots[END_REF]. In Fig. 1, let 𝓡 𝐼 = (𝑜 𝐼 , 𝒙 𝐼 , 𝒚 𝐼 , 𝒛 𝐼 ) be the inertial (world) reference frame, 𝓡 𝑏 = (𝑜 𝑏 , 𝒙 𝑏 , 𝒚 𝑏 , 𝒛 𝑏 ) the mobile base attached frame with the origin 𝑜 𝑏 located at its geometric center, 𝓡 ℎ𝑖 = (𝑜 ℎ𝑖 , 𝒙 ℎ𝑖 , 𝒚 ℎ𝑖 , 𝒛 ℎ𝑖 ) is the 𝑖 𝑡ℎ hip frame, where 𝑖 = 1, … , 4; a frame attached to the fixed part of the steering joint (related to the base frame by a fixed transformation matrix) whereas the steering frame 𝓡 𝑠𝑖 = (𝑜 𝑠𝑖 , 𝒙 𝑠𝑖 , 𝒚 𝑠𝑖 , 𝒛 𝑠𝑖 ) is attached to the movable part. The hip and steering frames share the same origin, with relative orientation depending on the steering angle 𝛽 𝑖 , 𝓡 𝑤𝑖 = (𝑜 𝑤𝑖 , 𝒙 𝑤𝑖 , 𝒚 𝑤𝑖 , 𝒛 𝑤𝑖 ) is a frame attached to (but doesn't rotate with) 𝑖 𝑡ℎ wheel. Frame 𝓡 𝑤𝑖 is assigned such that 𝒙 𝑤𝑖 points along the heading of the wheel, which rotates about 𝒚 𝑤𝑖 by the driving angle 𝜑 𝑖 . For all the described frames, the 𝒛 axis is always pointing upwards. Let the mobile base pose with respect to the inertial frame, expressed in the inertial frame define the task space coordinates and be described by the 3 × 1 vector: 𝝃 𝐼 𝑏 𝐼 = [𝑥 𝑦 𝜃] T , to simplify notation, the right sub, superscripts will be omitted in the sequel since they will never change. Let the mobile base joint actuation coordinates be the 8 × 1 vector: 𝑨 𝑏 = [𝛽 1 … 𝛽 4 𝜑 1 … 𝜑 4 ] T . Let the wheel velocity at the ground contact point 𝑜 𝑐 be the vector 𝒗 𝑐𝑖 = [𝑣 𝑡𝑖 𝑣 𝑛𝑖 0] T with 𝑣 𝑡𝑖 and 𝑣 𝑛𝑖 respectively the 𝑖 𝑡ℎ wheel's tangential and normal velocities: (colored red in Fig. 1) are defined with respect to frames 𝓡 𝑏 , 𝓡 𝑠𝑖 and 𝓡 𝑤𝑖 respectively, ℎ 𝑥𝑖 = ±𝑏 and ℎ 𝑦𝑖 = ±𝑎 denote the position of the 𝑖 𝑡ℎ hip frame origin 𝑜 ℎ𝑖 in the base frame 𝓡 𝑏 , while 𝑑 and 𝑟 𝑤 denote the steerable wheel offset and radius respectively. Using (1) we get the contact point velocities as:

𝝂 𝑐𝑖 = 𝑹 𝑏 𝑤𝑖 [𝑹 𝐼 𝑏 𝝃 ̇+ 𝜃 k ̂𝑏 × 𝑜 𝑏 𝑜 𝑐 ⃑⃑⃑⃑⃑⃑⃑⃑ 𝑏 + 𝛽 ̇𝑖𝑹 𝑠𝑖 𝑏 𝒌 ̂𝑠𝑖 × 𝑜 𝑠𝑖 𝑜 𝑐 ⃑⃑⃑⃑⃑⃑⃑⃑⃑ 𝑠𝑖 ] +𝜑̇𝑖𝒋ŵ 𝑖 × 𝑜 𝑤𝑖 𝑜 𝑐 ⃑⃑⃑⃑⃑⃑⃑⃑⃑⃑ 𝑤𝑖 . (1)
𝜈 𝑡𝑖 = [𝑐(𝛽 𝑖 ) 𝑠(𝛽 𝑖 ) 𝑑 -ℎ 𝑦𝑖 𝑐(𝛽 𝑖 ) + ℎ 𝑥𝑖 𝑠(𝛽 𝑖 )] 𝝃 ̇ 𝑏 +𝑑𝛽 ̇𝑖 -𝑟 𝑤 𝜑̇𝑖 , (2)
𝜈 𝑛𝑖 = [-𝑠(𝛽 𝑖 ) 𝑐(𝛽 𝑖 ) ℎ 𝑥𝑖 𝑐(𝛽 𝑖 ) + ℎ 𝑦𝑖 𝑠(𝛽 𝑖 )] 𝝃 ̇ 𝑏 , (3)
with 𝝃 ̇ 𝑏 = 𝑹 𝐼 𝑏 𝝃 ̇, 𝑐( * ) and 𝑠( * ) shorthand the trigonometric cosine and sine functions respectively. By setting 𝑣 𝑡𝑖 = 0 and 𝑣 𝑛𝑖 = 0, (2) and ( 3) respectively describe the rolling without slipping, and the no lateral skidding kinematic constraints. The no-skid constraint restricts the mobile base motion (the wheel cannot move sideways) and forces the existence of a unique ICR, around which all the wheels and the base frame rotate. From (3), we derive the steering angles that respect such constraint:

𝛽 𝑖 = 𝑡𝑎𝑛 -1 ( 𝑦̇ 𝑏 + ℎ 𝑥𝑖 𝜃 ẋ̇ 𝑏 -ℎ 𝑦𝑖 𝜃 ̇) . ( 4
)
This can be time differentiated to obtain the steering rates:

𝛽 ̇𝑖 = 𝜕𝛽 𝑖 𝜕 𝑥̇ 𝑏 𝑥̈ 𝑏 + 𝜕𝛽 𝑖 𝜕 𝑦̇ 𝑏 𝑦̈ 𝑏 + 𝜕𝛽 𝑖 𝜕𝜃 ̇𝜃̈= 𝒇 1𝑖 ( 𝝃 ̇ 𝑏 ) 𝝃 ̈ 𝑏 . (5)
The wheel drive rates can be evaluated using ( 2) and ( 5):

𝜑̇𝑖 = 1 𝑟 𝑤 ([𝑐 (𝛽 𝑖 ) 𝑠(𝛽 𝑖 ) 𝑑 -ℎ 𝑦𝑖 𝑐(𝛽 𝑖 ) + ℎ 𝑥𝑖 𝑠(𝛽 𝑖 )] 𝝃 ̇ 𝑏 + 𝑑𝛽 ̇𝑖) = 1 𝑟 𝑤 𝒇 2𝑖 (𝜷) 𝝃 ̇ 𝑏 + 𝑑 𝑟 𝑤 𝒇 1𝑖 ( 𝝃 ̇ 𝑏 ) 𝝃 ̈ 𝑏 . (6)
In ( 5) and ( 6), the steering and wheel drive rates are related to the base velocity 𝝃 ̇ 𝑏 and acceleration 𝝃 ̈ 𝑏 , expressed in the base frame. These equations can be grouped in matrix form to derive the inverse kinematic actuation model (IKAM):

𝑨 ̇𝑏 = 𝑴 𝐼 ( 𝝃 ̇ 𝑏 ) 𝜼̇ 𝑏 , (7)
𝑴 𝐼 ( 𝝃 ̇ 𝑏 ) = [ 𝟎 4×3 𝑭 1 ( 𝝃 ̇ 𝑏 ) 1 𝑟 𝑤 𝑭 2 (𝜷) 𝑑 𝑟 𝑤 𝑭 1 ( 𝝃 ̇ 𝑏 ) ] , 𝑭 1 ( 𝝃 ̇ 𝑏 ) = [𝒇 11 𝑇 … 𝒇 14 𝑇 ] T , 𝑭 2 (𝜷) = [𝒇 21 𝑇 … 𝒇 24 𝑇 ] T ,
with 𝜼 𝑏 = [ 𝝃 𝑏 𝝃 ̇ 𝑏 ] T . Similarly, the forward kinematic actuation model (FKAM) can be derived from [START_REF] Betourne | Kinematic modeling of a class of omnidirectional mobile robots[END_REF]:

𝝃 ̇ 𝑏 = 𝑴 𝑓 (𝜷 𝑚 )𝑨 ̇𝑏 , (8)
𝑴 𝑓 (𝜷 𝑚 ) = [-𝑑 * 𝑭 2(𝑑) + (𝜷 𝑚 ) 𝑟 * 𝑭 2(𝑑) + (𝜷 𝑚 ) ] .
In [START_REF] Connette | Singularity avoidance for overactuated pseudo-omnidirectional wheeled mobile robots[END_REF], 𝜷 is computed as a function of 𝝃 ̇ 𝑏 using (4), whereas in [START_REF] Oftadeh | Time optimal path following with bounded velocities and accelerations for mobile robots with independently steerable wheels[END_REF] of 𝑭 2 [START_REF] Nakamura A Nd | Inverse kinematic solutions with singularity robustness for robot manipulator control[END_REF][START_REF] Wampler | Manipulator inverse kinematic solutions based on vector formulations and damped least-squares methods[END_REF], with damping factor 𝜆. Using it, the velocity trajectory can be reconstructed from joint velocity measurements, even at 𝑭 2 singularities, making (8) a robust odometry model. Typically when moving with 𝜃 ̇= 0; such motion will yield a column of zeros depending on the direction of motion according to [START_REF] Connette | Singularity avoidance for overactuated pseudo-omnidirectional wheeled mobile robots[END_REF].

As mentioned earlier, mobile robots with steerable wheels can perform complex planar trajectories, provided their wheels orient to the proper initial values. These initial steer angles depend on the trajectory to be performed, and can be obtained, using (4) as:

𝛽 𝑖(𝑖𝑛𝑖𝑡) = 𝑡𝑎𝑛 -1 ( 𝑦( 𝑡 𝑖𝑛𝑖𝑡 +𝑇 𝑠 ) 𝑏 + ℎ 𝑥𝑖 𝜃 ̇(𝑡 𝑖𝑛𝑖𝑡 +𝑇 𝑠 ) 𝑥( 𝑡 𝑖𝑛𝑖𝑡 +𝑇 𝑠 ) 𝑏 -ℎ 𝑦𝑖 𝜃 ̇(𝑡 𝑖𝑛𝑖𝑡 +𝑇 𝑠 ) ) . (9)
In ( 9), 𝑇 𝑠 is the sample time and the subscript (𝑡 𝑖𝑛𝑖𝑡 + 𝑇 𝑠 ) denotes the value of the desired velocity component at the first sample time of the trajectory. Since the time needed to initialize the steer joints must be taken into account in the motion planning phase, it will affect the desired trajectory timing. To minimize such effect, the initial steer angles must be attained as fast as possible. In addition to using the maximum joint acceleration and/or velocity limits, we apply the following modification on the output of ( 9), to minimize the motion, based on the current configuration 𝛽 𝑖(𝑐) :

𝛽 𝑖(𝑖𝑛𝑖𝑡) = { 𝛽 𝑖(𝑖𝑛𝑖𝑡) -𝜋, ∀ 𝛽 𝑖(𝑖𝑛𝑖𝑡) -𝛽 𝑖(𝑐) > 𝜋 2 ⁄ 𝛽 𝑖(𝑖𝑛𝑖𝑡) + 𝜋, ∀ 𝛽 𝑖(𝑖𝑛𝑖𝑡) -𝛽 𝑖(𝑐) < 𝜋 2 ⁄ 𝛽 𝑖(𝑐) , ∀ 𝛽 𝑖(𝑖𝑛𝑖𝑡) -𝛽 𝑖(𝑐) = 𝜋 , (10)
The formula provided in [START_REF] Connette | Singularity-free state-space representaion for non-holonomic omnidirectional undercarriages by means of coordinate switching[END_REF] guarantees that the initial steer joint angle will always be ≤ ± 𝜋 2 ⁄ .

III. SINGULARITY TREATMENT

Singularities related to this kind of mobile robots are divided into two categories: kinematic and representational. While the latter (for 3 or more steerable WMR) is solved by using the Cartesian coordinates of the base frame [START_REF] Dietrich | Singularity avoidance for nonholonomic omnidirectional wheeled mobile platforms with variable footprint[END_REF], the former still presents a challenging problem. Kinematic singularity refers usually to the case where the ICR passes by (or nearby) any of the steering axes. In such case, the steer angle 𝛽 𝑖 in not uniquely defined, as there exist infinite values respecting the kinematic constraints. While passing this configuration, the steering rate shall grow unbounded from the "nearby" to the "at" singular configuration. This is shown mathematically in [START_REF] Schwesinger | A novel approach for steeringwheel synchronization with velocity/acceleration limits and mechanical constraints[END_REF], where the denominator of the argument of the tan inverse function decreases to zero at such singularity. In this paper, we fix this problem with a very simple, yet effective, numerical treatment, by adding the damping parameters 𝛿 1 and 𝛿 2 respectively to the denominator of the tan inverse argument for the steer angle:

𝛽 𝑖 = 𝑡𝑎𝑛 -1 ( 𝑦 ̃𝑖 𝑥 ̃𝑖 + 𝛿 1 * 𝑠𝑖𝑔𝑛(𝑥 ̃𝑖) ) , ( 4
where 𝑦 ̃𝑖 = 𝑦̇ 𝑏 + ℎ 𝑥𝑖 𝜃 ̇, 𝑥 ̃𝑖 = 𝑥̇ 𝑏 -ℎ 𝑦𝑖 𝜃 ̇. Although the developed inverse kinematic model aims at providing joint steer rates, rather than joint steer angles, it is important to provide a singularity-free model for the steer joint variable too, since this is used in initializing robot configuration at the start of each new trajectory via [START_REF] Chamberland | Motion planning for an omnidirectional robot with steering constraints[END_REF], which justifies the need for (4'). The value of 𝛿 1 can be arbitrarily adjusted to be infinitesimally small, while 𝛿 2 should respect the acceleration limits of the steer joints (in case of centered WMRs) or of the steer/drive joints (in case of off-centered WMRs). Such effect is shown in Fig. 3(b). Once tuned, 𝛿 2 provides a damping effect which is completely the opposite to the singular behavior. Using (5') the steering rate will decrease to zero from the "nearby" to the "at" singular configuration. In order to tune 𝛿 2 to respect steer acceleration limits, we differentiate (5') with respect to time, neglecting higher order derivatives, to obtain:

𝛽 ̈𝑖 = 𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 ) (𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 + 𝛿 2 ) 2 , (11)
where 𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 ) = 2(𝑦 ̃𝑖𝑥̇𝑖 -𝑥 ̃𝑖𝑦̇𝑖)(𝑥 ̃𝑖𝑥̇𝑖 + 𝑦 ̃𝑖𝑦̇𝑖) is a function of the base frame trajectory. We define a candidate value of 𝛿 2 (called 𝛿 2𝑐 ) as:

𝛿 2𝑐 = √ |𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| 𝛽 ̈𝑖(𝑚𝑎𝑥) -(𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 ) , (12)
where 𝛽 ̈𝑖(𝑚𝑎𝑥) is the i th steer joint acceleration limit in centered steerable robots, or the smallest acceleration limit of the steer/drive joint in off-centered steerable robots.

Although the value obtained in [START_REF] Muir | Kinematic modeling of wheeled mobile robots[END_REF] depends on the trajectory, to respect the acceleration limits at all times, we can conservatively use, for 𝛿 2 , the maximum value over all possible trajectories in a bounded domain around the singularity. This value exists, since 𝛿 2𝑐 is upper-bounded, in such a bounded domain around the singularity. In applications involving human-robot collaboration, the trajectory is generally unknown a priori. In this case, we need to evaluate the maximum 𝛿 2𝑐 online. For this, we use:

𝑚𝑎𝑥(𝑥 𝑘 ) = { 𝑥 𝑘 , 𝑥 𝑘 > 𝑥 𝑘-1 𝑥 𝑘-1 ,
𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒 , which will store the input argument with highest magnitude, where ( * ) 𝑘 and ( * ) 𝑘-1 denote a value at the current and the previous sampling instances respectively. Also, (12) has shown empirically (the authors intend to prove this in the future) to evaluate to a positive value in the neighborhood of kinematic singularity. In this region of interest, where respecting the acceleration limits becomes critical, we set 𝛿 2 to 𝑚𝑎𝑥(𝛿 2𝑐 ). We should point out that this is the minimum value that can be used in (5'), while respecting the joint acceleration limit. Indeed, we need the minimum value so as to obtain the highest accuracy in evaluating the steer rate command. Finally, the online evaluation of 𝛿 2 is done using:

𝛿 2 = { 𝛿 1 ∀ 𝛿 2𝑐 ≤ 0 𝑚𝑎𝑥(𝛿 2𝑐 ) ∀ 𝛿 2𝑐 > 0 . ( 13
)
Thanks to [START_REF] Campion | Structural properties and classification of kinematic and dynamic models of wheeled mobile robots[END_REF], the smallest 𝛿 2 value can be obtained online and set only in the vicinity of singular configurations at which the acceleration limits are to be monitored. Away from the critical zone (around singularity), this formula provides negligibly small value (𝛿 1 ) for 𝛿 2 , consequently much higher accuracy for (5'). In what follows we prove that using ( 13) guarantees respecting the joint acceleration limits:

Case I: 𝛿 2𝑐 ≤ 0 From ( 12), this case corresponds to:

√|𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| 𝛽 ̈𝑖(𝑚𝑎𝑥) ⁄ ≤ 𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 ,
and we can assume that:

𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 = √|𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| 𝛽 ̈𝑖(𝑚𝑎𝑥) ⁄ + 𝑐 , ( 14
)
where 𝑐 𝜖 ℝ + (positive semidefinite). Substituting by ( 14) in [START_REF] Oftadeh | A novel time optimal path following controller with bounded velocities for mobile robots with independently steerable wheels[END_REF] where 𝛿 2 = 𝛿 1 we obtain:

𝛽 ̈𝑖 = 𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 ) |𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| 𝛽 ̈𝑖(𝑚𝑎𝑥) + 2𝑐 1 √ |𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| 𝛽 ̈𝑖(𝑚𝑎𝑥) + 𝑐 1 2 , ( 15
)
where 𝑐 1 = (𝑐 + 𝛿 1 ) 𝜖 ℝ + . Rearranging we obtain:

| 𝛽 ̈𝑖 𝛽 ̈𝑖(𝑚𝑎𝑥) | = |𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| |𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| + 2𝑐 1 √|𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )|𝛽 ̈𝑖(𝑚𝑎𝑥) + 𝑐 1 2 𝛽 ̈𝑖(𝑚𝑎𝑥) , (16)
From ( 16), it is evident that the right hand side will always be smaller than one. Consequently, the steer joint acceleration will comply with the maximum limit.

Case II: 𝛿 2𝑐 > 0 In this case, we assume that the value of 𝛿 2 is constant and as such [START_REF] Oftadeh | A novel time optimal path following controller with bounded velocities for mobile robots with independently steerable wheels[END_REF] still holds true. This is a reasonable assumption after few movements of the robot passing by kinematic singularity, where it quickly converges to the maximum value of 𝛿 2𝑐 . Then [START_REF] Muir | Kinematic modeling of wheeled mobile robots[END_REF] becomes:

√|𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| 𝛽 ̈𝑖(𝑚𝑎𝑥) ⁄ > 𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 ,
and we can assume that:

𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 = √|𝑘( 𝝃 ̇ 𝑏 , 𝝃 ̈ 𝑏 )| 𝛽 ̈𝑖(𝑚𝑎𝑥) ⁄ -𝑐 , (17)
where 𝑐 𝜖 ℝ + . Substituting by ( 17) in [START_REF] Oftadeh | A novel time optimal path following controller with bounded velocities for mobile robots with independently steerable wheels[END_REF], we obtain the same formulae in ( 15) and ( 16) with 𝑐 1 = 𝑚𝑎𝑥(𝛿 2𝑐 ) -𝑐.

However the definition of the 𝑚𝑎𝑥( * ) function guarantees that 𝑚𝑎𝑥(𝛿 2𝑐 ) ≥ 𝑐, so 𝑐 1 ≥ 0 and consequently 𝛽 ̈𝑖 ≤ 𝛽 ̈𝑖(𝑚𝑎𝑥) .

IV. BENCHMARK TESTING TRAJECTORY

In this section, we propose a velocity trajectory to benchmark test the model and controller performances w.r.t representational and kinematic singularities. The benchmark is composed of five motion profiles (all defined in the robot frame), depicted in Fig. 2: 1) ICR approaching, coinciding with and departing from a steering axis. We employ a parabolic ICR motion profile with vertex at the steering axis (note that a straight line would impose no motion on the steering joint).

2) ICR coincident with a steering axis: the robot pivots about that axis.

3) Straight line motion in the direction of one of the axes (ICR at infinity). This tests the proposed singularity avoidance algorithm for zero angular velocity, i.e., at a representational singularity of ICR-based kinematic models. It also tests the developed forward kinematic model, since it will lead to a column of zeros, hence a rank loss in 𝑭 2 .

4) Zero linear and angular velocities 𝝃 ̇ 𝑏 = [0 0 0] 𝑇 , which result in joint angles being undefined, refer to (4). 5) Straight line motion profile between two of each of the steering axes (i.e., six straight lines for a 4-steerable WMR). This motion profile tests the performance of kinematic models developed using only two steerable wheels, since then it will result in undefined steer joint values.

Since in our model development, we use four steerable wheels, we will exclude the fifth test from our benchmark trajectory. The results of numerical simulations (in C++) of trajectories 1-4 are shown in Fig. 3.a, where 𝛽 ̈𝑖(𝑚𝑎𝑥) is set to 5 𝑟𝑎𝑑/𝑠 2 . To ensure a smooth behavior of each motion test, a linear trajectory with 5 th order blends (indicated in the subscript) is employed:

𝑇 𝑙5𝑏 = { 𝑎 0 + 𝑎 1 ∆𝑡 1 + 𝑎 2 ∆𝑡 1 2 + 𝑎 3 ∆𝑡 1 3 + 𝑎 4 ∆𝑡 1 4 + 𝑎 5 ∆𝑡 1 5 ∀ 𝑡 𝑖 ≤ 𝑡 < 𝑡 1 𝑎 6 + 𝑎 7 ∆𝑡 2 ∀ 𝑡 1 ≤ 𝑡 < 𝑡 2 𝑎 0 + 𝑎 1 ∆𝑡 3 + 𝑎 2 ∆𝑡 3 2 + 𝑎 3 ∆𝑡 3 3 + 𝑎 4 ∆𝑡 3 4 + 𝑎 5 ∆𝑡 3 5 ∀ 𝑡 2 ≤ 𝑡 < 𝑡 𝑓 . ( 18
)
Constants 𝑎 0 → 7 in (18) depend on initial and terminal conditions, 𝑡 𝑖 (𝑡 𝑓 ) denotes initial (final) time, and ∆𝑡 1 = 𝑡 -𝑡 𝑖 , ∆𝑡 2 = 𝑡 -𝑡 1 , ∆𝑡 3 = 𝑡 -𝑡 2 , while 𝑡 1 = 𝑡 𝑖 + 0.1 * (𝑡 𝑓 -𝑡 𝑖 ) and 𝑡 2 = 𝑡 𝑓 -0.1 * (𝑡 𝑓 -𝑡 𝑖 ).

V. EXPERIMENTS AND DISCUSSION

In this section, we present the experiments conducted on the Neobotix MPO700 mobile robot to assess the proposed model, compare it with the embedded controller. The experiments are shown in Fig. 4, and in the video attached to this paper (available online at: IDH-LIRMM youtube channel 2 ). The robot driver allows two modes of commands; joint velocity or robot velocity modes. We use the former to test the proposed model while the latter (employing the embedded model) is used in the comparative study. In a first experiment, the testing trajectory shown in Fig. 3.a (top) is sent in robot velocity mode, to evaluate the joint commands output by the embedded model. In a second experiment, the output of our inverse kinematic model shown in Fig. 3.a (middle) is used to control the robot in joint velocity mode. Fig. 5.a and Fig . 5.b respectively show the results for the embedded and developed models. For test 1 (parabolic motion of the ICR), the embedded controller gives a velocity peak for the steering joint in the neighborhood of the kinematic singularity, green curve, at 6.3 𝑠 on Fig. 5.a (top). This corresponds to a steer angle change of 180 degrees in a very short time (see Fig. 4 (top) at t = 6 s and t = 7 s), implying that the embedded model probably employs steer position, rather than steer velocity control. Corresponding wheel velocity response can be seen in Fig. 5.a (middle) and the effect of such inconvenient velocity command on the velocity error is evident in Fig. 5.a (bottom). The otherundesirable -steering velocity peaks in Fig. 5.a (top) are due to the fact that the embedded controller goes to each initial trajectory configuration as quickly as possible.

The effect of the proposed model on the steering joint velocity is shown in Fig. 5.b (top). As shown, when approaching kinematic singularity, the velocity of the singular steer joint slows down to 0 𝑟𝑎𝑑/𝑠 at the kinematic singularity, with damped steer/drive rates in vicinity (observe Fig. 4 (middle) between t = 6 s and t = 7 s). Such effect is favorable, as it makes all the velocity space of the robot accessible, with minimum power consumption and with no risk of damage to motors performing at their top limits. Such damped behavior in the steering (Fig. 5.b, top) and driving (Fig. 5.b, middle) results in much smaller velocity error w.r.t the desired trajectory (Fig. 5.b, bottom). Both models show satisfactory response in the 3 other tests and as such the response is omitted from Fig. 4.

VI. CONCLUSION

A complete kinematic model for steerable wheeled mobile robots has been presented in terms of forward (odometry), inverse (actuation) kinematics, and minimum steer angle initialization models. The inverse kinematic model presented is free of representational singularities. Additionally, a numeric treatment is provided to solve the kinematic singularity, hence providing a completely singular-free model. A benchmark velocity trajectory is proposed, to evaluate the performance of the developed model in all singular conditions that can be encountered by such systems. Using the proposed benchmark test, the developed model has been tested on the Neobotix MPO700 robot, and shown superior results as compared with the embedded controller.

  In this equation, 𝒌 ̂𝑏, 𝒌 ̂𝑠𝑖 and 𝒋̂𝑤 𝑖 are unit vectors along the axes 𝒛 𝑏 , 𝒛 𝑠𝑖 and 𝒚 𝑤𝑖 respectively, 𝑹 𝑏 𝑤𝑖 = 𝑹 𝑏 𝑠𝑖 = 𝑟𝑜𝑡(𝒛 𝑏 , -𝛽 𝑖 ) and 𝑹 𝐼 𝑏 = 𝑟𝑜𝑡(𝒛 𝐼 , -𝜃) are 3 × 3 rotation matrices, the vectors 𝑜 𝑏 𝑜 𝑐 ⃑⃑⃑⃑⃑⃑⃑⃑ 𝑏 , 𝑜 𝑠𝑖 𝑜 𝑐 ⃑⃑⃑⃑⃑⃑⃑⃑⃑ 𝑠𝑖 and 𝑜 𝑤𝑖 𝑜 𝑐 ⃑⃑⃑⃑⃑⃑⃑⃑⃑⃑ 𝑤𝑖

Fig. 1

 1 Fig. 1 Modeling schematic for the four fully motorized off-centered, steerable wheeled mobile base

For motion test 1 ,

 1 𝑡 = [4, 8[, we apply rigid body mechanics: the robot linear tangential velocity 𝑣 𝑏 = 𝑅𝜃 ̇, with 𝑅 the radius of curvature. For 𝜃 ̇= -1 𝑟𝑎𝑑/𝑠 (i.e., 𝑣 𝑏 = -𝑅), it can be shown that: 𝑥̇ 𝑏 = -𝑣 𝑏 𝑠𝑖𝑛(𝛾) = 𝑅 𝑠𝑖𝑛(𝛾) = 𝑦 𝑏 𝐼𝐶𝑅 and 𝑦̇ 𝑏 = -𝑥 𝑏 𝐼𝐶𝑅 . The base trajectory can be expressed as: 𝑦̇ 𝑏 = 𝑇 𝑙5𝑏 ( 𝑦̇𝑖 = 𝑏 0, 𝑦̇𝑓 = 𝑏 2ℎ 𝑥2 , 𝑡 𝑖 = 4, 𝑡 𝑓 = 8 ) 𝑥̇ 𝑏 = -( 𝑦̇ 𝑏 -ℎ 𝑥2 ) 2 -ℎ 𝑦2 , 𝜃 ̇= -1. (19)

Fig. 2

 2 Fig. 2 ICR position in the base frame in each of the five motion tests of the proposed benchmark testing trajectory.

Fig. 4 Fig. 3

 43 Fig. 4 Snapshots of the two experiments (test 1, with singular joint indicated by the red arrow). Top: embedded controller, Middle: developed model. Bottom: v-rep 1 simulation showing the ICR position.

  it is measured by the steer joint position sensor. Matrix

			𝒙 𝑤2
			2𝑏
	𝒙 𝑤3	𝒚 𝑏
			𝑜 𝑏		𝒙 𝑏	𝑜 ℎ1 , 𝑜 𝑠1	𝒛 𝑤𝑖
						𝒚 𝑤𝑖	𝒙 𝑤𝑖
	𝒚 𝐼	𝒙 𝑤4			𝑜 𝑤1	𝑜 𝑤𝑖 𝑜 𝑐𝑖	𝒗 𝑡𝑖 𝒗 𝑛𝑖
	𝑜 𝐼	𝒙 𝐼	𝒚 𝑠1	𝒚 ℎ1	𝒙 𝑠1	𝛽 1
					𝒙 ℎ1
			𝑑	𝒚 𝑤1		𝒙 𝑤1
						𝜑 1
					𝑟 𝑤
	𝑭 2(𝑑) +	= (𝑭 2 T 𝑭 2 + 𝜆 2 𝑰 3 ) -1 𝑭 2 T is the damped pseudo-inverse

  ') and to the denominator of the partial derivatives in 𝒇 1𝑖 :

		𝜕𝛽 𝑖 𝜕 𝑥̇ 𝑏 =	-𝑦 ̃𝑖 𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 + 𝛿 2	,
	𝜕𝛽 𝑖 𝜕 𝑦̇ 𝑏 =	𝑥 ̃𝑖 𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 + 𝛿 2	,	𝜕𝛽 𝑖 𝜕𝜃 ̇= ℎ 𝑥𝑖 𝑥̇

𝑏 + ℎ 𝑦𝑖 𝑦̇ 𝑏 𝑥 ̃𝑖 2 + 𝑦 ̃𝑖 2 + 𝛿 2 , (

ACKNOWLEDGMENTS

This work has been supported by the French region Languedoc Roussillon Midi Pyrénées (project CoBot@LR), by the PSA robotics department, and by French -German PHC Procope project ViNavHuBot.