The cleaning and maintenance of commercial premises using robots is still a fledgling technology in our country. Alongside the imported products brought in from the Far East as a quick fix, Ara Robotik has also begun providing services in our country with its locally manufactured robots. However, the waters are still murky; standards have not yet been fully established, and companies lacking advanced software are attempting to prove themselves by bending these standards.

In this article, we will examine the technical details of the ISO 3691-4, EN 1525 and the more recent ISO 3691-4:2020 standards regarding mapping and navigation requirements for driverless industrial vehicles and autonomous mobile robots, as well as certain operating conditions.

Let us first address the Navigation System Requirements.

Fundamental Safety Principles:

The standards primarily highlight the following points.

Navigation systems must provide reliable, uninterrupted position determination.
The system must detect deviations from planned routes and respond appropriately.
Back-up navigation methods must be available should the primary system fail.
Positioning accuracy requirements must be defined according to the application and the necessary safety zones.

The key rule required by these points—and which must be strictly adhered to—is that the robot must always know its position, be able to decide what to do when encountering an obstacle, and have a Plan B in the event of a problem.
So, which navigation technologies are covered by the standards?

Common navigation technologies include:

Laser/optical guidance systems
Guidance using magnetic strips or wires on the floor (quite common in AMRs)
Natural feature navigation (using building features)
A combination of inertial navigation and other methods
Vision-based systems and SLAM (Simultaneous Localisation and Mapping)

Right, we’ve identified the navigation methods; now let’s look at what’s required for mapping.

The ISO 3691-4, EN 1525 and ISO 3691-4:2020 standards outline the following requirements for the installation and mapping of autonomous robots:

Maps must accurately represent the operational environment
Changes to the layout of the premises require map updates and verification
Defined traffic routes and restricted areas
Clear marking of restricted areas where people may be present

Simple, and indeed, most of you will already be familiar with these from your home robots. The robot first creates a map, divides the areas as it sees fit, and you then organise those sections using commands such as ‘split’, ‘merge’ or ‘restrict’. This is where things get a bit tricky, and where the core software capabilities really come to the fore.

If the mapping and navigation software of the robot you are selling or using does not have sufficient infrastructure and level of detail, and cannot adapt to dynamically changing environmental conditions, you would naturally not want to use it in the presence of people.

The same standards have summarised Safety-Critical Navigation Features as follows:

Redundancy and tracking:

Obstacle detection independent of navigation (redundancy)
Safe position tracking – the system must be able to detect when it has ‘lost its way’. (In very crowded areas, mapping beams constantly encountering people may cause the robot to lose its exact position; in such cases, it should stop and attempt to re-orient itself)
Safe stopping procedures in the event of navigation failure (the first action in the event of mechanical or electronic faults should be to stop safely)
Speed limits in areas of uncertainty
Zone-based behaviour (different speeds/rules in different mapped areas) (e.g. operating more slowly in areas expected to be crowded, and manoeuvring more freely in open spaces)

Performance criteria:

Positioning accuracy tolerances (typically within the range of ±10–50 mm – wall-following is a priority)
Position update frequency requirements (more frequent updates = safer)
Navigation system response times (faster = safer; this is not a job for substandard processors)
Route deviation threshold values

If there are other robots in the environment, you can also fulfil the integration requirements with them under the following conditions. Although it is not known exactly where your data goes with robots imported from the Far East, I have nevertheless included the data management required by the standards.

System-level integration:

Communication protocols between vehicle navigation and fleet management systems (enabling control of each vehicle from a single point)
Coordination between multiple vehicles sharing a mapped area (Ara Robotics, for example, has a highly advanced infrastructure in this regard)
Interface with facility security systems (ability to operate in conjunction with gates, lifts and traffic lights)
Integration with emergency stop systems (ability to intervene not only with the relevant robot but with all robots if there is a problem anywhere in the system)

Data management:

Map data format and data integrity
Version control and change management
Map synchronisation (across the entire fleet)

As these two standards cover every wheeled autonomous device operating in indoor environments, we must also specifically examine the general Risk Assessment Requirements.

Hazard scenarios related to navigation:

Loss of position or incorrect localisation (mistaking its location for another)
Discrepancies between the map and the real environment (may require remapping)
Sensor failures or blind spots
Environmental conditions affecting navigation (lighting, reflections, dust)
Damage to or alteration of the navigation infrastructure (physical issues)

Risk mitigation measures:

Multi-sensor fusion (if your processor infrastructure is powerful, more sensors = a better map)
Definition of safety zones and speed-reduction zones
Pedestrian detection and collision avoidance systems (secure sensor infrastructure, use of artificial intelligence)
Fail-safe behaviours in the event of navigation failure

Technical Requirements for the Application

When you bring the robot into an environment and run it for the first time, it creates a map and sends it to you (to a tablet or computer) as a base map. Below, we list the first steps to be taken and—if you are working with a reputable robot manufacturer—the rare instances where human intervention may be required, in accordance with industry standards:

Map validation tests following initial setup (have the general outlines of the space, columns and walls been mapped correctly?)
Position accuracy measurements using reference points (are specific reference points in exactly the correct position?)
Performance tests under different environmental conditions
Failure modes and effects analysis (FMEA)
Periodic calibration and validation procedures

Safety Zones and Mapping

Prohibited zones (no-go zones): The robot must not enter under any circumstances (Off-limits mode)
Restricted zones: Entry permitted only with special authorisation or under specific conditions (‘I’ll just pop in to see a mate’ mode)
Speed-restricted zones: Areas with potential for human interaction (‘Be wary of humans’ mode)
Car parks/waiting areas: Idle waiting points (‘My turn will come’ mode)
Charging stations: Areas requiring precise positioning (‘Don’t touch the oil paint’ mode)

Dynamic map updates

Any robot equipped with good software continuously updates its map, incorporates even momentary changes into it, optimises its operations accordingly, and adjusts its manoeuvres to avoid obstacles.

Mechanisms for adding temporary obstacles to the map
Integration with traffic management systems
Real-time route optimisation
Emergency routes and escape routes

These two standards do not prevent robots from operating fully autonomously, but they very clearly summarise the requirements that must be met in terms of software and hardware infrastructure. If you meet these criteria, you will have no issues with mapping, autonomous operation or operating in public spaces; you can use your robot with confidence.