📝 Developing robot apps

Section

📜 Developing applications - high-level documentation

Robot applications (or robot apps) are a great way to develop and distribute new behaviours for PAL’s robots.

PAL’s robots 100% build on ROS (specifically, as of PAL OS 24.9, ROS 2 Humble), and a robot application is itself one (or several) ROS node(s) that follows a few simple conventions to ease modularity, packaging and skills auto-discovery.

This page:

• introduces the main concepts and terminology you need to understand robot applications and start developing your own;

• explain how to quickly create your first application with the pal_app tool;

• explain the typical workflow for development and testing on the robot;

• link to tutorials to learn how to build more complex applications.

Structure of a robot application

First, a quick run through the terminology:

• the mission controller implements the main role or behaviour of the robot. It reacts to incoming intents and starts tasks to perform actual actions. At a given time, only one mission can be active;

• intents represent the user’s desires or commands. The mission controller monitors incoming intents, and reacts accordingly;

• a task is a (finite) set of actions performed by the robot to achieve a specific goal (i.e. “Doing an Inventory”, “Getting a glass of water”, “Going to the kitchen”). It is time-bound (i.e. it has a finite duration), and can usually be paused and resumed; Tasks rely on the robot individual skills to perform to actions.

• skills are smaller, self-contained operations performed by the robot: saying something using TTS, navigating to a position, performing a gesture are all examples of skills. Some skills are always available, we call them system skills, some are specific to a particular application, we call them user skills;

• Finally, an application is a package made of (usually a single) mission controller, and can include additional resources (eg images, sounds) and custom tasks and skills.

Note

This terminology is mostly aligned with the RobMoSys conceptual model.

Two additional background processes run on the robot to orchestrate applications and tasks:

• a high-level application manager that controls which application is currently active. For instance it could start a ‘receptionist’ application during the day, and a ‘patrolling’ application during the night.

• the tasks coordinator, whose role is to ensure eg that two tasks do not use the same hardware resources at the same time (note that, as of PAL OS 24.9, resources management is not yet fully implemented).

We discuss each of these concepts in greater detail below.

Application

An application is a bundle of one mission controller (see below) and all its required resources (for instance data, text, images, models, additional skills…)

The whole application is bundled as a robot package (see below), that can be easily distributed and installed.

Mission controllers

Mission controllers implement the main role or behaviour of the robot.

The robot’s default application (that you experience eg the first time you turn on the robot) comes with a simple controller that does not do much. For instance, on ARI, it simply triggers the different tasks demoed on the landing page.

Soon, you will want to create more interesting autonomous behaviours for the robot, suited to your task, by implementing your own mission controller.

PAL OS does not enforce any specific structure or technique to implement your controller: you are free to use any control paradigm you wish, from simple imperative-style control scripts, to behaviour trees (BT), finite-state machines (FSM) or symbolic task planner (eg, HTN).

Note

Future releases of PAL OS might enable PAL’s ‘no-code’ tools (eg, visual programming) to quickly create mission controllers. See no-code.

In the section Development workflow: how to create new applications?, we show how a new mission controller can be quickly created with the help of the pal_app tool, and then customized to your application.

Examples of mission controller that you could implement yourself include:

• a ‘robot receptionist’ mission, which welcomes visitors when they enter a building;

• an interactive information robot, which answers questions about a location or an organisation;

• a controller implementing robot tele-operation for an scientific study;

Alternative terminology

Mission controllers are sometimes also referred as supervisors or high-level behaviours in the literature.

Intents

An intent is an abstract description of an operation to be performed by the robot.

Intents are primarily designed to capture user-initiated desires or commands. For instance, a button click on a touchscreen, the result of a chatbot-based verbal interaction, a command started by a remote user interface.

Intents are represented as ROS messages, and they are all published on the same channel (the ROS /intents topic). By monitoring incoming messages on this channel, the active mission can react to user requests.

Note

Intents are also an effective way to test/debug your application: you can manually publish a new Intent message on the /intents topic to simulate any user interaction, and check the controller’s reaction.

In order to facilitate re-usability, intents are standardised. Examples of intents include ENGAGE_WITH, GUIDE, PRESENT_CONTENT, etc.

Learn more about the structure of intents and the list of available ones.

Tasks

A task represents a finite set of actions performed by the robot to achieve some goal (i.e. “Doing an Inventory”, “Getting a glass of water”, “Going to the kitchen”). It is time bound (i.e. it has a finite duration), and can usually be paused and resumed.

The robot’s mission controller is responsible to start (and possibly stop/pause/resume) the required tasks to achieve the desired behaviour. It does so by requesting the tasks coordinator to start/stop the task on its behalf. This level of indirection makes it possible to monitor resource usage, prevent resource conflicts, and offer a level of behaviour tracing.

Tasks themselves then rely on calling skills to perform specific actions.

Note

When developing simpler applications, your mission controller might decide to directly call skills, without creating a task. This is fine, but not recommended for complex applications, as it makes it harder to monitor and control the robot’s behaviour.

You usually need to create your own tasks, as required by your application. Task are regular software modules (typically ROS nodes) and must register themselves in the system using the ament resource index mechanism.

Alternative terminology

Tasks are sometimes also referred as activities or behaviours in the literature.

Skills

Skills are ‘unit’ operations on the robot: navigating to a location, looking at a specific target, grasping an object, etc.

The robot’s SDK offers a set of off-the-shelf skills, called system skills. They are organised in broad categories:

• navigation skills

• gesture-related skills

• social skills

• expressive skills

• communication-related skills

• reasoning and knowledge-related skills

• or direct hardware control

You can as well create your own custom skills as ROS node, and bundle them with your application.

Alternative terminology

Skills are also sometimes referred to as Actions, Atomic actions or Atomic task.

Skills should not be confused with ROS actions. ROS actions are a generic mechanism to perform asynchronous remote procedure calls (RPC), while PAL OS’ concept of skills refers to the implementation of a robot’s operation.

That said, in practise, ROS actions are often used to implement the robot’s skills, especially for asynchronous control.

Application manager

The robot’s application manager is the top-level controller of the robot.

The application manager does not directly execute any task or react to intents. Instead, it starts, manages, and stops specific applications (via their mission controller), based on high-level rules (time of the day, particular context of interaction, etc.).

In PAL OS 24.9, you can only access the application manager via the web-user-interface interface, to manually start and stop applications, and configure a default application that will automatically be launched at startup.

In future revision of PAL OS, we might offer additional APIs to schedule more complex scenarios.

Robot package

Applications can be bundled as robot application packages. Those packages are zip archives of the application and its resources (including the manifest), and can be easily installed on the robot by drag-dropping them onto the robot’s Web user interface interface.

Robot packages must have the .rpk extension. They can be created using the pal_app tool (see below).

Caution

Robot packages are not yet fully supported in PAL OS 24.9. You can instead use the pal deploy tool. See Deploying ROS 2 packages on your robot.

Development workflow: how to create new applications?

The pal_app tool simplifies the creation of new applications for the robot.

Discover more: pal_app.

You can also directly go to our tutorials to learn how to create applications:

• basic-hello-world

• basic-interaction