As AMRs (autonomous mobile robots) and forklift-type robots are adopted more widely across manufacturing sites and logistics hubs in Thailand, the challenge is shifting dramatically from “getting one robot to move” to “keeping a fleet of dozens or hundreds of robots running without stopping.” With a single robot, people can keep track of its route and its charging schedule. But once many robots start moving on the same floor at the same time, a whole set of problems erupts at once: collision avoidance at intersections, congestion in aisles, deadlock in dead-end passages, and falling utilization caused by robots queuing to charge. Handling all of this manually is not realiztic, which makes a brain that intelligently commands the entire fleet – namely an RCS (Robot Control System) – indispensable. TOMAS TECH provides fleet management platforms such as Hikrobot’s RCS-2000 to manufacturing and logistics customers in Thailand, integrating not merely robot hardware but the complete “fleet-control mechanizm that keeps the site running.” This article explains, in practical terms, what an RCS is, why fleet control is necessary, its main functions and architecture, host system integration, large-scale operation, visualization and analytics, the benefits of adoption, ease of deployment with the lightweight edition, the implementation process and pre-deployment checks, maintenance and support, and finally a set of frequently asked questions.

What is RCS (Robot Control System / RCS-2000)?

An RCS (Robot Control System) is a control system that single-handedly manages task allocation, scheduling, traffic operation, and operational maintenance for every robot working on site. Hikrobot’s RCS-2000 uses multiple scheduling algorithms to assign tasks optimally, and through multi-robot path planning and robot traffic management it directs each robot so that they cooperate without interfering with one another. This maximizes the working efficiency of the fleet as a whole and supports material handling (the transport of materials and products) that spans different scenes such as warehouses and production lines.

Put simply, the RCS is the equivalent of an airport control tower. No matter how skilled an individual pilot may be, once many aircraft gather on the runways and in the airspace, safe operation is impossible without a controller who oversees the whole picture and dictates the sequence and routing of takeoffs and landings. The controller mounted on each individual robot (the brain on the robot itself) handles that machine’s own travel and load handling, but the fleet-wide decisions of which robot performs which task, in what order, and when, are the responsibility of the RCS. The intelligence of a single robot and the intelligence that binds a fleet together are two different things, and it is the RCS that provides the latter.

RCS-2000 covers not only warehouse inbound and outbound operations but also the continuous flows specific to manufacturing sites, such as supplying raw materials to production lines, inter-process transport, and putting finished goods into storage. It receives tasks issued by third-party systems (host systems such as WMS, MES and ERP), or automatically generates tasks based on production information collected from equipment by the WCS (device control service), and then selects the optimal carrier according to area, strategy and material attributes. In other words, the RCS is not merely a device that issues instructions to robots; it is a software platform that functions as the “execution hub” connecting host business systems with the robot fleet on the floor.

Why fleet control is necessary – four barriers that emerge in multi-robot operation

Customers who have introduced a single robot and seen the benefits typically hit the “multi-robot barrier” the moment they try to increase the number of units. Benefits do not simply grow in proportion to the number of robots; without proper control, adding units can instead cause congestion and stoppages, and may even cancel out the return on investment. Below we organize the four representative barriers that fleet control must overcome.

Avoiding interference and collisions

When multiple robots travel on the same floor, there will inevitably be moments when their paths overlap at intersections or in narrow aisles. If each robot only sees its own immediate surroundings, they cannot yield to one another and may end up deadlocked face to face, or in the worst case make contact. The RCS grasps the position and heading of the entire fleet in real time and centrally decides which robot goes first and which robot waits, preventing collisions before they happen.

Controlling congestion

Just like roads used by people, robot aisles become congested when load concentrates on particular sections: queues waiting for picking, concentration at inbound and outbound doors, or single-lane aisles that act as bottlenecks. The RCS path planning algorithm does not simply seek the shortest route; it distributes routes so that overall travel cost is minimized, predicts congestion, and applies detours or sequencing control in advance. This avoids the situation in which a few robots get caught in congestion and drag down the efficiency of the whole fleet.

Preventing deadlock

Deadlock is the state in which multiple robots block each other’s paths and none of them can move. It occurs particularly easily in single-lane aisles and confined areas, and once it happens the entire fleet can remain stopped until a person intervenes and resolves it manually. The path planning algorithm of RCS-2000 dynamically manages the situation even while tasks are being executed, predicting congestion and preventing deadlock in advance so that AMR traffic efficiency is maximized. On the premise that there is no congestion, it provides several processing mechanizms including shortest-route provision, collision avoidance control, and re-planning control.

