This conference is aimed at addressing important aspects of robot control architectures, with a specific emphasis on distribution, verification and validation, languages and modeling, and implementation of control architectures. It brings together researchers and practitioners from universities, institutions and industries, working in this field. It intends to be a meeting to expose and discuss gathered expertise, identified rends and issues, as well as new scientific results and applications around software control architectures related topics, through plenary invited papers.

Due to their increasing complexity, nowadays intervention robots, that to say those dedicated for instance to exploration, security or defence applications, definitely raise huge scientific and commercial issues. Whatever the considered environment, terrestrial, aerial, marine or even spatial, this complexity mainly derives from the integration of multiple functionalities: advanced perception, planning, navigation, autonomous behaviours, in parallel with communication or robots coordination enable to tackle more and more difficult missions.

But robots can only be equipped with such functions if an appropriate hardware and software structure is embedded: the software architectures will hence be the main concern of this conference.
As quoted above, the control architecture is thus a necessary element for the integration of a multitude of works; it also permits to cope with technological advances that continually offer new devices for communication, localization, computing, etc. As a matter of fact, it should be modular, reusable, scalable and even readable (ability to analyze and understand it).
Besides, such properties ease the sharing of competencies among the robotics community, but also with computer scientists and automatics specialists as the domain is inherently a multidisciplinary one.

Numerous solutions have been proposed, based on the “classical” three layers architecture or on more “modern” approaches such as object or component oriented programming. Actually, almost every robot integrates its own architecture; the workshop will thus be a real opportunity to share reflections on these solutions but also on related needs, especially on middleware for robotics, which are of particular importance in multi-robot applications for instance.
Hence, this conference on control architectures of robots aims at gathering a large number of robotics actors (researchers, manufacturers as well as state institutions) in order to highlight the multiple issues, key difficulties and potential sources of advances.

Schedule – Dates
- Paper submission (full paper or extended abstract): May 18 2015
- Paper Acceptation Notification : May 29 2015
- Camera Ready due : June 29 2015
- Conference: 29-30 June 2015

Submission Guideline
- Even if CAR is a french conference, we prefer articles written in english
- No specific style is asked : latex article style is OK
- No limit on article length, usually articles for CAR are between 6 and 17 pages long !

Web Page

Scientific Committee
- David Andreu LIRMM, Univ. Montpellier 2
- Noury Bouraqadi Ecoles des Mines de Douai,
- Jacques Malenfant LIP6, UPMC
- Roger Pissard-Gibollet INRIA Grenoble,
- Julien Ponge CITI-INRIA, INSA de Lyon
- Olivier Simonin CITI-INRIA, INSA de Lyon
- Serge Stinckwich UBCN & UMMISCO, IRD/UPMC


  3. tf_splitter decomposes the /tf topic into multiple ones.



-coordination algorithms for multi-robot systems.
-mobile robot programming and software control architectures.
-Robot middleware such as ROS.

A background in dynamic languages would be a plus.


In traditional robot behavior programming, the edit-compile-simulate-deploy-run cycle creates a large mental disconnect between program creation and eventual robot behavior. This significantly slows down behavior development because there is no immediate mental connection between the program and the resulting behavior. With live programming the development cycle is made extremely tight, realizing such an immediate connection. In our work on programming of ROS robots in a more dynamic fashion through PhaROS, we have experimented with the use of the Live Robot Programming language. This has given rise to a number of requirements for such live programming of robots. In this text we introduce these requirements and illustrate them using an example robot behavior.

This presentation has been given at the DSL Rob Workshop held as part of the SIMPAR 2014 conference (Bergamo, Italy).



  1. Follow the steps 1 to 4 of this post.

    LrpharosPackage uniqueInstance
  3. Create an instance of the RobulabBridge class

    RobulabBridge uniqueInstance

Stop when an obstacle is detected


    (var robulab := [RobulabBridgr uniqueInstance ])
    (var min_distance := [0.5])
    (var f_vel := [0.25])
    (var t_vel := [0.5])
  2. We define the state machine called Tito.

    (machine Tito
        ;; States
        (state forward
            (onentry [robulab value forward: f_vel value])
        (state stop
            (onentry [robulab value stop])
        ;; Transitions
        (on obstacle forward -> stop t-avoid)
        (on noObstacle avoid -> forward t-forward)
        ;; Events            
        (event obstacle [robulab value isThereAnObstacle: min_distance value])
    (spawn Tito forward)


Avoiding obstacles

Then a simple behavior that match the avoidance requisite is:



  1. Add the following states

            (state turnLeft
                (onentry [robulab value turn: t_vel value])
            (state turnRight
                (onentry [robulab value turn: t_vel value negated])
  2. Add the corresponding transitions

            (on rightObstacle stop -> turnLeft t-lturn)          
            (on leftObstacle stop -> turnRight t-rturn)
            (on noObstacle turnLeft -> stop t-tlstop)
            (on noObstacle turnRight -> stop t-trstop)
  3. And add the events

            (event rightObstacle [robulab value isThereARightObstacle: minDistance value])
            (event leftObstacle [robulab value isThereALeftObstacle: minDistance value])



    (onentry [robulab value turn: t_vel value negated])

is turned to

    (onentry [robulab turn: t_vel negated])

making it more readable.