Pierre Misse-Chanabier
email: pierre.misse-chanabier@inria.fr

Vincent Aranega
email: vincent.aranega@inria.fr

Guillermo Polito
email: guillermo.polito@inria.fr

Stéphane Ducasse
email: stephane.ducasse@inria.fr

A modular transpilation toolchain from Pharo to C

Keywords: Transpilation, Pharo, C language, Tools

The Pharo programming language runs on the OpenSmalltalk-VM. This Virtual Machine (VM) is mainly written in Slang, a subset of the Smalltalk language dedicated to VM development. Slang is transpiled to C using the Slang-to-C transpiler. The generated C is then compiled to produce the VM executable binary code.

Slang is a powerful dialect for generating C because it benefits from the tools of the Smalltalk environment, including a simulator that runs and debugs the VM. However, the Slang-to-C transpiler is often too permissive. For example, the Slang-to-C transpiler generates invalid C code from some Smalltalk concepts it does not support. This makes the Slang code hard to debug as the errors are caught very late during the development process, which is worsen by the loss of the mapping between the generated C code and Slang. The Slangto-C transpiler is also hard to extend or adapt to modify part of the translation process.

In this paper we present Illicium, a new modular transpilation toolchain based on a subset of Pharo targeting C through AST transformations. This toolchain translates the Pharo AST into a C AST to generate C code. Using ASTs as source and target artifacts enables analysis, modification and validation at different levels during the translation process. The main translator is split into smaller and replaceable translators to increase modularity. Illicium also allows the possibility to introduce new translators and to chain them together, increasing reusability. To evaluate our approach, we show with a use case how to extend the transpilation process with a translation that requires changes not considered in the original C AST.

Introduction

Smalltalk code is traditionally compiled to bytecode, which is interpreted by a virtual machine (VM) [START_REF] Black | Pharo by Example[END_REF][START_REF] Goldberg | Smalltalk 80: the Language and its Implementation[END_REF]. The OpenS-malltalkVM is the current virtual machine used by many IWST'19, July, 2019, Cologne, Germany 2019.

Smalltalk dialects, such as Squeak, Pharo and Newspeak. The OpenSmalltalkVM is mostly developed in Slang. Only platform dependant code is directly developed in C. Slang is described as a subset of Smalltalk that is trans-compiled (or transpiled) to C [START_REF] Guzdial | Squeak -Open Personal Computing and Multimedia[END_REF]. Developing in Slang enables developer to use Smalltalk live programming features and simulation of the VM [START_REF] Bera | Sista: a Metacircular Architecture for Runtime Optimisation Persistence[END_REF][START_REF] Ingalls | Back to the Future: The Story of Squeak, a Practical Smalltalk Written in Itself[END_REF][START_REF] Miranda | Two decades of smalltalk VM development: live VM development through simulation tools[END_REF] Slang. The Slang-to-C transpiler uses the Smalltalk abstract syntax tree (AST), transforms it, and writes the corresponding C code in a file. We observe several problems.

• Slang does not have the same semantics as Smalltalk. However, since Slang is described as a subset of Smalltalk, and developed in a Smalltalk environment, it is misleading for newcomers to Smalltalk VM development.

• The Slang-to-C transpiler accepts erroneous Slang codes as input, and translates them into invalid C code without throwing errors. Errors are caught during the compilation of the generated C code making them hard to debug. • The Slang-to-C transpiler is tightly coupled to the Smalltalk AST to produce code, making it difficult to extend.

While Slang has been successfully applied for twenty years to produce Pharo and Squeak Virtual Machines [START_REF] Ingalls | Back to the Future: The Story of Squeak, a Practical Smalltalk Written in Itself[END_REF][START_REF] Miranda | Two decades of smalltalk VM development: live VM development through simulation tools[END_REF], the work presented in this article is a reflection on how to provide a basis for a modular architecture for a transpiler, improving reusability. To experiment with this idea, we designed, Illicium, a new toolchain transpiling Pharo to C.

Illicium. We created a new transpilation toolchain from Pharo to C that we named Illicium. We use a metamodel approach to describe a subset of the C AST and generate corresponding code. We also use the metamodel to generate some tooling for the C AST, in the form of diverse visitors such as walker and structural analysis visitors. This approach allows us to create tooling around the C AST that is independent of the transpilation process.

Illicium's translator is split in several modular and replaceable components. A main translator dispatches the translation to smaller, specialized translators, each taking care of one of the Pharo AST node types. Each of these specialized translators are responsible to accept or reject their input, to allow for early error detection. Moreover, it uses a mechanism to treat messages depending on their receiver's types, rather than only on their selectors.

The paper is structured as follow: We first give an overview of how the Slang-to-C transpiler works, and focus on problems we want to solve in Section 2. We then introduce our solution in the form of the Illicium compilation toolchain in Section 3 and how it solves the problems we outlined in Section 2. To support our claim, we show how to extend our tool in Section 4. Next, we explain some of the semantic gaps between Pharo and C that have to be kept in mind when extending Illicium in Section 5. Section 6 compares our solution with other approaches. Finally Section 7 describes several possible future work before concluding in Section 8.

Slang

To respect a long tradition of writing everything in Smalltalk, the Pharo Virtual Machine is developed in Smalltalk itself. Yet, it was decided to translate it to C to produce a reliable and efficient VM [START_REF] Ingalls | Back to the Future: The Story of Squeak, a Practical Smalltalk Written in Itself[END_REF]. To allow the VM developer to express C code in Smalltalk, Slang, a subset of the Smalltalk language is used [START_REF] Guzdial | Squeak -Open Personal Computing and Multimedia[END_REF]. Slang code is translated to C code during a process called source to source compilation, or transpilation. The generated C code is then compiled.

Using Slang in a Smalltalk environment allows for a quicker VM development through live programming and simulation [START_REF] Ingalls | Back to the Future: The Story of Squeak, a Practical Smalltalk Written in Itself[END_REF][START_REF] Miranda | Two decades of smalltalk VM development: live VM development through simulation tools[END_REF]. Slang is actively used for the OpenSmalltalk VM development and more specifically for the development of the operating system independent part of the virtual machine as well as plugins. Two different kinds of plugins are developed: internal and external. Internal plugins are compiled with the VM sources, whereas external plugins are compiled on their own, and dynamically linked to a running VM.

Slang has been used for decades and offers a powerful language to express C concepts. However, Slang induces a huge learning curve and the Slang-to-C transpiler tends to make the generated C code hard to debug, especially for newcomers. We identified three main problems that are error prone for VM plugins developers: P1 Slang does not have the same semantics as Smalltalk. P2 The Slang-to-C transpiler does not check for semantic violations. P3 The Slang-to-C transpiler is hard to extend.

In the following sections, we show how these points are source of mistakes and introduce bugs that should be caught earlier in the development process.

Semantic mismatch

New Slang users usually come from Smalltalk to understand the underlying system or add a custom plugin for the VM they're using. They often have a Smalltalk background and mindset, rather than a C one.

Slang allows the developer to use the Smalltalk syntax, and most of its concepts, Slang allows the developer to use almost all Smalltalk syntax and concepts, but it has its own semantics and only a subset is translated (e.g., dynamic arrays are not supported). Therefore, Slang is a subset of Smalltalk from a syntactic point of view, but a different language. The Slang-to-C transpiler does not prevent the use of all unsupported Smalltalk features. These unsupported Smalltalk concepts are translated in erroneous C code, that the C compiler rejects at compilation time. As the Slang-to-C transpiler does not keep the mapping between the Slang code and the generated C code, debugging this kind of errors is often complicated. The Slang-to-C transpiler also inlines significant amount of code, which worsen this problem. Let's do a first plugin in Slang to illustrate one of the issue of the current transpilation.

A first plugin as illustrative example. To create a new plugin, we start by subclassing InterpreterPlugin, which gives us access to plugins properties such as the stack manipulation. We add to this class a class variable (Listing 1), as it is common to do in Smalltalk. In Smalltalk semantics, class variables values are assigned in any method in the class, or through accessors. In this example, the class variable is set to 5 in aPluginMethod, a instance side method (Listing 2). Listing 2. An instance side method assigning a value to a class variable.

As shown in Listing 3, when translated to C, the class variable is transformed in a #define macro. The value of this macro is the class variable value obtained during the transpilation phase. The assignment is translated simply as a C assignment and stays equivalent to the Slang code. This results in the following compilation error from the C compiler:

error : lvalue required as le f t operand o f assiдnment This happens because during the C pre-processing phase macros are replaced with their values. This means that after this phase, AClassVariable = 5; is replaced by null = 5; 1 , which is an attempt to assign a value to a value and isn't tolerated by the C compiler. This particular error can be hard to understand when the developer is unaware of the way the Slang-to-C transpiler translates class variables.

This example illustrates a difference between Slang's semantic and Smalltalk's (P1), and that the semantic violation is not caught by the transpiler (P2).

Slang's development process

Slang's development process requires more steps than Smalltalk's as shown in Figure 1. In a Smalltalk development process, the written Smalltalk code is directly compiled into executable bytecode (i.e., a Compiled Method) and interpreted by the VM. When developing in Slang, the written code goes through three stages, with different sets of constraints and enforcements. As Slang is developed in a Smalltalk environment and is a subset of Smalltalk, it first goes through the same steps as regular Smalltalk code and is therefore also compiled to 1 null is also a macro defined in the plugin file produced by Slang as 0, this assignment is therefore actually 0=5 after the pre-processing phase executable bytecode. During this first stage, the Smalltalk compiler first parses the code and creates the method's AST. This compilation process then detects some errors and mistakes such as syntactic errors or undeclared variables.

Next, The Slang-to-C transpiler computes a set of classes to be translated and processes them in the second stage of the transpilation. During the transpilation process, the transpiler handles the AST of input classes and methods, prepares them to be translated and emits the corresponding C code. The Slang-to-C transpiler checks for some unsupported features usage such as the usage of static arrays, and interrupts the translation process with an error if it encounters any of them. It then flushes the emitted C code into a file. Finally, the generated C code is compiled using a traditional C compiler. During this last stage of translation, translation errors, i.e., invalid C code, are caught by the C compiler.