Maintaining utilization

As the number of units grows, managing charging timing also becomes complex. If every machine goes to charge at once, transport capacity plummets; conversely, if charging is neglected, robots run out of battery while traveling. The RCS coordinates a charging strategy based on remaining battery level across the whole fleet – for example, stopping acceptance of new tasks and heading to charge once the level falls below a lower threshold, and not sending a robot to charge if it is above the upper threshold – so that the required number of active units is always secured. Suppressing interference, congestion and deadlock while intelligently rotating charging: this combined capability is the value of fleet control, and it delivers operation in which efficiency does not degrade as the fleet grows.

Main functions of the RCS

RCS-2000 systematically provides the functions required for fleet control as modules. Here we explain the core function groups following the flow of actual operation.

Task assignment (TAS) and scheduling

TAS (Task Assignment Service) is the core function that assigns generated tasks to the optimal robot. The task assignment algorithm does not look only at total transport distance; it also takes into account the balance of workload at transport destinations. Furthermore, it manages tasks dynamically even during execution, adjusting the assignment strategy as appropriate to raise overall operational efficiency. The criteria used for assignment include task priority, task creation time, distance, robot battery level, and the number of idle robots. When a task starts, the optimal robot is selected, and tasks can also be switched dynamically between robots according to the situation.

Task priority control is equally comprehensive. In addition to the default priority of a task template and the priority set at task creation, the system provides a mechanizm that dynamically adjusts priority in real time based on deadline time. It also supports changing destination points and interrupting tasks, so it flexibly follows changes in on-site conditions.

Multi-robot path planning

The path planning algorithm plans optimal routes that minimize total travel cost in scenes where multiple vehicles using different navigation methods are mixed. As described above, it also manages the situation dynamically during execution, predicting congestion, preventing deadlock before it occurs, and maximizing AMR traffic efficiency. It has the path planning capacity to handle more than 1,200 AMRs on a single map, and is designed to support large-scale topologies on the order of 30,000 nodes.

Traffic management (traffic control)

Traffic management handles the order of passage at intersections, one-way control of single-lane sections, advance scheduling, sequencing control and load balancing, keeping the flow of the whole fleet smooth. It is also possible to configure “vehicle control areas” that set a maximum number of vehicles per area according to vehicle type, preventing robots from concentrating in a particular section. Operational actions such as blocking and unblocking areas, pausing and restoring areas, and clearing areas are also provided, so that a single zone can be safely isolated during maintenance or an abnormal event.

Charging management (smart charging)

The smart charging function within the robot control service (RCS) governs the battery strategy of the whole fleet. Based on battery level thresholds – for example, stopping task acceptance and starting charging once the level falls below a lower limit, stopping charging once a specified value is exceeded, and not sending a robot to charge if it is above the upper limit – charging is rotated in a planned manner while securing the number of active units. This prevents situations such as “transport stops because every machine charges at once” or “a robot halts mid-travel due to insufficient charge.”

World Model (modeling the objects of execution)

World Model (world model construction) is a function that models execution objects, transport objects, storage objects and the like, and exposes their attributes, methods and events to enable model design. By representing the physical world on site (robots, loads, racks, stations and so on) as abstract models in software, the system can understand and control complex scenes consistently. It is precisely this abstraction that allows the system to be adapted flexibly to a wide variety of sites and industries.

Device management (WCS)

The WCS (Warehouse/Device Control System, the device access service) is responsible for integrating peripheral equipment other than robots into the RCS. It supports multiple protocols including TCP, serial port, UDP, REST, IO, SDK and OPC UA, and connects a wide variety of equipment such as lifters, robot arms, conveyors, stretch-film wrapping machines, scanning gates, cameras, PTL (pick-to-light), call and signal lights, and fire alarms. By bringing multiple protocols, multiple devices, multiple functions and multiple scenes under a single point of control, an automated line in which robots and equipment cooperate can be built. It also supports VDA5050-compliant interfaces, including online device registration via an MQTT broker, offline and last-will management, fact sheets, task control and state acquisition.

Alarm management (AMS)

