Reference resource

This page covers the essential concepts and links to more specialised resources. Capabilities, constraints and rules must always be checked against the relevant site and use case.

A patrol robot designed for outdoor spaces

OTSAW O-R3 is a wheeled autonomous security robot developed by the Singapore-based company OTSAW. It is presented for patrols in locations such as commercial properties, industrial areas, campuses and other structured outdoor or semi-outdoor environments. For verification, see Official O-R3 presentation (OTSAW) and Robotics as a Service (OTSAW).

The robot combines navigation sensors, panoramic cameras, communication and a software platform. Its purpose is to repeat selected routes, maintain a visible presence and provide remote teams with information from points that fixed cameras do not cover well.

O-R3 is not an independent decision-maker. A person or vehicle alert remains a signal that requires context. The operator must know whether the subject is authorised, whether the route is open and what response is proportionate.

The product is particularly relevant to organisations considering a service model rather than owning and engineering every component. That can simplify entry, but it makes supplier quality, service levels and data arrangements central to the decision.

Explore this topic

For a deeper analysis, read Argus S5. Another wheeled outdoor patrol platform.

3D SLAM provides bounded autonomy

SLAM allows a robot to build or use a map while estimating its position within it. Three-dimensional sensing can improve obstacle awareness and localisation. The robot can then follow waypoints and adapt its path around selected temporary objects.

Autonomy remains bounded by the prepared environment and software rules. Delivery pallets, crowds, reflective surfaces, rain, changed fences or an unexpectedly closed passage can create exceptions. The system needs safe stopping behaviour and a method for remote assistance.

A pilot should not use only an empty demonstration route. It should include staff, vehicles, moved objects, narrow passages, low light and wireless shadows. The purpose is to measure repeatability, not to prove that the robot can complete the easiest possible circuit.

Maps also contain sensitive operational information. Access to route data, restricted zones and site layouts must be controlled. Changes should follow an approved process so that a convenient navigation edit does not accidentally introduce a privacy or safety problem.

For a deeper analysis, read Business security. Design patrols around real risks.

Video, AI and alerts must be expressed as measurable performance

Panoramic video can provide useful awareness around the robot. Analytics may classify people, vehicles or other events, depending on the configured software. These functions should be translated into testable requirements: target size, distance, lighting, detection rate and acceptable false alarms.

An alert without its source image, position and confidence is difficult to review. The operator should be able to understand what triggered the event and confirm or reject it. Decisions should never rely on a hidden score alone.

Security sites contain legitimate activity. Cleaners, drivers, contractors, animals and moving vegetation can all appear unusual. Testing must include these normal cases so that the customer can measure the burden placed on the monitoring team.

A loudspeaker or intercom can help a remote operator ask a person to identify themselves or leave a restricted area. Scripts and escalation limits should be defined. The robot should preserve distance and avoid pursuit or confrontation.

Explore this topic

Robot-as-a-Service creates flexibility and supplier dependence

A service model can spread the cost of hardware, software, maintenance and support over time. It may also give the supplier responsibility for fleet health and updates. This is attractive to a customer that does not want an internal robotics team.

The contract becomes part of the technical architecture. It should specify availability, support hours, recovery, replacement, software functions, update policy, cybersecurity incidents and data ownership. A low monthly price has limited value if a stranded robot waits days for assistance.

Customers should confirm what happens at the end of the service. Maps, patrol history, incident records and exported evidence need a defined format and deletion process. The customer should not lose access to legally or operationally necessary records.

Supplier dependence can be managed through clear interfaces and fallback procedures. Fixed security continues without the robot, while documented data exports and integration boundaries reduce the cost of changing provider later.

A Swiss project must limit both the route and the data

The patrol should remain within the customer’s legitimate perimeter and avoid neighbouring properties or public space where possible. Camera orientation, recording schedules and restricted zones should be configured deliberately rather than left at broad defaults.

Employees and contractors need information about the system. On a workplace, security is not a justification for continuous observation of individual behaviour. Night patrols and route choices can reduce the amount of personal data collected. For verification, see Video surveillance in the workplace (FDPIC).

Routine footage should have a short retention period. Confirmed incidents may be preserved under a controlled evidence process. Named accounts, access logs and export controls prevent a mobile camera from becoming an uncontrolled source of recordings.

The robot, charging point and cloud connections need network segmentation, strong authentication and controlled supplier access. The project should test a communication loss and make sure the machine enters a safe state without depending on an operator’s immediate reaction.

Explore this topic

For a deeper analysis, read Business solutions. Connect mobile observation to human response.

Our view: a credible alternative for regular routes

O-R3 is a credible option for structured sites that value a service-led deployment and a compact wheeled patrol platform. The strongest routes are predictable, relatively smooth and sufficiently controlled to keep interactions safe.

Ascento Guard offers hybrid mobility and Swiss proximity. Argus S5 targets large outdoor perimeters with a substantial sensor platform. Knightscope K5 has a long public deployment history in the United States. The right comparison depends on route, integration, support and data governance.

A pilot should measure completed routes, useful alarms, false positives, remote interventions, recovery, downtime and operator workload. It should run long enough to include weather, normal traffic and changing obstacles.

The service succeeds when the robot reliably supplies information that shortens a security decision. If staff spend more time rescuing the platform or reviewing weak alerts than they save, the project needs redesign regardless of the advertised autonomy.

Explore this topic

Frequently asked questions

What is OTSAW O-R3 designed to do?

It is designed to repeat security patrols, provide mobile video and support remote alarm verification on structured sites.

What does 3D SLAM mean?

It is a mapping and localisation approach that helps the robot estimate its position and navigate around the environment.

Does Robot-as-a-Service include everything?

Not necessarily. Monitoring, integration, recovery, support hours and data services must be listed precisely in the contract.

Can O-R3 operate around employees?

Potentially, after safety and privacy analysis, route limits, staff information and representative testing.