Surprising translations

In Smalltalk, all interactions between entities, besides assignments, are done via message sending. Therefore, their translations are an important part of the process and they require a special care. Slang introduces a distinction between message sends: it considers special message sends and normal message sends. This distinction is made during the transpilation process and induces a difference in the message send translations.

Special messages. Let us suppose a user overloads the #= binary method for a plugin's class. When sending this newly defined message to self, the overload is ignored, and is translated as the C == operator systematically without warning or error from the transpiler. Special messages are messages that denote a special symbol or a specific function in Slang. To each of these messages an ad-hoc translation is applied, regardless of their usage. There are 125 special messages. These messages and their associated translations are statically predefined in the CCodeGenerator » initializeCTranslationDictionary method.

Normal messages. Normal message sends are translated as simple function calls. Messages are translated without verification that the corresponding function will be defined. For example, if a developer sends the #sqrt message to a Boolean instance, it is translated as a function call sqrt(. . . ) even if this message is not understood by Booleans. This shows that a function call is generated from a message send even if the function is not compatible with the receiver's type. This translation generates invalid C code. This error is caught during the generated C code compilation.

Method generation. A plugin must inherit directly or indirectly from the InterpreterPlugin class. The transpiler generates code for methods contained in the plugin class and every one of its superclasses until the InterpreterPlugin class, which is excluded. As a consequence, the #class method is not inherited from Object. Class side methods are therefore not usable from Slang code and only instance sides methods are translated. The Slang-to-C transpiler translates unary and keywords methods as function definitions, and inlines binary messages rather than generating their methods. Methods corresponding to a message send to the super pseudo variable are inlined, leaving no traces of inheritance in the generated code. Method redefining a special messages are ignored.

In this part, we saw that inheritance in Slang has a different meaning than the one in Smalltalk (P1). We also saw that the Slang-to-C transpiler allows for invalid function calls (P2). Finally we explained Slang special messages are stored in a table, making it hard to derive a dedicated translation regarding the context of the message send, limiting extensions (P3).

All those reasons make starting to code in Slang a challenge. Since errors are often caught very late in the generation process (i.e., during C code compilation), as the transpiler does not keep the mapping between the C and Slang codes and it heavily uses method inlining, it is very complex to infer from which parts of the code the errors come from. Moreover, the semantic mismatch also makes it hard to reason about the written code, and forces the developer to code in a Smalltalk like language while thinking about the results she wants in C.

Illicium: a modular toolchain

To solve the limitations of Slang and the Slang-to-C transpiler, we created a new compilation toolchain from a Limited Pharo to C as a reflection on how to improve the transpilation process with a modular design. The toolchain must implement the three following requirements: R1 The generated C code must be semantically close from what has been expressed in Smalltalk. R2 If features are not supported by the toolchain, the error must be caught as soon as possible. R3 The whole toolchain must be modular to support easy modifications and extensions.

Structure Overview

An overview of our transpiler is illustrated in Figure 2. Illicium relies on AST transformations. Using ASTs as source and target artifacts of the translation increases the analysis, validation and transformation potential of the toolchain (R2 and R3). Limited Pharo is used as toolchain input. Limited Pharo defines a subset of Smalltalk that will be translated while trying to keep an equivalent semantic (R1). Not all concepts of Pharo are translated, but as the toolchain is designed to be modular, it can be easily extended to add or replace feature support. Once the Limited Pharo code is compiled by the standard Pharo compiler, several analyses are run on the produced AST. These analyses check for unsupported features or modify the AST. Although most analyses and modifications are optional, Illicium requires of the the Pharo AST to be typed. We currently use the Phineas type inferencer [START_REF] Passerini | An extensible constraint-based type inference algorithm for object-oriented dynamic languages supporting blocks and generic types[END_REF] to annotate the AST with concrete Pharo types. Such type information enables us to translate messages depending on the type of the receiver, as well as detect messages misuse early in the transpilation process. After the preliminary passes, the modified and annotated Pharo AST is translated into a C AST using a dedicated translator. Exactly as for the Pharo AST, analysis and modification phases are run in the produced C AST if needed. Finally, the C AST is generated by prettyprinting it in files. The generated C code is then compiled to produce a binary that can be used as a plugin for the VM.

Generative approach to AST creation

To provide a modular generation toolchain, we decide to heavily rely on AST transformations either to change the AST structure or to pass from an AST to another. In the case of Illicium, the translation is performed between the Pharo AST and the C AST. The Pharo AST is part of the Pharo system and can be directly used as such. To produce the C AST, we used a metamodel approach. We manually created a C AST metamodel using FAMIX [START_REF] Demeyer | FAMIX 2.1 -The FAMOOS Information Exchange Model[END_REF], and we used code generation to automatically derive validation visitors and a simplified C AST in Pharo. This approach allows us to reuse and easily extend the C AST through the metamodel and to automatically generate common artifacts.