AMS (Alarm Management Service) handles the querying and processing of alarms that occur during fleet operation. It detects abnormalities early and handles them appropriately through functions such as pushing task timeout notifications and alarm notifications, disabling machines in an abnormal state and stopping new assignments to them, and sending alarm notifications from AGVs to host systems. A rich set of exception-handling measures is also provided, including task cancellation by soft cancel or hard cancel, task transfer, binding and unbinding of racks, and enabling and disabling of stations.

Centralized management (CMS)

CMS (Centralized Management Service, RCMS) consolidates the central management functions covering mapping, vehicles, devices and peripheral equipment. In large-scale operation it bundles multiple instances of RCS and WCS and manages them as a group, enabling segmented map management and seamless switching of robots between maps. On the operational maintenance side, one-click return-to-base and power-off, timer-based start and stop, and AGV version management and OTA (over-the-air update) can all be executed from centralized management.

Architecture – a three-layer structure and the iData series

The fleet management platform centered on the RCS is built as a layered architecture with clearly separated roles. Broadly, it is divided into three layers: the Business Layer that governs business operations, the Management Layer that manages the fleet, and the Execution Layer that actually drives the robots, with business systems connected above and the device layer connected below. This separation of layers allows each layer to be extended and maintained independently, and keeps the whole system comprehensible even at large scale.

Internal modules of RCS-2000

The scheduling layer of RCS-2000 consists of several service modules working together: RCMS, the central management service (management of mapping, vehicles, devices and peripheral equipment); RTAS, the task orchestration service (orchestration, message processing, tasks, logs); iDataMeta, the statistics service (dynamic data, custom kanban boards, statistical indicators); RCS, the robot control service (robot control, path planning, task assignment, smart charging); AMS, the alarm service (alarm query and processing); and WCS, the device access service (management and control of peripheral equipment). In addition, a set of supporting tools – the monitoring client, mapping client, simulation client, PDA terminals and APP terminals – underpins day-to-day operation on site.

The iData series (iDataMeta / iDataView / iDataFlow / iDataBus)

What underpins the flexibility of this architecture is the iData series, a low-code development platform. Each component has a clearly distinct role.

• iDataMeta (data collection): the foundation that collects and organizes fleet operation data such as dynamic data, statistical indicators and customizable kanban boards. It collects business data from across the whole operation along multiple dimensions and pre-processes it comprehensively.
• iDataView (data visualization): responsible for visualizing business data and generating custom reports tailored to business needs. It supports statistical reports, dashboards, Excel export, data source extension and more.
• iDataFlow (business flow design): provides data models, data transformation, tool nodes and business flow design, making it possible to compose back-end logic on a process basis.
• iDataBus (interface platform): as the Hik interface platform, it serves as the portal responsible for integrating heterogeneous data from multiple sources and connecting with host systems.

With these low-code development components, an approach of “flexible configuration plus low-code development” makes it possible to respond flexibly to custom requirements and keep pace quickly with changes in business. For flow composition, seven major categories of process nodes are provided – flow, tool, event, AMR action, sub-flow, decision and resource – extending the conventional “single-line process” into a “multi-branch process” so that more complex business scheduling scenes can be handled.

iWMS integration

iWMS-1000 is a business management system centered on inventory management, combining multiple data mining and AI technologies. It makes use of the four iData low-code development components described above to achieve flexible configuration and rapid customization. Combined with the RCS, iWMS delivers efficient and intelligent warehouse management for a wide range of scenes and industries. It comes with a rich set of business algorithms – a rack location recommendation algorithm, an inventory allocation algorithm, an intelligent wave algorithm, an SKU turnover adjustment algorithm and an intelligent stocktaking algorithm, among others – and covers business scenes such as inbound, inventory, movement, outbound, storage management and exception handling. If the RCS is the “brain that moves the robots,” iWMS is the “brain that manages the inventory,” and the linkage of the two brings intelligence to the warehouse as a whole.

Host system integration – standard interfaces with WMS/MES/ERP/OMS

The RCS does not only drive the robot fleet on the floor; it demonstrates its true value when it is tightly integrated with the company’s core business systems. RCS-2000 provides standard interfaces for connecting to host systems such as ERP, WMS, MES, OMS and MCS. The standard interfaces cover operations such as task generation, task cancellation, return of execution results, state acquisition and manual intervention, reliably bridging instructions issued by host systems into the movements of the robot fleet.

