Engineering the software systems for robotics – An overview

Software plays a vital role in developing robotic systems, capable of artificially replicating human-like capabilities such as sensing, planning, control, reasoning, and learning.

Typically, robot software, especially in autonomous robots, is concurrent, distributed, embedded, real-time, and data-intensive to react quickly to events occurring in all dynamic operational environments.

This has created a big race among the robotic engineers toward performance and delivering highly efficient implementations of control applications for specific robotic platforms that perform specific tasks in specific operational environments.

To seamlessly combine various complex hardware and software components and enhance the efficiency, robustness, safety, reliability, and cost of robotic systems, engineers must increasingly focus on exploiting software engineering methodologies that consist of software components, middleware for distributed systems, application frameworks, and model-driven engineering.

Sensors, actuators, and other mechanical parts are readily available from various dedicated suppliers with precisely specified characteristics, and they can be re-used in different systems. In contrast, most robotics software systems are based on proprietarily designed software architectures. These software systems are often tightly bound to specific robot hardware, processing platforms, or communication infrastructures. Besides, assumptions and constraints about tasks, operational environments, and robotic hardware are hidden and hard-coded in the software implementation.

Some unique aspects of robotic software design and development are as follows:

  • Re-usability of components (to compose the robot system starting from appropriate levels of abstraction)
  • Simple configuration of those components – instead of low-level programming
  • Possibility for the specification of the desired behavior at the highest levels instead of “wiring in” pre-defined schemata at various software architecture levels.

Several different approaches to robotic software development have evolved based on the availability of some simulation models of robotic components. They are:

  • Total software simulation
  • Partial simulation and software-augmented hardware
  • Software driving both simulator and hardware robot (e.g., assembling parts in a factory)
  • No simulation during normal usage

Real-time operating system (RTOS)

Typically, multiple software control levels need to take place within all but the simplest robots. The microcontroller units (MCUs) and system-on-chip (SoC) solutions responsible for managing sensors and actuators will generally take advantage of a real-time operating system (RTOS) or kernel.

The advantage of using an RTOS is support for multi-tasking. It provides a relatively simple way to schedule numerous activities on a single microprocessor to maximize resources and the ability of the system to react to external events. For example, opening the safety cage needs to trigger a suspension of activities to minimize risk to the robot and personnel. Simply removing power is potentially unsafe. An RTOS can trigger all the actions needed to place the robot in a non-moving state but ensure that it does not drop heavy objects or cause damage anything else. This can be achieved, for example, by moving to a software thread that orders the power electronics circuits to hold motors in predefined positions.

In combination with appropriately designed applications software, an RTOS can provide hard guarantees of the amount of time it takes to react to critical events, generally signaled by an external interrupt to the microprocessor. This is usually handled through an interrupt handler, which may initiate a software thread that can take action. Through priority-based pre-emptive scheduling, the RTOS guarantees the shortest possible latency for this type of response to the most critical issues.

Robot operating system (ROS)

In a robot with multiple microprocessors and hardware accelerators, which is increasingly the case, each actuator node needs to be controlled by a supervisory system that takes care of task planning and high-level behavior. This is a role that is typically undertaken by middleware, such as the robot operating system (ROS) running on a high-performance microprocessor.

Today, an ROS is designed to run on an operating system such as Linux rather than being an operating system in its own right. ROS also does not demand RTOS behavior from the underlying operating system as it is performing longer-term tasks than those that need microsecond response times. However, work is underway to build ROS 2.0 implementations that will run on RTOS platforms to offer higher degrees of responsiveness.

The middleware that makes up ROS provides a variety of services. They include hardware abstraction of low-level devices and support for messages passing between processes to enable multi-processor architectures and software packages management. Typically, processes are represented using graphs that link nodes to denote where processing takes place and how they communicate. ROS implementations are often open-source packages and use Linux platforms to ease the job of managing dependencies between open-source projects. This has the benefit of making ROS software easy to access. In ROS, nodes are processes or software modules that handle one or more related tasks. For example, a camera and image processing node may process visual data from one or more image sensors. To enable networking infrastructure to interconnect nodes – an architecture now typical in automotive systems – ROS supports TCP/IP and UDP for message passing. The various nodes and connections can be described using the Universal Robot Description Format (URDF), an XML file format.

ROS employs a publish-subscribe mechanism in which nodes register to be informed of specific topics to enable efficient sharing of sensor data and commands. Any updates on each topic are sent to all of the subscribed nodes. The ROS Master keeps track of all services and topics. It handles node registration and operates a parameter server to allow nodes to store and retrieve common configuration data. A significant advantage of middleware, such as ROS, is code reuse and sharing. Code sharing allows all users to have a common software base, which helps with testing and overall software reliability. ROS is not restricted to physical robots. It also supports simulated robots.

Robot simulation software

An essential requirement of robot design is to simulate its behavior in the virtual environment before implementation in hardware. The simulator allows for robotics programs to be written and debugged offline. It enables the development of software in a risk-free environment. It avoids damaging the robot or the robot’s surrounding environment if the proposed program contains serious errors. The final version of the program can then be tested on an actual robot.

There are further advantages of simulation. Designers can develop in phases, starting with simple high-level models, which is beneficial for complex projects. Such simulations can be used at an early stage to establish whether a system is viable. The simulation environments developed for robotics are designed to be compatible with a wide range of programming languages, supporting easy development. And simulation can cut development time as it allows mistakes in application logic to be corrected before they are committed to hardware and become much more challenging to fix.

There are several approaches to robot simulation. Traditionally, the simulation was focused on the robot movement’s kinematics to demonstrate whether paths and trajectories are feasible and practical.

This simulation type puts a virtual robot into a 3D space and demonstrates how joints are likely to move in the physical world. The simulation can also help determine whether a robot will lift and manipulate heavy or bulky objects without losing stability. Some kinematics simulators use a simplified set of calculations and focus primarily on how a program may rotate and move objects to ensure they do not collide with a safety cage or work-cell boundaries. Others involve more complex physics simulations to gauge the stresses and other issues affecting robot performance in the field.

As robots move out of controlled environments protected by safety cages and into areas where people and other robots can move around freely, designers need to consider possible interactions. For mobile robotics design, simulators that deal with behavior let designers create, at a high level of abstraction, virtual worlds that contain other objects. A simple behavior simulation just considers the motion of a robot among a set of fixed objects. More complex simulations involve the use of multiple mobile agents or avatars. These behavior-based simulators help design applications where the robot is likely to be faced with complex environments. They can learn from collisions and other interactions to better deal with obstacles. Physics simulations are essential for establishing that the kinematics of the robot are accurately represented.

Simulation environments such as the open-source Gazebo package can generate realistic sensor data that may be corrupted with varying noise levels.

There are, however, limits to simulation. An application can only simulate characteristics and events for which it is programmed. Internal or external factors are not represented and will not be simulated, leading to problems when the design is translated into hardware. It is also often challenging to build sufficiently representative scenarios, especially when evaluating complex situations and behaviors. However, experience with translating simulated designs into the physical environment can be fed back into future projects, which will reduce errors as time goes on. As a result, simulation remains one of the most powerful tools in the armory of the robot engineer.

Key takeaways

  • Most readily available robot operating system (ROS) implementations do not run on a rigid real-time operating system (RTOS), but the components that provide data to the ROS will often need to be based on an RTOS.
  • Engineers can choose from open-source or commercial offerings for ROS, simulation, and RTOS options.
  • Simulation environments cover various needs, from basic motion profiles through physics-assisted kinematics to behavior in complex scenarios.


Please enter your comment!
Please enter your name here