An excerpt of the C AST metamodel is depicted in Figure 3. We see 4 main concepts from the C AST: AST Code generation. From this metamodel, we generate a simplified code for the AST, free from FAMIX dependencies. The class hierarchy generated from the metamodel presented in Figure 3 is shown in Figure 4. The generator generates the necessary accessors for each relationship in each corresponding class. For each container relationship that can contain many instances of other classes in the metamodel, it generates an initialize method that creates default, empty, ready to use collections. On top of these basic accessors and initializers, the generator generates class testers (e.g., #isBlock) and a basic visitor mechanism. Accessors methods are generated, as well as class tester methods. A default initialize method is generated to initialize an instance variable that contain zero or many entities with a default collection.

Visitors. The generator also generates visitors that are applied to the C AST if required. Figure 5 shows the generated visitor hierarchy from the C AST metamodel. Abstract and Walker are used as base classes and Walker gives an automatic way of navigating through the AST. Printer gives a first display of the AST. StructureValidator and StructuralErrorCount provide a structural validation of the AST code. Their generation relies on the type of each properties in the metamodel. For each property of a class, a special assert is generated in the code of the visitor ensuring that a C AST is structurally correct. StructuralErrorCount uses the StructureValidator, but does not stop on each false assertion and counts the errors instead. The C AST code and tools generated from the metamodel are purely standalone and are independent from the translator and FAMIX. We can therefore develop tools dedicated to the C AST, and reuse them in various contexts where the C AST must be handled. This metamodel approach improves the modularity of the transpilation process and facilitates its extension (R3).

Modular translation

Supporting a modular translation goes with the idea of distributing as much as possible the translation efforts into small interchangeable translation units. In Illicium, we created translation units for the dedicated translation of each Pharo AST node type. These units are responsible for producing from a Pharo AST node the equivalent C AST fragment. They also detect some AST input patterns and adapt their translation, raising errors if required. In this section, we briefly present how the translator is built, show how translation units are written and report errors before focusing on message translation.

Translation structure

The current Illicium translator is built upon a visitor of the Pharo AST. This main translator is composed of smaller translators, specialized to translate only one type of AST node. For each node the main translator visits, it invokes the corresponding translator unit for that kind of node. Each node translator translates the node it gets, and asks the main translator to translate the sub-AST of this node.

An example of the translation process is pictured in Figure 6 for a simple message send in a method. The main translator is visiting a message send #ifTrue: and dispatches this node to the MessageNodeTranslator. The MessageNodeTranslator takes care of the current selector and asks the main translator to dispatch the receiver and the arguments onto the correct specialized translators. Consequently, the true literal is sent to the LiteralValueNodeTranslator while the empty array is sent to the LiteralArrayNodeTranslator. The process repeats until every node in the method's AST is visited.

Node translator

Each of these specialized translation units is independent and replaceable. They only need to provide the method: #trans-lateNode:withMainTranslator:. This method must return a fragment of a C AST.

For example, a simplified version of this method for the AssignmentNodeTranslator is shown in the Listing 4. This assignment translator creates a new AST node corresponding to a C AssignmentOperator, and initialize its operands with the AST fragments that are returned by the dedicated translation unit for these nodes.

Transpilation errors

Each unit translator is responsible for accepting or rejecting the AST node it receives as input. In the example described in Section 2.1, we saw that the Slang-to-C transpiler translates class variable as C macro definition, therefore it does not support class variable assignment. However, the transpiler does not enforce the read only property implied by this translation choice. The assignment AClassVariable := 5. from the code should throw an error to forbid the user to use this unsupported feature. This expression's AST is shown in Figure 7. For the translation of such an AST fragment, three translation units are used: a ClassVariableTranslator, an AssignmentN-odeTranslator and a LiteralValueNodeTranslator. The ClassVari-ableNodeTranslator receives as input the ClassVariableNode representing the class variable AClassVarNode and performs the read-only check from it (Listing 5).

The translator checks if its parent node is an AssignmentNode and if it is, if the variable of the assignment is the node the translator is currently treating. (lines 2-4). The translator throws an error if it identifies that the ClassVariableNode is accessed in write, otherwise, it translates it as an Identifier node instance from the C AST (lines 5-6).

Each node translator is responsible for its own transpilation errors, the semantic enforcement is dedicated to each kind of node (R2). Moreover, this approach by small translation units introduces a high modularity as they can be easily modified or replaced (R3).

A focus on message translation

As we mentioned in Section 2.3, messages are the basis of interactions between objects. We saw that Slang makes the distinction between special message sends and normal message sends. More specifically, the translation architecture behind special messages makes it hard to extend. Moreover, the translation as function calls or inlines for normal messages is ad-hoc and cannot be changed depending on the type of the receiver. In that regard, we focused on providing a unified and modular approach for message sends translations depending on the receiver's type.

Translation principle. In Illicium, the Pharo AST is required to be annotated with type information. This type information is used by the translator to conduct the code generation. It also allows us to detect invalid message uses during the transpilation process. When the MessageNodeTranslator is called with an input node, it looks for the type of the receiver. Depending on the type of the receiver, it redirects the translation to a special class, a translation class, that represents the corresponding type in the target language. The methods of the translation classes define how each message will be translated. We created translation classes for primitive types. This translation class is instantiated with the receiver's AST as value. The message is dynamically sent to this newly created instance of the translation class using the #perform:withArguments: message. Finally, the translation classes method returns the C AST fragment corresponding to this message send. The #perform:withArguments: message is overridden for those translation classes to have control over the translation and to prevent messages from Object to be inadvertently accepted by the transpiler. Those translation classes implement the methods that are authorized for the translation and return C AST fragments. A message not understood by a translation class is considered invalid, and throws a compilation error.

Taking the same input as the previous example (Figure 6), the #ifTrue: selector is performed on an instance of ILBoolean type which is the translation class for the Boolean type. IL-Boolean understands the #ifTrue: selector and knows how to produce the corresponding C AST fragment. This method asks the Main Translator to translate the LiteralNode containing the true literal, and the LiteralArrayNode that contains the empty static array. Finally, the #ifTrue: method returns an If node from the C AST to the main translator.

Advantages. Having translation classes present several advantages:

• Methods and translation type for Smalltalk classes that are available for translation are browsable, modifiable, and extendable. This feature also improves the modularity of the translator (R3). As a consequence, several messages with the same selector have different translations depending on the receiver's type. • Translation classes being used only for the translation process, they also offer a dedicated documentation. This enables transpilation developers to explain the semantic chosen for each types and methods, as well as exposing their limitations (R2). • Statically detectable invalid message errors come up during the translation process rather than in the C compilation process (R2).

Users are able to browse and tweak the translation, replace part of the translation process without affecting the target language and create new analyses on the target code using generated visitor base classes. This infrastructure improves the area of the translations and provides a solution to three requirements exposed in Section 2.

Extending Illicium: an illustration

To illustrate the modularity and extensibility of Illicium (R3), we describe the process of adding a translation for the #to:do: message on SmallInteger.

Analysis. The #to:do: method is a for loop. It is defined on SmallInteger and takes two arguments: the upper bound of the loop and a block representing the sequence of instructions that is executed by each iteration. Each SmallInteger value between the two bounds is passed as argument to the block.

1

(2 + 3) to: 10 do: [ :i | "do a computation with i" ] Listing 6. #to:do: call in a smalltalk method There are three ways of translating this message send in C: a for loop, a while loop or a call to a recursive function. In this example, we decided to implement it as a while loop where the loop variable has the same name as the block's parameter.

The following C fragment (Listing 7) shows the C code we aim to generate. Note that the variable i does not exist outside of the Pharo BlockClosure. We therefore enclose it in another C Block. Extending the Metamodel. The current C AST does not have a While loop concept, we therefore need to add it. A C While is a Statement containing an Expression which is the condition and a Statement which is its body. This is represented in the metamodel in Figure 8.

After this addition to the metamodel, the metamodel code for the new C AST node and the new version of the visitors are generated.

Extending the Translator. #to:do: is a message and is therefore translated by the MessageNodeTranslator. As we described in the Section 3.3.4, the MessageNodeTranslator send a dynamically created message to an instance of a translation class. Here, as we want to support this message for Small-Integer, we implement the method #to:do: on its translation We see in the Listing 8 a simplified version of the C AST to return. In the first place, we ensure that aBlock takes exactly one argument (line 3-4). We then retrieve the name of this argument to use it as the loop variable name (line 5). The methods finally builds the AST fragment and returns it (lines 6-25). In this Block there is the declarations of a variable initialized with the AST fragment corresponding to the receiver's translation (lines 8-11) and a While statement (line [START_REF] Rigo | PyPy's approach to virtual machine construction[END_REF][START_REF] José E Rivera | Orchestrating ATL model transformations[END_REF][START_REF] Wendell | An MDE Approach for Automatic Code Generation from UML/MARTE to OpenCL[END_REF][START_REF] Yasumatsu | SPiCE: A System for Translating Smalltalk Programs Into a C Environment[END_REF][17][18][19][20][21][22][23][24]. This While contains an Expression which is a condition (line 14-17) and a body which is a Block (line 18-23). The body of the While loop contains the AST fragment of aBlock's translation (line 20) and the loop variable incrementation (line 22-23).

Pretty-printing. Finally the last part of the process is the production of the C code pretty-printed from the C AST. The PrettyPrinterVisitor therefore has to implement the #visitWhile: method. Listing 9. Pretty-printing method for the C While concept.

Listing 9 shows how the method is implemented. We observe that only little code is related to the While concept and that the code generation is quickly distributed to the condition and body of the While statement.

The challenges of defining a Limited Pharo

C and Smalltalk have different designs, and a different level of abstraction. Mapping the features offered by each language is a difficult task. While defining the supported input, a number of semantic gaps appear. The transpiler developer should be aware of such gaps to provide correct translations or warn the user if they are not supported.

We showed in the Use Case Section (Section 4) an example of how Illicium is extended to enable transpiler developers to add new translations, modify existing ones or remove them. It is the responsibility of the transpiler developer to choose the semantic she gives to a feature in the limited language. Therefore she can decide to overlook a problem, if it does not happen in the context she manipulates. For example, Slang ignores the integer overflow problem and therefore does not pay the run-time cost of checking overflows after operations on integers.

Regardless of the translation decisions, those problems exist, and have to be dealt with when designing a limited version of Pharo to be translated to C. We outline in this section the challenges a transpiler developer faces when translating Pharo code to C code. Both languages offering numerous features, we are focusing on features we think are the most important.

Primitive data-types

The C language provides four primitive data-types: integer, float, character and boolean. C provides a handful of builtin operators for each of them based on hardware available operators. On the other hand, equivalent to those primitives types are Objects in Pharo and they come with rich libraries allowing their uses and manipulations. It means that although a few messages have a direct mapping to their C operators counter parts, most of them have to be translated by hand to be available.

Floats and booleans types have a similar semantic on both sides, but integers and characters are problematic.

Integers. In Pharo, Integers are considered infinite because they return a different representations of an Integer when it is needed, in a transparent way for the user. In C, however, the developer has the responsibility to choose the size of the integer to be big enough for its purpose.

When computing an arithmetic operation, if the result is too big for the representation the developer chose, the operation causes an overflow. In Pharo, the SmallInteger's method detects the overflow, and returns a LargeInteger instead. But in C, the result is just different. If the developer does not expect the overflow, the resulting program has an undefined behavior.

Characters. The character type in C is just a byte and does not involve encoding. Character's encoding in C is interpreted as ASCII by many libraries. In Pharo characters are represented by unicode points. The first 128 Unicode code points are the ASCII characters and are encoded on seven bits. Those characters are therefore not a problem. Any Unicode code point's interpretation, when the code point is superior to 128, depends on the library used and will be problematic if they are encoded on more than a byte.

Strings. Although Strings support is not available as a primitive data-type in C, they are as useful as they are used. In C, as an approximation, the convention is to terminate an array of characters by a null character (\0) which is added automatically in the case of a string literal by the compiler.

Pharo represents them using a Pharo Array of Characters. Pharo String's representation is chosen transparently for developers by the system, depending on their content. They are an instance of ByteString if every character it contains is encodable on a byte, or an instance WideString otherwise. They inherit the encoding problems from Characters.

Symbols. Symbols are interned Strings i.e.,Strings that are only created once and shared across the program 2 to minimize memory footprint for example 3 . Symbols are a kind of literal in Pharo but they do not have a C native equivalent, although libraries implementing them exist. Similarly to Strings, Pharo supports ByteSymbols and WideSymbols transparently for the user and also inherit the encoding problems from Characters.

Object Oriented Programming

C does not support Object-Oriented Programming (OOP) features whereas Pharo is basing everything on them. This discrepancy is the most obvious one to notice and is dealt 2 In the Smalltalk context, shared across the image 3 See the Flyweight design pattern with in a several different ways ranging from ignoring OOP completely, to create a support for OOP features.

For example Slang uses OOP as an organization system on the Smalltalk side and removes any trace OOP features in the generated code. SPiCE [START_REF] Yasumatsu | SPiCE: A System for Translating Smalltalk Programs Into a C Environment[END_REF] on the other hand recreates an equivalent of the Smalltalk environment, and implements OOP features such as dynamic message passing.

This issue is well documented in the literature and is beyond the scope of this paper. Still, Slang offers an interesting static limited inheritance model [START_REF] Miranda | Two decades of smalltalk VM development: live VM development through simulation tools[END_REF].

Slang's inheritance. In this model, plugin classes actually inherit other plugins instances side methods. Every method that is not redefined, is translated as one of the current plugin. The usage of the super pseudo variable is supported as well and the method call using super as receiver is inlined. This mechanism allows to reuse Slang code, while having no trace of inheritance in the generated code.

Arrays and collections

An Array is a chunk of contiguous memory of a specified size in C. It can be accessed using the square bracket operator. C requires for all elements to have the same type.

Pharo provides a rich collection library, of which Array is the closest counter part. Pharo's Array is a collection of a fixed size that contain elements of any types as well as the knowledge of its own size. Pharo's collections also provides developers with a wide range of methods allowing to iterate over them without having to know how they are represented whereas user have to describe how to iterate over a C array.

Block Closures

BlockClosure is an important feature that has several properties in Pharo:

• lexical closure • deferred execution • non local returns A block closure also accepts arguments, as well as defining new temporary variables. It is heavily used, most notably used for iteration and control flow It is syntactically represented by square brackets.

However in C, a block is a simple statement that contains statements surrounded by curly braces and they only support the creation of temporary variables.

Additional problematic Pharo features

Typing. Although not as visible as the previous features, dynamic typing is an important feature in Pharo.

Message passing is the mechanism allowing all interactions between entities in Smalltalk. It is therefore primordial. The principle of message passing is to send a message to an entity, without caring for its type. All that is required from this receiving entity, is that it understands that message. This method corresponding to the message is looked up in the class of the receiver and through the inheritance hierarchy if the it does not know it directly. An error mechanism is triggered if the method is nowhere to be found.

C takes another approach: static typing. The compiler enforce statically, that all functions used, are known, and that types used to call them are correct. C static typing allows the compiler to resolve bindings between a function calls and a function definitions at compile time. It also makes type verification possible during the compilation process, to prevent run-time type errors in the resulting program.

Memory management. In Pharo, memory management is taken care of by the VM, relieving the developer of that responsibility. In Pharo, developers only have to ask for a resource. This resource is handled by a Garbage Collector. When the Garbage Collector notices that the resource is not used anymore, it gives it back to the system.

C on the other hand, only manipulates memory, both static and dynamic. When manipulating dynamic memory in C, developers have to ask the underlying system to allocate a chunk of memory of a specific size. The developers are responsible for its manipulation, and to tell the system when they do not need that chunk of memory anymore, so the system can allocate it to another process. Developers are also able to unsafely access memory directly, which often results in crashes of programs. This access is not restrained and is a common errors when programming in C.

Related Work

Slang is a subset of Smalltalk that has been used successfully for two decades to develop the OpenSmalltalkVM [START_REF] Ingalls | Back to the Future: The Story of Squeak, a Practical Smalltalk Written in Itself[END_REF][START_REF] Miranda | Two decades of smalltalk VM development: live VM development through simulation tools[END_REF] (Section 2). The languages delimitation is hard to grasp, resulting in a huge learning curve for newcomers. The Slangto-C transpiler is too permissive, and accepts in the input code Smalltalk features it does not support. We improve its design with a modular approach, where error management is distributed on small, specialized translations units.

Several other projects successfully translated Smalltalk to C. Among them, Orchard [START_REF] Nash | An accidental translator from Smalltalk to ANSI C[END_REF] and later SPiCE [START_REF] Yasumatsu | SPiCE: A System for Translating Smalltalk Programs Into a C Environment[END_REF] aim at translating general purpose Smalltalk. They provide a runtime system replacement for the Smalltalk VM as well as replacement classes which implements similar methods as the ones available in the Smalltalk standard class library directly in C. They are called using dynamic look up, to preserve Smalltalk's messaging semantics. We use translation classes at compilation time to guide transpilation in a static manner as well as enabling early errors throw rather than implementing a substitute.

RPython 4 is a toolchain that provides a Restricted Python to C transpiler as well as a support framework to implement dynamic languages. Unlike Slang, RPython offers more features and feels more like writing Python than C [START_REF] Miranda | Two decades of smalltalk VM development: live VM development through simulation tools[END_REF]. The cost 4 https://rpython.readthedocs.io/en/latest/# for this abstraction is a less direct mapping to C. This requires long analyses to transform, which results in long compilation times [START_REF] Rigo | PyPy's approach to virtual machine construction[END_REF] and the generated code is quite unreadable making it difficult to debug.

Using successive ASTs transformations to pass from a formalism to another is equivalent to Model Driven Engineering (MDE) transformation chains [START_REF] Sánchez | Approaches for Model Transformation Reuse: Factorization and Composition[END_REF]. For example, Rodrigues et al., present a MDE approach to generate OpenCL code from UML [START_REF] Wendell | An MDE Approach for Automatic Code Generation from UML/MARTE to OpenCL[END_REF]. This kind of approaches rely on model transformations and models that conforms to metamodel. Our approach could have followed the same principle by directly handling C models that conform to the C AST FAMIX metamodel we built and use model transformation languages. Instead we decided to produce a simpler C AST version to cut FAMIX dependency, and to use Pharo reflexive capabilities as model transformations languages replacement.

Rivera et al., worked upon the ability to chain model transformations [START_REF] José E Rivera | Orchestrating ATL model transformations[END_REF]. They proposed a modeling language to express how one can link model transformation one to the other. Their system relies on an execution engine that interprets input models describing the transformations chain. Currently, Illicium does not provide an abstraction to express the ASTs transformations chaining, but we consider the production of a Domain Specific Language (DSL) dedicated to this task as future work.

Future work

Better way to write AST. As we saw in Section 4, writing an AST by hand is a tedious task. We would like to improve the way we write AST fragments to be able to ease the extension of the current translation classes.

Inlining. Generally speaking, inlining is the process to replace a function call by its code which prevents to pay for a function call at the cost of code size. Slang's Inlining improved the VM performances significantly when it was first introduced [START_REF] Ingalls | Back to the Future: The Story of Squeak, a Practical Smalltalk Written in Itself[END_REF]. An advantage of transpiling over compiling, is that we rely on the target language's compiler. C compilers have been the subject of research and optimizations and have evolved tremendously. After twenty years, does it still make sense to inline at the transpilation level, rather than allowing the C compilers to take care of it?

Experimenting with the translation. Illicium currently translates classes following a semantic similar to Slang's. We aim at enabling the user to choose how to translate their classes, for example to translate instance variables in a structure rather than as global variables. Illicium can and should also be extended to support higher level concepts with careful attention to the costs they induce. This will enable us to benchmark features, and measure the impact of using one translation rather than another.

Ease plugin testing. Plugins are currently compiled outside of the Pharo environment by a C compiler and their interfaces have to be created by hand. We would like to have a compilation pipeline that transpiles the plugin, compiles it, and plugs it in the current VM to be tested. A default interface to interact with the plugin could be generated as well.

Composing transformations for an adaptive toolchain. Illicium is designed around ASTs transformations. Transformations introduce validation, refactoring, going from one abstraction level to another. . . Expressing their composition is currently hardcoded in the system. We will propose a DSL dedicated to the expression of transformations compositions. This language will also allow the toolchain designer to express tasks that could be executed in parallel, increasing the transpilation speed. Such a language invites developers to code smaller composable transformations units that focus on specific independent tasks, increasing reusability, modularity and testing. It will be also interesting to explore how all these small transformations can be enabled or disabled at run time thus producing an adaptive toolchain. For example, the toolchain could adapt its optimisation or validation level regarding patterns identified in the user code.

Multi-level debugging. We showed that the toolchain we designed reduces potential surprises and errors thanks to small transformations units. However, trusting the toolchain does not imply that the user code does not contain bugs. Some bugs can be observed and caught at Smalltalk level, but others are only observed at run time. As future direction, Illicium will maintain a link between the Smalltalk code and the C code to allow the toolchain to report errors into the Smalltalk code (e.g., C syntactical errors). Moreover, conjointly used with C debug format information as DWARF [START_REF] Eager | Introduction to the DWARF debugging format[END_REF], this mapping would allow Illicium to propose a step by step run time debugging directly from Smalltalk.

Conclusion

In this paper we present Illicium, a new transpilation toolchain from Pharo to C that is extensible and allows early validations in the transpilation chain instead of waiting until the C compiler fails. This is possible because Illicium uses a C AST model that can be validated and transformed before the C compilation. For this, we use a metamodel approach that describes a subset of the C language and generates the corresponding AST. This metamodel approach also allows us to automatically generate tooling such as structural checkers.

Illicium's translator is split in several replaceable components. A main translator dispatches the translation to smaller, specialized translators, that take care of each of the Pharo AST node types. Each of these specialized translators are responsible to accept or reject their input, to allow for early error detection. Moreover, it uses a mechanism to treat messages depending on their reveiver's types, rather than only on their selectors.

We show how Illicium can be easily extended to be able to transpile new features. Finally, we describe the semantic gaps between Pharo and C that a transpiler developer should keep in mind when extending the Illicium transpilation chain.

1 InterpreterPluginListing 1 .

 11 A first plugin.

1 # 6 } 3 .

 163 Listing Generated C code for aPluginMethod.

Figure 1 .

 1 Figure 1. Code compilation process. Slang code is first parsed in a Smalltalk AST, before being compiled as a Smalltalk method. The Slang-to-C transpiler then uses the Smalltalk AST to generate C code. Finally, the C code is compiled.

Figure 2 .

 2 Figure 2. Illicium structure. Limited Pharo code is parsed in an AST. A type inferencer annotates Pharo nodes with concrete types. T he typed AST is then translated in the C AST. Finally, the C AST is pretty-printed.

Figure 3 .

 3 Figure 3. C AST metamodel excerpt. A Block is a Statement containing of a variable number of Statements. An Expression-Statement is a kind of Statement containing an Expression.

Figure 4 .

 4 Figure 4. Simplified generated code's model for the C AST.Accessors methods are generated, as well as class tester methods. A default initialize method is generated to initialize an instance variable that contain zero or many entities with a default collection.

Figure 5 .

 5 Figure 5. Visitors generated from the metamodel. Abstract and Walker are used as base classes. Printer gives a first display of the AST. StructureValidator and StructuralErrorCount provide a structural validation of the AST code.

Figure 6 .

 6 Figure 6. Translation process. The Main Translator dispatches the MessageNode containing the selector #ifTrue: to the MessageNodeTranslator. The MessageNodeTranslator then asks the Main translator to take care of the receiver and the argument of the message, which the Main Translator dispatches onto specialized visitor.

1 AssignmentNodeTranslator 6 (Listing 4 .

 164 anAssignmentNode value acceptVisitor: aTranslator) Simplified translation of an AssignmentNode

Figure 7 .

 7 Figure 7. Pharo AST for the expression: AClassVariable := 5. It is represented by an AssignmentNode assigning to the variable AClassVariable the literal value 5.

1 ClassVariableNodeTranslator

 1

3 5 ↑new 6 id: aClassVarNode name Listing 5 .

 565 and: [ aClassVarNode parent variable = aClassVarNode ]) 4 ifTrue: [ self error: ' ClassVariables are read only in Limited Pharo.' ]. Identifier Class Variables Translation process