There are broadly two integration patterns. In the first, a third-party system such as a WMS issues actual tasks, and the RCS receives them and assigns robots. In the second, the WCS collects production information from equipment and automatically generates scheduling tasks. In the latter case, “advance scheduling” is also possible, internally triggering pre-dispatch tasks according to the production progress of machines; by preparing robots before a task is actually needed, waiting time in upstream processes is reduced.

Through iDataBus (the Hik interface platform), business data such as SKU master data, inbound orders, outbound orders, inventory details and stocktaking details can be synchronized with host systems, and heterogeneous data from multiple sources can be handled in an integrated way. In actual deployments as well, there are cases where RCS-2000 was seamlessly connected to the user’s WMS to achieve digital management of storage information, and cases where multiple systems such as RCS-WCS-ERP-AS/RS were coordinated to achieve intelligent management of warehousing and transport. TOMAS TECH supports the design and implementation of such host system integration in a way that suits sites in Thailand.

Large-scale operation – grouping multiple RCS instances and scaling to thousands of robots and several million square meters

One of the major strengths of the RCS is its scalability to large-scale operation. RCS-2000 is designed with a project scale of thousands of AMRs and fields of several million square meters in mind, and by grouping multiple RCS instances it enables operation beyond the limits of a single system.

The key to scaling up is “division and coordination.” A very large map is managed by dividing it into multiple maps, and robots access different RCS instances in response to map changes, much like air traffic control areas. Robots achieve “seamless (imperceptible) switching” across maps, so operators can run the fleet without being conscious of the boundaries. For load balancing and cluster management, Nginx distributes external instructions to each service for processing, in a configuration where the crash of a single service does not affect overall operation. By expanding service resources, the scheduling performance limits of a single server can be broken through, giving scalability with no theoretical upper bound.

Deployment modes can also be chosen according to the scale of operation. Standalone mode is available for demonstrations, UAT and a small number of AMRs; quorum mode (2 servers plus an arbitration server) for small and medium-scale operations of 20 units or fewer; and cluster mode (3 servers), the standard configuration with high stability. Business data can be migrated between the different modes. As the number of AMRs increases, server nodes can be added to raise the processing capacity of the cluster, with support for one-click scale-out and scale-up. Even if a single server goes offline, a new server can be brought online to guarantee normal operation of the existing cluster. The database adopts a PG STOLON high-availability cluster (1 master plus 2 backups), and if the master fails a backup is promoted so that operations continue. This kind of redundant configuration guarantees “no stoppages” even in large-scale operation.

Visualization and analytics – dashboards and the digital twin

To keep improving the effectiveness of fleet control, “visualization” is essential. The RCS provides dashboards that record operating status and performance from multiple angles, together with data analysis charts that classify and analyze statistics. It visualizes statistics along dimensions such as equipment tasks, efficiency and alarms, so the state of the site can be grasped at a glance.

There are several kinds of dashboards – an analysis dashboard, an operations dashboard, a performance dashboard, a task execution dashboard and an alarm dashboard – and data can be explored in depth through device data analysis, performance data analysis, task data analysis, alarm data analysis and heat maps. Visualizing business data makes it possible to analyze and optimize task execution rates, anomalies, and the popularity and effectiveness of routes, so that questions such as “which routes tend to get congested” and “where do anomalies occur most often” can be answered quantitatively and turned into improvements.

In addition, a digital twin (Robo Mirror) reproduces the operating situation in 2D and 3D in real time. The 3D digital twin makes data easier to read, records equipment operation and maintenance data in real time, and analyzes all statistics with precision. By faithfully mirroring the movements of the physical site on screen, it becomes easy to grasp the situation remotely, trace the causes of abnormalities, and validate layout changes in advance. On the system monitoring side as well, multi-layer monitoring is provided at the host, middleware, process and network levels, so that all resource indicators can be grasped comprehensively, in real time and accurately through the cluster resource board, database cluster board, middleware resource board, network request board and others.

Benefits of adoption – optimized operation, labor savings, visualization and scalability

The benefits gained by adopting RCS-based fleet control can be organized broadly along four axes. Each of them relates directly to the challenges faced by manufacturing and logistics customers operating in Thailand.

• Optimized operation: by coordinating task assignment, path planning, traffic management and charging management across the whole fleet, interference, congestion and deadlock are suppressed and high utilization is maintained even with many units. This delivers operation in which adding units translates directly into higher efficiency.
• Labor and space savings: automating the transport of raw materials and finished goods reduces manual workload and headcount. In one actual case, more than 60 workers were reduced across the entire plant, more than 5,000 square meters of storage area was saved through the use of AMRs plus an automated high-bay warehouse, and the response time for feeding (compounding) was shortened by 15 minutes.
• Continuous improvement through visualization: dashboards and the digital twin allow the site to be measured quantitatively, bottlenecks to be identified, and improvements to be made continuously. Data-driven site management becomes possible, rather than relying on intuition and experience alone.
• Scalability: grouping multiple RCS instances and expanding the cluster allow the system to scale in stages as the business grows. It is possible to start small and grow large, keeping initial investment down while preserving room for future expansion.

These benefits cannot be obtained simply by buying robots. They are realized only when the system is adopted as a complete “mechanizm” that includes the RCS binding the fleet together, host system integration, visualization and maintenance. TOMAS TECH designs and builds this entire mechanizm to suit sites in Thailand.

Lightweight edition and ease of deployment – one-click installation and high-quality mapping

For needs such as “large-scale operation is attractive, but we want to start small” or “we want to run it easily on an industrial PC,” the answer is the lightweight edition of the scheduling system. The lightweight edition is application software with a C/S architecture, supporting one-click installation and rapid deployment. Its operating environment requirements are low and it is compatible with industrial control computers, so hardware deployment costs can be greatly reduced. All functions can be used with simple configuration, and its core scheduling functions are equivalent to those of the RCS scheduling system, with support for peripheral equipment integration as well.

Another element that supports ease of deployment is comprehensive mapping. Comprehensive guidance is provided for full-process mapping that fuses LSLAM and VSLAM, and professional prompts (on-screen guidance) throughout the process raise mapping quality. One-stop drawing and editing of topology maps based on the navigation map is supported, greatly improving both the quality and the speed of map editing.

Map quality is the foundation of fleet control; if it is inadequate, the accuracy of collision avoidance and path planning suffers. For this reason a post-mapping map verification function is provided: AMRs are scheduled automatically to carry out a map quality assessment and generate assessment results, so that the mapping work is reliably completed in a single pass. On the RCS-2000 side as well, MapStudio achieves automatic map stitching and alignment through data analysis algorithms and automatic comparison and fitting, and provides an online check function that quickly finds low-confidence areas and prompts the user to address them. Saving and restoring maps, and cross-map operation through association management between maps, are also supported.

Implementation process and lead time

In a standard deployment using forklift-type robots (FMR), the project proceeds in stages from contract and order placement through to full operation. Referring to Hikrobot’s standard schedule, the flow is broadly as follows (it may shift depending on site scale and the extent of customization).

• Contract signing / order placement: the starting point of the project. Requirements are finalized and the order is placed.
• Detailed engineering (about 1 month): includes blueprint creation, finalization of layout and design, and the project kick-off.
• Standard production period (about 2 months): includes material preparation, production and external procurement.
• Transport (about 2 months): includes movement from the factory in China to the port, sea freight, customs clearance and delivery to the local site. For destinations in Thailand, the transport legs are adjusted according to the delivery location.
• Implementation (about 1.5 to 2 months): includes hardware installation, AGV commissioning and system commissioning.
• Go-live and ramp-up period (about 1 month): production operation begins and utilization is ramped up. If additional customization is required, allow roughly 2 to 4 weeks.

Overall, roughly 7 to 8 months is a reasonable guide for a standard configuration. TOMAS TECH supports coordination, installation and start-up locally in Thailand at each of these phases, and keeps the project running smoothly through communication in Japanese and Thai.

Pre-deployment checks – servers, redundancy, WiFi and network requirements

For a fleet control system to run stably, it is important that infrastructure requirements are met before deployment. Here we summarize the main points to confirm and prepare in advance.

Servers, redundancy and power

A standard configuration requires 2 servers, a UPS and a server cabinet. The system servers are set up in a primary-backup configuration, with redundancy provided by hot standby software as required. To prepare for unexpected power failures, it is recommended to equip the server room with a UPS (uninterruptible power supply) to ensure normal server operation. Large-scale configurations adopt cluster mode (3 or more nodes) and eliminate single points of failure with a PG STOLON high-availability cluster (1 master plus 2 backups). Adding, removing and replacing server nodes is straightforward, requires no complex redeployment, and supports one-click scaling operations.