7 }

 7 Listing 7. C code corresponding to #to:do:

Figure 8 .

 8 Figure 8. Addition of the While concept to the C AST metamodel. A C while is a Statement, that contains an Expression, the condition, and a Statement representing its body.

Listing 8 .

 8 A simplified implementation of the #to:do: for ILSmallInteger.

1

  PrettyPrinterVisitor >> visitWhile: aWhile 2 stream << 'while('.

3

  aWhile condition acceptVisitor: self.

5

  aWhile body acceptVisitor: self.

  Statement, Expression, Block and ExpressionStatement. The metamodel states that a Statement is either a Block or an ExpressionStatement. The Block is composed of zero or many other Statements such as Blocks or ExpressionStatements. An ExpressionStatement represents the top node of an Expression.

Acknowledgments

This work was supported by Ministry of Higher Education and Research, Nord-Pas-de-Calais Regional Council, CPER Nord-Pas-de-Calais/FEDER DATA Advanced data science and technologies 2015-2020. The work is supported by I-Site ERC-Generator Multi project 2018-2022. We gratefully acknowledge the financial support of the Métropole Europénne de Lille.


Saeid Samadi

Stéphane Caron

Arnaud Tanguy

Abderrahmane Kheddar

Balance of Humanoid robot in Multi-contact and Sliding Scenarios