WiFi and wireless network requirements

Communication between the robots and the RCS is fundamentally wireless, so the quality of the wireless environment determines the stability of fleet control. As a guideline for installing wireless APs (access points), adjacent APs should use non-overlapping channels (1, 6 and 11) to avoid channel interference (AGVs scan only channels 1, 6 and 11). APs are best installed at a height of 3 meters with a recommended tilt angle of 7 to 9 degrees, covering a radius of 15 meters. Signal attenuation caused by physical barriers such as walls must also be taken into account. As for signal strength, it must be stronger than -65 dBm in AGV activity areas; the test criteria are -70 dBm or better, latency under 300 ms in a 1500-byte ping test, and uplink and downlink speeds of 4 Mbit or more. For a stable wireless environment, a dual AC (redundant) configuration is recommended, and adding a UPS should also be considered as a countermeasure against power failure.

Network and operating environment

In a private cloud configuration, data center servers require bandwidth of more than 1 Gbps for business control and data monitoring, and network latency of 100 ms or less must be secured for communication between the plant, the data center and workstations. Physical servers are x86 servers from leading international brands (Dell, Lenovo and the like), and supported operating systems include RedHat, Ubuntu, Oracle Linux and CentOS. Regarding the AGV operating environment, requirements include a flat indoor floor surface, ambient temperature of 0 to 45 degrees C, humidity of 15 to 95% (non-condensing), air free of dust and of flammable, explosive or corrosive gases, a 220 V (+/-10%), 50 Hz power supply, and consideration of electrostatic discharge from the floor. Tolerances for floor unevenness, gradients, steps and gaps (for example, steps of 5 mm or less and gap widths of 8 mm or less) should also be confirmed against the specifications. Each charging station requires a supply circuit of 2000 W or more (4000 W for some models).

Maintenance and support

A fleet control system is not finished once it is installed; maintenance and operation during ongoing service determine success or failure. Through its system monitoring functions, the RCS covers monitoring indicators across multiple layers – host, network, middleware and application software – providing the evidence needed for troubleshooting analysis and accurate problem localization. The database cluster board records operating parameters, enabling real-time fault alerts, accurate tracing of fault locations and rapid fault identification.

In day-to-day operational maintenance, a full set of functions is available for performing maintenance without stopping the site: blocking and unblocking areas, pausing and restoring areas, one-click return-to-base and power-off, timer-based start and stop, configuration of vehicle control areas, and AGV version management and OTA (over-the-air update). Machines in an abnormal state are automatically disabled so that no new assignments are made to them, and operations continue with the other robots. Software scale-out and scale-up can be performed in a matter of seconds, and adding, removing or replacing server nodes is straightforward. Single sign-on through an integrated portal, together with unified user management, permission management and role management, also lightens the administrative burden.

As an IT integrator based in Thailand, TOMAS TECH supports customers through these maintenance and operation phases as well. Rather than stopping at product supply, we place importance on establishing fleet control as a “mechanizm that can be used continuously,” covering local start-up support, coordination of host system integration, and tuning after operations begin.

Frequently asked questions (FAQ)

Q1. How many robots can the RCS control?

RCS-2000 has the path planning capacity to handle more than 1,200 AMRs on a single map, giving it powerful scheduling capability within a single project. Furthermore, by grouping multiple RCS instances it can support thousands of AMRs and fields of several million square meters. Expanding service resources breaks through the performance limits of a single server, so there is no theoretical upper bound. It is entirely possible to start small and expand in stages as the business grows.

Q2. Can it integrate with our existing WMS or ERP?

Yes. RCS-2000 integrates with host systems such as ERP, WMS, MES, OMS and MCS through standard interfaces. The standard interfaces cover task generation, task cancellation, return of execution results, state acquisition and manual intervention, and heterogeneous data from multiple sources can be integrated via iDataBus (the Hik interface platform). In practice, there are cases in which the system was seamlessly connected to the user’s WMS to achieve digital management of storage information, and cases in which multiple systems such as RCS-WCS-ERP-AS/RS were coordinated.

Q3. Can collisions and deadlock between robots really be prevented?

The RCS path planning algorithm plans optimal routes that minimize total travel cost, and at the same time manages the situation dynamically during task execution to predict congestion and prevent deadlock in advance. On the premise that there is no congestion, it provides several processing mechanizms including shortest-route provision, collision avoidance control and re-planning control. Traffic management additionally handles the order of passage at intersections, control of single-lane sections and the setting of maximum vehicle counts by vehicle type, keeping the flow of the whole fleet smooth.

Q4. Can equipment other than robots (conveyors, lifters and so on) be controlled together with them?

Yes. The WCS (device access service) integrates a wide range of equipment – lifters, robot arms, conveyors, wrapping machines, scanning gates, cameras, PTL, signal lights, fire alarms and more – using multiple protocols such as TCP, serial, UDP, REST, IO, SDK and OPC UA. It brings multiple protocols, multiple devices, multiple functions and multiple scenes under a single point of control, allowing an automated line in which robots and equipment cooperate to be built. VDA5050-compliant interfaces are also supported.

Q5. Can we start small and expand later?

Yes, you can. Deployment modes can be chosen from standalone mode for a small number of AMRs, quorum mode for 20 units or fewer, and the standard cluster mode, and business data can be migrated between the different modes. Switching from quorum mode to cluster mode is also supported. Server nodes can be expanded as the number of units increases, with support for one-click scaling operations. In addition, the lightweight edition of the scheduling system can be started easily with a one-click installation, and its core functions are equivalent to those of the RCS.

Q6. How long does implementation take?

For a standard FMR configuration, the process runs from contract and order placement through detailed engineering (about 1 month), production (about 2 months), transport (about 2 months), implementation (about 1.5 to 2 months) and go-live and ramp-up (about 1 month), for a guide figure of roughly 7 to 8 months overall. This may shift depending on site scale and the extent of customization. If additional customization is required, allow roughly 2 to 4 weeks. TOMAS TECH supports each phase locally in Thailand.

Q7. How do you guard against the risk of the system going down?

We guard against it with a redundant configuration. Servers are set up in a primary-backup configuration, and cluster mode adopts a PG STOLON high-availability cluster (1 master plus 2 backups); if the master fails, a backup is automatically promoted so that operations continue. A load-balanced configuration ensures that the crash of a single service does not affect overall operation, and a mechanizm is in place so that even if a single server goes offline, a new server can be brought in to maintain the existing cluster. A UPS is recommended as a countermeasure against power failure, and a dual AC configuration as a countermeasure against wireless faults.

Q8. Isn’t creating and updating maps difficult?

Map creation has been greatly simplified. Full-process mapping that fuses LSLAM and VSLAM comes with guidance and professional prompts that raise mapping quality. After mapping, AMRs are automatically scheduled to carry out a map quality assessment, so the work is reliably completed in a single pass. On the host side, MapStudio provides automatic stitching and alignment as well as online checking of low-confidence areas, and saving and restoring maps and cross-map operation are also supported.

Summary / Contact us

The value of introducing robots is determined not by the performance of a single unit but by the ability of the fleet to keep working without stopping. In multi-robot operation, four barriers – interference, congestion, deadlock and utilization – will always appear, and overcoming them requires a brain that binds the robots together, namely an RCS (Robot Control System). Hikrobot’s RCS-2000 systematically implements functions such as task assignment (TAS), multi-robot path planning, traffic management, charging management, World Model, device management (WCS), alarm management (AMS) and centralized management (CMS) on top of a three-layer architecture of business layer, management layer and execution layer, together with the iData series (iDataMeta / iDataView / iDataFlow / iDataBus). It covers standard integration with WMS/MES/ERP/OMS, large-scale expansion to thousands of robots and several million square meters, visualization through dashboards and the digital twin, and one-click deployment with the lightweight edition.

TOMAS TECH is an IT integrator that supports manufacturing and logistics customers in Thailand end to end – from design and construction through to maintenance – treating Hikrobot’s fleet management platform not as a standalone product but as a “fleet-control mechanizm that keeps the site running.” From phased adoption that starts small and grows large, to local coordination of host system integration and tuning after operations begin, we work alongside you at your site. If you are considering multi-robot operation of AMRs or forklift-type robots, or the adoption of fleet control and fleet management with an RCS, please get in touch. We will listen to the challenges and layout of your site and propose the optimal configuration. For inquiries, please feel free to contact us at https://tomastc.com/en/contact/.