Keywords: Humanoid and multi-legged robots, balance, multi-contacts, sliding contacts

This study deals with the balance of humanoid or multi-legged robots in a multi-contact setting where a chosen subset of contacts is undergoing desired sliding-task motions. One method to keep balance is to hold the centerof-mass (CoM) within an admissible convex area. This area should be calculated based on the contact positions and forces. We introduce a methodology to compute this CoM support area (CSA) for multiple fixed and sliding contacts. To select the most appropriate CoM position inside CSA, we account for (i) constraints of multiple fixed and sliding contacts, (ii) desired wrench distribution for contacts, and (iii) desired position of CoM (eventually dictated by other tasks). These are formulated as a quadratic programming optimization problem. We illustrate our approach with pushing against a wall and wiping and conducted experiments using the HRP-4 humanoid robot.

I. INTRODUCTION

Humanoid robots are designed to interact with the environment and are supposed to be able to reproduce all sorts of physical actions that a human could do such as running, flipping, jumping, crawling, etc. In theory, state-of-the-art humanoid robots have the hardware capability to achieveto some extended and relative performances, some of these complex behaviors. Yet, they lack efficient control strategies with robust equilibrium conditions.

Sustaining equilibrium is more challenging in multicontact settings. Balance in multi-contact conditions was studied theoretically in [START_REF] Collette | Dynamic balance control of humanoids for multiple grasps and non coplanar frictional contacts[END_REF] but restricted to non-sliding contacts. A recent study on the interaction of the robot with the environment introduces a passivity-based whole body balancing framework [START_REF] Abi-Farraj | Torque-Based Balancing for a Humanoid Robot Performing High-Force Interaction Tasks[END_REF]. In this latter work, gravito-Inertial wrench cone (GIWC) -introduced in [START_REF] Caron | Stability of surface contacts for humanoid robots: Closed-form formulae of the Contact Wrench Cone for rectangular support areas[END_REF], is used to keep the balance in multi-contact, eventually under moving but not sliding contacts.

Sliding motion is one of the actions that humans master in achieving several tasks in their daily lives. Sliding contacts have been studied on several robots by considering dynamic friction forces and planning and controlling objects by pushing, see a recent example in [START_REF] Shi | Dynamic in-hand sliding manipulation[END_REF].

Recent works on humanoid robots are mostly focused on avoiding [START_REF] Kajita | Biped walking on a low friction floor[END_REF], [START_REF] Zhou | Simultaneous prevention of rotational and translational slip for a humanoid robot[END_REF] or recovering [START_REF] Kaneko | Slip observer for walking on a low friction floor[END_REF], [START_REF] Vázquez | Experimental estimation of slipping in the supporting point of a biped robot[END_REF] slips. Keeping the balance while sliding on purpose has been studied for two feet contacts in both rotational and translational directions. Linear contact constraints have been used in [START_REF] Kojima | Rotational Sliding Motion Generation for Humanoid Robot by Force Distribution in Each Contact Face[END_REF] for the The authors are with the Montpellier Laboratory of Informatics, Robotics and Microelectronics (LIRMM), CNRS-University of Montpellier, France. A. Kheddar is also with the CNRS-AIST Joint Robotics Laboratory (JRL), UMI3218/RL, Tsukuba, Japan. Corresponding author: saeid.samadi@lirmm.fr controller to keep the dynamic balance while slipping in rotational directions on the feet. While rotational-slipping, considering the force distribution within the contact surfaces is the most challenging part of the study. Slip-turn motion for the robot is produced in [START_REF] Miura | Slipturn for biped robots[END_REF] by minimizing the floor friction power. The works in [START_REF] Hashimoto | Realization of quick turn of biped humanoid robot by using slipping motion with both feet[END_REF], [START_REF] Koeda | Shuffle turn and translation of humanoid robots[END_REF] are about generating quick turning motion by rotational shuffling.

As a motion planning for translational shuffling, [START_REF] Kojima | Shuffle motion for humanoid robot by sole load distribution and foot force control[END_REF] implemented two-layer controller to satisfy of the stability criteria of the robot using Zero-tilting Moment Point (ZMP) and achieve proper force distribution in two feet contacts. Total motion sequence of this method consists of both slideand-stop phases and CoM trajectory is generated solving a QP and related constraints. Also, keeping the dynamic balance while shuffling is studied in [START_REF] Posa | Corrigendum: A direct method for trajectory optimization of rigid bodies through contact[END_REF] by formulating complementarity constraints into a QP, and in [START_REF] Kim | Quick change of walking direction of biped robot with foot slip in single-support phase[END_REF] by uniform force distribution assumption on the sole for single support phase.

Multiple sliding contacts for humanoid robots are still a challenge to solve. Our contribution to this field of interest is in introducing an applicable method to keep the balance of the robot in multi-contact settings. Our method not only guarantees equilibrium criteria for fixed contacts, as shown in Figure [START_REF] Collette | Dynamic balance control of humanoids for multiple grasps and non coplanar frictional contacts[END_REF], but also keeps the balance of the robot in the presence of sliding contacts.

In the following, we structured our work in four sections.

In Section II, we introduce a CoM support area for multiple fixed and sliding contacts. Holding the position of the CoM inside this area guarantees the balance of the robot while some chosen contacts slide and other not. Next, in Section III, we illustrate our methodology for calculating the position of CoM under constraints. Sections IV and V shows the experimental results of proposed method and gives a conclusion of the whole work, respectively.

II. COM SUPPORT AREA

The dynamic model of any robot which can be described by Newton-Euler equations is in the following form:

W c = -W m (1)
where W c ∈ R 6 and W m ∈ R 6 are the contact and the gravity wrenches respectively. We follow the common practice to write the resultant linear term (force) first in the wrench followed by the moment term. So, W = [f τ ] T . By separating forces and torques of (1), we have:

i f i = -mg (2)
i p i × f i = -p G × mg ( 3
)
where m is the total mass of the robot, p i , f i ∈ R 3 are the position and force of the i th contact point respectively; g ∈ R 3 is the gravity vector and is equal to 0 0 -9.81 T and p G ∈ R 3 is the position of the CoM. By introducing the unit vector e z as 0 0 1 T , we can rewrite these equations by separating the vertical component of the gravity vector:

i f i = mge z (4) i p i × f i = mgp G × e z (5)
where gravity acceleration is g = -9.81 m/s 2 . Moreover, by applying a cross-product to both sides of ( 5) by e z , we get the following equation:

mge z × p G × e z = i e z × (p i × f i ) (6)
Next, we use two well-known properties of the crossproduct that are:

e z × p G × e z =   p x G p y G 0   (7) a × (b × c) = (a.c)b -(a.b)c (8)
by applying equations 7 and 8 into (6) we have:

mgp S G = i f z i p i -p z i f i (9)
where p S G denotes the position of the CoM in the horizontal plane and is equal to

[p x G p y G 0] T .
Let's consider we have a robot in a 3-contacts setting. The position of the CoM will be formulated as follows:

p S G = f z 3 mg p 3 + f z 2 mg p 2 + f z 1 mg p 1 -[ p z 3 mg f 3 + p z 2 mg f 2 + p z 1 mg f 1 ] (10)
The equation 10 shows the general form of this formula regardless of orientation and positions of contacts. As a particular case, we assume that both feet are on the ground so that p z 1 = p z 2 = 0. Consequently (10) becomes:

p S G = f z 1 mg p 1 + f z 2 mg p 2 + f z 3 mg p 3 - p z 3 mg f 3 (11)
In the following, we specify a region for the feasible position of CoM without losing the balance according to our sliding and multi-contact conditions. This region was introduced in [START_REF] Bretl | Testing static equilibrium for legged robots[END_REF] as a static equilibrium CoM area, and its extension to 3D in [START_REF] Audren | 3-D robust stability polyhedron in multicontact[END_REF]. The purpose of our present work is to be able to balance the robot in multi-contact configurations with fixed or sliding contacts. Furthermore, this method will guarantee the stability of the robot for sliding contacts such as wiping a board by hand or shuffling foot motions.

Let's consider a humanoid having its feet on the ground and one of its arm (e.g. right one) wiping a board (noncoplanar with the other contacts). The wiping trajectory could be anything and there is no limitation for the direction of wiping. Hence, the position of the sliding contact is a pre-defined parameter according to the designed wiping trajectory. Therefore, the last two elements of [START_REF] Hashimoto | Realization of quick turn of biped humanoid robot by using slipping motion with both feet[END_REF] is not related to the main variables (p 1 and p 2 ) for introducing the CoM support Area (CSA), and we can define them as an independent variable A:

p S G = f z 1 mg p 1 + f z 2 mg p 2 + A (12a) A = f z 3 mg p 3 - p z 3 mg f 3 (12b) then: p S G -A = f z 1 mg p 1 + f z 2 mg p 2 (13)
On the other hand, by considering (2) in vertical direction, we have:

f z 1 mg + f z 2 mg + f z 3 mg = 1 (14)
From ( 14), we introduce "S c " as the sum of the coefficients of (12a):

S c def = 1 - f z 3 mg (15)
and ( 13) becomes:

p S G -A = α i (S c p i ) (16a)
α i = f i S c mg (16b)
where, Equation ( 17) is a sufficient condition to show that the point p S G -A should be inside the convex polygon constructed by connecting p i points. There are two equivalent ways to represent the wrench applied by the environment on the robot under a surface contact:

α i = 1 (17)
1) Contact forces applied at the vertices of the contact area [START_REF] Caron | Stability of surface contacts for humanoid robots: Closed-form formulae of the Contact Wrench Cone for rectangular support areas[END_REF]; 2) A single contact wrench applied at a given point [START_REF] Audren | 3-D robust stability polyhedron in multicontact[END_REF]. We choose the latter method. To be able to use the surface contact instead of single points, we replace each of these points (p i ) with four edges of the related foot. Coordinates of new points are available by considering the dimension of each foot. CSA is depicted in Fig. 2. The green area on the ground of Fig. 2 As a result, the CSA is constructed according to both sliding and multi-contact conditions. To keep the balance of the robot, the CoM should remain inside the CSA during operating motions. Setting the exact position for the CoM inside the CSA is the next contribution of our work. This is done by formulating this problem as a QP where desired behaviors are specified via a set of tasks and constraints.

III. CENTROIDAL QUADRATIC PROGRAM

A common solution for keeping the balance of the robot is to put a constraint on the position of the CoM and hold it inside the CSA. This constraint will ignore some parameters that affect the performance of the robot such as keeping the maximum distance of CoM from edges of the CSA or considering an appropriate wrench distribution on the contacts.

A. Decision Variables

Collete et. al [START_REF] Collette | Dynamic balance control of humanoids for multiple grasps and non coplanar frictional contacts[END_REF] introduced a quadratic program that takes into account to the position of CoM, linearized contact forces and the gravity wrench in static equilibrium. Here we extend this QP to enable sliding contacts and apply sliding constraints to the related contact. Our QP is designed with the following decision variables:

Y = p S G W rf W lf W rh T 1×21 (18)
1 http://choreonoid.org/en/ 2 https://github.com/stephane-caron/pymanoid/ where W denotes the wrench in the world frame and subscripts "rf", "lf" and "rh" correspond to the right-foot, left-foot and right-hand contacts, respectively. The solver deals with position of the CoM. This centroidal QP computes decision variables at each time step and sends them to the robot as a command. The static equilibrium of the system is given in [START_REF] Collette | Dynamic balance control of humanoids for multiple grasps and non coplanar frictional contacts[END_REF]. Accordingly, by considering three contacts (one hand contact and two feet contacts), Newton-Euler equation writes:

W m + W rf + W lf + W rh = 0 ( 19
)
where wrenches can be formulated as follows:

W m =         0 0 0 0 0 0 0 0 0 0 -mg 0 mg 0 0 0 0 0         p S G +         0 0 -mg 0 0 0         (20)
W rf,lf =         I 3×3 0 3×3 0 -p z p y p z 0 -p x I 3×3 -p y 0 p x         w rf,lf (21)
where w shows the wrench in contact frame and is equal to

[f ∈ R 3 τ ∈ R 4 ] T .
W rh is calculated in a same way with W rf,lf . In this way, we can shortly write these equations as: Usual works in locomotion, multi-contact conditions or motion generation for humanoids avoid slippage whereas we aim for it when needed. To avoid slipping, it is common to use inequality constraints to hold each contact force within its associated friction cone. Instead, we are implementing constraints to generate the sliding motion.

W m = E m1 .p S G + E m2 (22a)
W rf = E rf W rf (22b) W lf = E lf W lf ( 22c
)
W rh = E rh W rh ( 22d
For generating controlled slipping motion, force vector of the sliding contact (f c ) should remain at the edge of the related contact's friction cone, and hence expressed as equality constraints. Hand torques are considered as inequality constraints.

We introduce two matrices named [S 1 ] and [S 2 ] such that the normal hand contact force and the related friction forces could be given to the QP as a constrain:

[S 1 ] 6×6 = I 3×3 0 3×3 0 3×3 0 3×3 (23)
so that:

[S 1 ]W rh = f 3×1 0 3×1 rh ( 24
)
For the sliding contact calculations, f x rh shows the normal force applied to the right hand in the world frame. According to the wiping trajectory, the contact forces in y and z directions could be calculated:

f 3×1 0 3×1 rh =          0 0 . . . 0 fy fx 0 . . . 0 fz fx . . . . . . . . . 0 0 . . . 0          6×6 w rh +         f x 0 0 0 0 0         (25)
where fy fx and fz fx are constant numbers and they are independent from the forces. From ( 24) and (25), we have:

[S 1 ]w rh = [S 2 ]w rh + k (26) thereby: [S 1 -S 2 ]w rh = k (27)

C. Non-sliding Conditions

The sliding contacts are expressed with equality constraints. However, to keep the rest of the contacts fixed on the ground, we have to implement inequality constraints to maintain the related contact force inside the friction cone. The general constraints that should be applied to contact wrenches in the QP solver are same as [START_REF] Caron | Computational Foundation for Planner-in-the-Loop Multi-Contact Whole-Body Control of Humanoid Robots[END_REF]:

| f x | µf z , | f y | µf z , f min z f z f min z | τ x | Yf z , | τ y | Xf z , τ min z τ z τ min z (28)
where X and Y are dimentions of contact surfaces, so:

τ min z = -µ(X + Y)f z + | Yf x -µτ x | + | Xf y -µτ y | (29) and τ max z = µ(X + Y)f z -| Yf x + µτ x | -| Xf y + µτ y | (30)
The equations (28) are combined in the following form for feet contacts:

±       f x f y f z τ x τ y       rf,lf       µf z µf z f max z Yf z Xf z       rf,lf (31)
Furthermore, for sliding contacts, we consider torques similarly to (31) in all directions inside the inequality constraints. Because, sliding contact forces have been considered in equality constraints to create the sliding motion. Note that, there is no τ z element inside the vectors and it will be considered separately. We need to generate vectors in a way that we can apply it as an inequality constraint to the system. For this reason, we re-write these equations using G ∈ R 6×21 and h ∈ R 6 matrices and vectors:

G 1 rf,lf,rh Y h 1 rf,lf,rh (32)
G 2 rf,lf,rh Y h 2 rf,lf,rh (33)
where:

G 1 rf = 0 6×3 Υ 1 rf 0 6×12 (34a) G 2 rf = 0 6×3 Υ 2 rf 0 6×12 (34b) G 1 lf = 0 6×9 Υ 1 lf 0 6×6 (34c) G 2 lf = 0 6×9 Υ 2 lf 0 6×6 (34d) G 1 rh = 0 6×15 Υ 1 rh (34e) G 2 rh = 0 6×15 Υ 2 rh (34f)
where Υ 1 rf,lf ∈ R 6×6 is defined as:

Υ 1 rf,lf =            1 0 -µ 0 . . . 0 1 -µ . . . . . . 0 1 -Y rf,lf 1 -X rf,lf 1 . . . 0 0 . . . 0           
Note that Υ 2 rf,lf is same as Υ 1 rh,lf except the diagonal values of the matrix which should be multiplied by -1. Also, for the sliding contact, we have:

Υ 1 rh =           0 0 . . . 0 0 . . . . . . . . . 0 0 0 . . . X rh 0 . . . 0 1 0 Y rh 0 . . . 0 1          
and for Υ 2 rh , just replace two last elemets on the diagonal of the matrix with -1. For the other side of the inequality, h is zero vector for sliding contacts. For fixed contacts, we have:

h 1 rf,lf = 0 0 f max z 0 0 0 T (35a) h 2 rf,lf = 0 0 f min z 0 0 0 T (35b) h 1,2 rh = 0 6×1 (35c)
Besides, we should consider inequality constraints on τ z . According to (28), we divide it to two types of boundaries which should be implemented for all contacts:

τ z -τ max z 0 (36)
-τ z + τ min z 0 (37)
consider that there is two absolute values inside each of τ max z and τ min z based on (29) and (30) that each equation results in four more rows inside the inequality matrix that should be multiplied by Y. We introduce Gz ∈ R 4×21 matrices which covers the inequality constraints on τ z element of wrenches:

Gz 1,2 rf,lf,rh Y 0 4×1 (38)
where:

Gz 1 rf = 0 4×3 Ψ 1 rf 0 4×12 (39a) Gz 2 rf = 0 4×3 Ψ 2 rf 0 4×12 (39b) Gz 1 lf = 0 4×9 Ψ 1 lf 0 4×6 (39c) Gz 2 lf = 0 4×9 Ψ 2 lf 0 4×6 (39d) Gz 1 rh = 0 4×15 Ψ 1 rh (39e) Gz 2 rh = 0 4×15 Ψ 2 rh ( 39f
)
where the Ψ ∈ R 4×6 matrices are different for each contact and should be defined separately. They are calculated as follows. Consider (36) for the right foot. By implementing the amount of τ max z from (30) and considering positive sign for the both of the absolute values, we get to the following equation:

Y rh f x + X rh f y + C rf f z + µτ x + µτ y + τ z 0
where C rf = -µ(X + Y) and is computed in the same way for other contacts.By considering negative sign for absolute values, the other three equations are available and Ψ matrix for for upper bound of the right foot is calculated:

Ψ 1 rf =     Y rf X rf C rf µ µ 1 -Y rf X rf C rf -µ µ 1 Y rf -X rf C rf µ µ 1 -Y rf -X rf C rf -µ µ 1    
Notice that the first row of this matrix corresponds to the above equation. Other matrices for the lower and upper bound of the contacts will be calculated in the same way.

D. QP Formulation

The goal of centroidal QP is to achieve Y des as desired amount of these decision variables as much as possible. Therefore, the minimization problem is:

Y -Y des 2 (40)
where the desired position for CoM is the 'middle' of the CSA and for feet contacts, desired quantity is equal to the wrench distribution for both.

According to (40) and sliding and non-sliding conditions, the QP formulation is in the following form:

min Y 1 2 Y T PY + q T Y (41a) GY h (41b) AY = b (41c)
where P = 2I 21×21 and q = -2Y des . By introducing G T rf as transpose matrix of G rf and the same for the other contacts, matrices and vectors of the equality constraints in (41) are:

G = G 1,T rf G 2,T rf G 1,T lf G 2,T lf G 1,T rh G 2,T rh T 21×60 (42a) h = h 1,T rf h 2,T rf h 1,T lf h 2,T lf h 1,T rh h 2,T rh T 21×1 (42b)
On the other hand, for equality constraints, (22) from section III-A and (27) from section III-B, should be used. To combine these constraints in one equation and be able to use them in QP directly, matrix A ∈ R 12×21 and vector b ∈ R 12 are defined as follows:

A = E m1 E rf E lf E rh 0 6×3 0 6×6 0 6×6 S 1 -S 2 (43a) b = -E T m2 ∈ R 6×1 -f x 0 . . . 0 T (43b)

E. Controller Specification

Position of the CoM and wrenches of contacts is calculated by centroidal QP. These values should be applied on the real robot as commands. For this purpose, we use a wholebody dynamic controller based on another QP formulation introduced in [20] using three following tasks.

1) Posture task: is a regularization task based on degrees of freedom q that brings the robot to a reference jointangle half-sitting configuration q half-sit and its derivatives by considering task stiffness K via:

q = K(q half-sit -q) -2 √ K q (44)
2) End-effector admittance task: takes a desired position p d ∈ R 6 as target in world frame, desired wrench w d ∈ R 6 in sensor frame and admittance gains A ∈ R 6 . For a given degree of freedom i, the task is a position task if A i = 0 and a force task if A i = 0 and in this case, force feedback is applied by ṗi = A i (w d i -w i ). In experiments, we apply this task to the right hand of the robot which is in contact with the wall.

3) CoM task: takes as target a desired position c d ∈ R 3 , velocity ċd ∈ R 3 and acceleration cd ∈ R 3 in world frame. This is a standard second-order task. Internally, it will realize:

c = K(c d -c) + B( ċd -ċ) + cd ( 45
)
where B is the task damping (usually 2 √ K) and ċ = J com q is the CoM velocity where J shows Jacobian matrix.

Finally, we regulate the weight distribution between the two feet on the ground while the end effector of the robot acts on the contact surface. For this purpose, we use: 4) Foot force difference control [START_REF] Kajita | Biped walking stabilization based on linear inverted pendulum tracking[END_REF]: applies to two endeffectors whose targets are in the same plane, in our case the left foot and right foot. The force difference (f z,lf -f z,rf ) is regulated to the value (f d z,lf -f d z,rf ) provided by the centroidal QP by applying damping control to a virtual offset z:

ż = A z ((f z,lf -f z,rf ) -(f d z,lf -f d z,rf )) (46)
The velocity -ż is then applied to the left foot, while + ż is applied to the right foot.

IV. EXPERIMENTS AND RESULTS

We implemented our new methodology for keeping the balance and did several experiments with HRP-4 humanoid robot. In this section, we discuss three of these experiments and show the performance of our controller in pushing and wiping scenarios. The baseline for our study is considering a fixed position for the robot's CoM. The Figure [START_REF] Shi | Dynamic in-hand sliding manipulation[END_REF] shows the robot scrabbling to increase the normal force on the hand contact and achieve the target force of 60 N but fails.

Force tracking of admittance control shows that the failure occurs in less than 20 N normal force and the robot is not able to achieve the target force with this posture anymore. On the other hand, we did the same experiment with our proposed controller. The Figure [START_REF] Kajita | Biped walking on a low friction floor[END_REF] shows successful tracking of the normal force with the generated posture of the robot due to the position of CoM and kinematics of the robot.

Also, the trajectory of CoM while increasing and decreasing the right-hand force is shown in Figure [START_REF] Zhou | Simultaneous prevention of rotational and translational slip for a humanoid robot[END_REF]. Position of the CoM moves forward by increasing the target normal force and lays back by decreasing the force. The last experiment deals with sliding contact and shows the performance of the controller while wiping a vertical surface with a normal force of 30 N on sliding contact. Figure [START_REF] Kaneko | Slip observer for walking on a low friction floor[END_REF] shows the normal force tracking of sliding contact. In this experiment, the normal Normal force tracking while wiping the wall using proposed strategy.

force is set to 30 N by admittance task of the controller and starts wiping from 16 th second. This is the reason of error occurred at this moment but then the normal force converges to the target value. Experiments are available in accompanying video 3 .

V. CONCLUSION

Stability criteria for humanoid robots based on the position the CoM have been studied in the current work. A methodology for constructing CSA in multi-contact conditions is introduced. This method, covers multiple fixed and sliding contacts. For setting CoM inside this the CSA, we use centroidal QP by considering constraints. The robot achieves to the desired configuration by implementing inverse kinematics of the system according to the position of the CoM.

Simulations and experiments show that proposed balance control is valid for both fixed and sliding contacts in practice. Also, by using this method, the robot is able to achieve a proper body configuration in order to reach target forces in contacts. Online estimation of the contact friction should be addressed as part of future work. The transition between fixed and sliding contact modes, which is still a challenge to solve, causes errors in target force tracking.

Fig. 1 .

 1 Fig. 1. Keeping balance of HRP-4 humanoid robot in pushing-against-awall scenario by adjusting position of the CoM.

Fig. 2 .

 2 Fig. 2. Humanoid robot with sliding hand contact on the wall simulated dynamically by Choroenoid 1 (a) and prototyped in pymanoid 2 (b).

  (a) is CSA for close foot contacts and Fig. 2(b) emphasizes this area for far feet contacts in wiping motion.

  ) B. Sliding Condition Consider a box in direct contact with the ground as shown in Fig. (3). An external force F ext is applied to this box. The box will not move as long as the contact force f c lies within the Coulomb friction cone C [18].

Fig. 3 .

 3 Fig. 3. Friction cone of a fixed box in presence of external force

Fig. 4 .

 4 Fig. 4. Normal force tracking while Pushing the wall using fixed CoM.

Fig. 5 .

 5 Fig. 5. Normal force tracking while Pushing the wall using proposed strategy

Fig. 6 .

 6 Fig. 6. Position of CoM while pushing the wall.

Fig. 7 .

 7 Fig. 7.Normal force tracking while wiping the wall using proposed strategy.

https://www.youtube.com/watch?v=Wai-Lp4e5FE


A Hofrichter

) Lpicm

A Constantinescu

S Benayoun

P Bulkin

B Dre

Study of the mechanical behavior of plasma-deposited silica films on polycarbonate and steel

In the present study, we deposited amorphous hydrogenated silicon oxide films on polycarbonate, stainless steel, and silicon by plasma enhanced chemical vapor deposition using a low pressure, high density integrated distributed electron cyclotron resonance plasma reactor. Substrate curvature, vibrating slab, and Vickers indentation experiments were used to evaluate the intrinsic stress, the Young modulus of the films, and the composite hardness of the film-substrate system. The indentation experiments were modeled by finite element analysis and the calculated values were compared to experimentally measured hardness values. A reasonable accordance with the experiment was found both for stainless-steel and polycarbonate substrates, indicating that the modeling is valid and may be used to enhance the interpretation of the indentation experiments. The calculations show an important bending of the film in the noncontact region in the case of a Vickers indentation on a coated polycarbonate sample. The analysis of the thus-induced strain distribution in the coating indicates that the measured diagonal might be overestimated and not representative of the real contact area. The calculations indicate that the yield limit of the plasma-deposited silica films is of about 4 GPa.

I. INTRODUCTION

Polymers are increasingly used to replace more traditional engineering materials such as glass, metals, and ceramics. There is considerable interest in using silicon-based thin films to enhance functional characteristics such as scratch and abrasion resistance or barrier properties. The mechanical properties of film and substrate and the mechanical behavior of the film-substrate composite are of prime importance for such applications. Previous studies focused on the mechanical properties of plasma enhanced chemical vapor deposition ͑PECVD͒ deposited films on a nanosized scale, 1 nevertheless, the macroscopic mechanical properties of the filmsubstrate system were, up to now, mainly studied from a phenomenologic point of view. 2,3 In this work, we studied silica coated polycarbonate with macroindentation tests and finite-element modeling ͑FEM͒ of the mechanical behavior in order to get quantitative information about the hardness of the thin film/substrate composite. As the interpretation of macroindentation tests of hard coatings on soft substrates is particularly delicate, we studied also the mechanical behavior of silica thin films on stainless steel to see if our model can cope with two completely different substrate materials.

II. EXPERIMENT

A. FEM analysis

In this study the indentation of the sample by a Vickers pyramidal indenter has been modeled using the FEM code CASTEM 2000 ͑Refs. 4-6͒ through a two-dimensional ͑2D͒ axisymetric indentation of a cylinder by a highly rigid cone. In their analysis of 2D and three-dimensional ͑3D͒ models, several authors [START_REF] Bhattacharya | [END_REF]8 found that a tip angle of approximately 70°f or the 2D cone leads to a displaced volume of matter similar to that of Vickers or Berkovich pyramidal indenters and provides similar indentation curves.

The contact between the indenter and the mesh has been considered frictionless. In the case of conical indenters this is justified by numerical results obtained by others. [8][9][10] One can remark that the friction plays an important role in the case of spherical indenters. 11 In order to simulate the indentation experiments, characterized by a ratio of film thickness to indentation depth of approximately 1:0.1 and 1:3 for nano-and macroindentation, respectively, two different types of meshes with 54 and 9 ͑see Figs. 1 and 7͒ elements, respectively, in the layer have been used. They have been designed in order to permit a high mesh refinement in the contact area and to span a large domain, typically, 15-50 times larger than the indentation depth. All meshes had between 2000 and 4000 linear quadrangular elements and between 2000 and 5000 nodes. a͒ Electronic mail: hofricht@poly.polytechnique.fr As a consequence of the large displacements induced by the indenter, the computations have been done under the hypothesis of finite displacements and small strains using a mesh actualization at each load step. This hypothesis is not valid at the tip of the indentor where plastic deformation can attain 200% on some elements and where the small strain behavior is largely surpassed. This phenomenon is, however, always confined in a very small region at the tip of the indenter.

The material behavior has been considered as elastoplastic with an isotropic hardening [START_REF] Simo | Computational Inelasticity ͑Springer[END_REF] and the material parameters are presented in Table I. It is important to remark that a change to a kinematic hardening or a small variation of the coefficients did not influence the global behavior of the film-substrate structure.

The mechanical behavior of silica has been assumed identical in traction and compression. However, it is well known that silica can be better characterized by plastic behavior in compression and a brittle one in traction and that the limit yield stresses can be very different. This was unfortunately not possible during these computations. Nevertheless, two different values for the plasticity coefficients have been chosen in order to activate the dissipation phenomena at different stress levels. The validity of the constitutive assumption of SiO 2 films will stem from the results presented in the next section.

The hardness H v has been computed according to H v ϭF/A, where F represents the resultant force and A the projected contact area obtained from the contact radius in the deformed configuration. The resultant force has been computed using the computed nodal forces or the Lagrange multipliers obtained directly in the contact conditions. The difference between the two methods provided a relative error smaller than 10 Ϫ4 -10 Ϫ6 .

The computations have been performed on a 400 MHz Intel PC and 100 load increments with about five internal iterations at each step, corresponding to contact and plasticity, took typically 40 min of CPU time. The use of elastic super elements on the exterior boundary of the domain reduced the number of active nodes by 400-600 and, consequently, the computed time by 30%.

B. Film deposition and measurements

The thin-film depositions were carried out in an integrated distributed electron cyclotron resonance ͑IDECR͒ microwave excited high density plasma reactor scalable for large area deposition. The system is described in detail in Ref. 13 and allows the deposition of dense stoichiometric silica with growth rates as high as 46 Å/s at room temperature. 14 The films were deposited from a mixture of SiH 4 and O 2 on 1 in.ϫ1 in. extruded GE Lexan polycarbonate and 316 L stainless-steel substrates. The microwave power was 100 W and the pressure was set at 1.14 mTorr. During deposition the substrates were kept at floating potential, the substrate holder was not heated intentionally, and the substrate temperature stayed below 50 °C. The film thickness and refractive index were measured in situ at an angle of 57.8°on a spectroscopic phase modulated ellipsometer ͑UVISEL ISA Jobin-Yvon Sophie͒. The Vickers indentation tests were performed with standard Vickers indenters at loads between 10 and 1000 g on bare and coated substrates. For each indent the diagonal was measured by optical microscopy. Particular care was taken to determine the diagonal of the indent, which proved to be difficult in some cases, especially for coated polycarbonate ͑PC͒ substrates ͑Fig. 2͒. The size of the indent was averaged over the two diagonals of the indenter and each indent was repeated ten times. Penetration depth and Vickers hardness were calculated using standard formulas.

The stress measurements were performed by measuring the bending of small rectangular c-Si slabs ͑0.7ϫ2.5 mm͒ of 100 and 111 orientation with a Sloan Dektak III profilometer before and after deposition. The Young moduli of the film and the bare polycarbonate substrate were determined by the vibrating slab technique.

III. RESULTS AND DISCUSSION

A. Film and material characterization

The thickness of the films was 5.50Ϯ0.05 m as determined by ellipsometry. The films had a refractive index of nϭ1.456, identical to that of thermal silica and had a hydrogen content of less than 4%. 14 The films had compressive stress of about ͑70Ϯ15͒ MPa, which was found to be independent of processing power.

The Young modulus of the bare polycarbonate sample was determined as 2.54 GPa, whereas the Young modulus of the SiO 2 layers was determined to be 50Ϯ2 GPa ͑Table I͒ [START_REF] Valin | Projet en Laboratoire[END_REF]16 which is well in accordance with the literature values. The traction curve of the bare polycarbonate sample was recorded and the measured strain-stress curve used for determining the isotropic hardening of the substrate.

B. Macroindentation

The numerical and experimental values of the Vickers hardness obtained for the macroindentation on coated and uncoated stainless steel are displayed in Fig. 3. For highindentation depths the hardness of the film/substrate system tends, as expected, towards the hardness of the bare substrate. The numerical values ͑1500Ϯ50 MPa͒ are in reasonable agreement with the experiment for the bare substrate ͑1600Ϯ100 MPa͒. In the case of the film/substrate system only the numerical simulation corresponding to a yield stress y of 4000 MPa for the silica coating are in agreement with the measurements. One can observe that for small indenta-tion depths the system shows a high hardness, corresponding essentially to the hardness of the pure film of about 10 GPa. This value is higher but of the same order of magnitude as hardnesses reported for similar silica coatings in the literature. 1,10 In order to effectively examine the measurements on polycarbonate, we must first compare the indentation depth on polycarbonate and steel substrates for an identical contact radius ͑Fig. 4͒. The total indentation depth ␦ T can be split in two parts: the contact indentation depth ␦ C and the structural indentation depth ␦ S (␦ T ϭ␦ S ϩ␦ C ). The structural indentation depth characterizes the elastic flexure bending of the film and is related to the ratio of the Young moduli between substrate and film. One can remark that the structural indentation depth is much lower in the case of the stainless-steel substrate. In the case of the polycarbonate the structural indentation depth represents a large part of the computed indentation depth ␦ T . Therefore, the computed values for the film on the polycarbonate substrate must be plotted as a function of contact indentation depth ␦ C .

The Vickers hardness values for the coated and uncoated polycarbonate are plotted in Fig. 5. The experimental values of hardness of the coated system tend to a limit of 220Ϯ20 MPa, whereas the hardness value of the bare polycarbonate is 140Ϯ10 MPa.

The computed values of hardness for the coated system are generally larger than the experimental ones. This can be explained by the cracking of the film, which would induce a larger observed indentation diagonal. In order to understand where the film might crack, let us first observe that the bending of the film induces traction in the upper part of the film outside the contact zone. This traction is represented by the radial stress component rr . It is important to understand why this phenomenon is not as strong in the case of a stainless-steel substrate.

If we plot rr for identical structural indentation depth, or equivalently, the same contact radius along the radius of the sample ͑Fig. 6͒, we observe that the maximum lies near the contact radius in the case of stainless steel, whereas it is located far outside the contact region in the case of polycarbonate. This suggests that cracking occurs for the polycarbonate substrate far outside the contact region and that the experimentally observed indentation diagonal will lie somewhere between the computed contact radius and the radius r s of maximal rr . Representing now the computed hardness Hr s using the radius r s we remark that the experimental values are well bounded by the two computed hardnesses ͑Fig. 5͒.

For high-indentation depth the computed H v tends towards 230Ϯ15 MPa, well in accordance with the experimen-tal results. In this case, the correction between r C and r S is of about 5 m for a radius of about 35 m which lies within the experimental error.

For low indentation depths, the computed hardness values tend to the expected value of 10 GPa, as in the case of the stainless-steel substrate. For these indentation depths, the structural bending is low and the rr stress stays under the threshold value responsible for the failure of the coating. Therefore, it does not make sense to talk about r S and the corresponding hardness.

It is obvious that for intermediate indentation depth a more sophisticated model, taking into account the precise fracture behavior of the SiO 2 layer and related to precise diagonal measurements, would be necessary in order to simulate the measured values.

C. Nanoindentation

Figure 7 compares the plastically deformed area in the film and substrate for Vickers and nanoindentation. In the case of nanoindentation, we observe that the plastic deformation in the film is confined in a small region under the tip of the indenter. In the substrate, the size of the plastically deformed region depends highly on the nature of the substrate. In the coating, the mechanical field distribution is practically independent of the nature of the substrate.

Unfortunately, no experimental values were available at the moment to validate the nanoindentation calculations. The computed hardness values were up to indentation depths smaller than 20% of the film thickness, independent of the nature of the substrate. This is in accordance with the experiments reported in the literature. 3 For a film yield limit Y ϭ4 GPa, the hardness was about 8 GPa. These values fit well with the values obtained in the macroindentations on stainless steel for small indentation depths. In the case of the polycarbonate substrate, the smallest indentation depth in our macroindentation experiments is with 2 m about half of the film thickness, and therefore, not low enough to be representative of the film hardness alone.

IV. CONCLUSION

We studied the macroindentation of silica thin films on stainless-steel and polycarbonate substrates. The indentation experiments were simulated by finite-element analysis and a reasonable accordance was found between the experiments and the simulations. The results indicate that the yield limit of the plasma-deposited silica films is of about 4 GPa. Further nanoindentation measurements would be necessary to obtain a more precise description of the mechanical properties of the film. The numerical analysis showed that due to film cracking the observed diagonals might be overestimated and not representative of the real contact area.

These simulations show that the finite-element analysis can be effectively used to better understand the mechanical aspects of indentation tests at both the nano-and macrolevel and that experimental hardness values can be computed with reasonable precision. More precisely, it has also been shown that cracking of the film could be predicted by FEM analysis and, therefore, enhance the interpretation of measurements.

These findings may form a basis for using FEM analysis to determine design specifications for protective coatings on polymers and similar single and multilayer structures, although further verification of the model will be necessary.

FIG. 1 .

 1 FIG.1. Deformed finite-element mesh for macroindentation with a zoom of the contact zone.

FIG. 2 .

 2 FIG. 2. Images of the Vickers indent on PC ͑left͒ and stainless steel ͑right͒. FIG. 3. Computed and measured hardness for coated and uncoated stainless steel vs indentation depth.

FIG. 5 .

 5 FIG. 5. Computed and measured hardness for coated and uncoated polycarbonate vs indentation depth.

FIG. 7 .

 7 FIG.7. Indenter, plastic deformed zone ͑dark gray͒, and elastoplastic finite elements ͑light gray͒ in the case of macro-͑a͒ and nano-͑b͒ indentations.

TABLE I .

 I Values of the mechanical constants used for the FEM calculations.

		Young modulus	Yield limit	Strain hardening	Poisson coefficient
	Material	E ͑GPa͒	y ͓GPa͔	H ͑MPa͒
	316 L	170	340	⑀		0.3
	͑Ref. 15͒			0.002	400
				0.1	1350
	PC a	2.54	40	⑀		0.3
				0.016	40
				0.038	50
				0.059	56
				0.1	58
	SiO 2	50 a	1 or 4	500		0.25
	͑Ref. 16͒

a Determined by experiment.

ACKNOWLEDGMENTS

The authors would like to thank Nicolas Tardieu for discussing some aspects of the numerical computations, Jean-Denis Touzalin for performing the indentation tests, and Jean Cristoph Eytard for the polycarbonate traction curve. The authors are grateful for the financial support of Air Liquide, Sekurit Saint Gobain, and from CEE Contract No. ERBIC15CT970706.