The 2D-drone swarm, a safe open-source sample transfer system for fully automated laboratories

Abstract

Laboratory automation is an active field in biology, drug discovery, and more recently in synthetic chemistry and materials science. Local automation has existed in the field for quite some time, but long-range or total laboratory automation is much less developed. In this article, we present a complete, open and decentralized global automation system called the 2D drone swarm system. It is based on a simple approach of small mobile robots moving autonomously in a dedicated track suspended above the scientific equipment for the long-distance sample and closely connected to localized robotic arms dedicated to short-distance transfers, interaction with scientific equipment and direct sample processing. This approach is inspired by the Kiva/Amazon model, where isolated autonomous mobile robots automatically deliver goods to external operators. It is also inspired by the modern automotive industry, such as Tesla's Gigafactories, to provide an evolutionary and flexible system that can adapt to numerous types of tasks with a minimum amount of resources and easily adapt to different types of workstations. This global automation system is controlled directly from the Laboratory Scheduler by a Robot Subscheduler, coded in an open-source environment, which takes care of all mobile and local robot operations. The result is an operator and scientific equipment safe, cost and energy-efficient, easily extensible and open-source global laboratory automation system that can be adapted to many different applications and laboratories.

---

1. Introduction

Laboratory automation, after years of development in biology and drug discovery, is now a very active area in chemistry and materials science,^1,2 with several approaches already described in the literature. According to Thurow and Fleischer,³ laboratory automation systems can be described by two criteria. The first one is open vs. closed and determines if the automation system is structured around a fixed number of workstations (sampling tools, mixing tools, measuring devices…) connected to a dedicated connection element (robot, conveyor, fluidic system) corresponding to a closed configuration or if the number of workstations can be easily increased without having to significantly reconfigure the system. The latter case corresponds to an open automation system. The second criterion is centralized vs. decentralized. This criterion is related to the fact that the connection element is either localized, i.e. fixed or moving in a predefined space (centralized configuration) or, in contrast, free to move and generate new trajectories and spaces according to new needs (decentralized configuration). Thus, the two authors define four possible combinations that represent different laboratory automation systems, which they schematize as shown in Fig. 1.

Fig. 1 Adapted from Thurow and Fleischer.³ The four possible combinations of the open vs. closed and centralized vs. decentralized criteria allow the different laboratory automation systems to be described. (a) Representation of a closed and centralized automation system (CCAS), where a fixed number of workstations (WS#) are directly interconnected through a localized connection element (CE), (b) representation of an open and centralized automation system (OCAS), where a variable number of workstations are interconnected through a localized connection element. (c) Representation of a closed and decentralized automation system (CDAS) where a mobile link is used to connect a defined number of workstations. (d) Representation of an open and distributed automation system (ODAS) where a mobile link is used to interconnect an open number of workstations.

The first combination is the closed and centralized automation system (CCAS, Fig. 1a). An example would be two workstations, a liquid handling station (WS1) used to prepare calibration solutions directly connected to an analyzer (WS2, e.g. HPLC, UV reader…) with a stationary arm serving as a connecting element (CE, e.g. SCARA arm) to transfer the plates. All commercially available automated analytical tools with internal autosamplers and analyzers (e.g. DAD, MS, FID, UV/VIS, NMR,…) should also be considered as the CCAS. The second combination is the open and centralized automation system (OCAS, Fig. 1b). There are several remarkable examples of such automation systems in the literature, such as the robotic platform for flow synthesis of organic compounds⁴ or the Chemputer.⁵ Commercial preparative stations (e.g. Chemspeed, Unchained Lab,…) or pipetting stations (e.g. Agilent Bravo, Hamilton, Opentrons,…) can be assigned to one of these first two categories, depending on their configuration and ease of workflow configuration. As previously described, these first two automation systems are localized and cannot be extended out of their defined space to expand their chemical capabilities, for example to include an autonomous solid sampling station connected to a large library of molecules, or to introduce complex analytical tools such as high-field NMR spectrometers or X-ray. To increase the overall ability to automate different types of workstations in the laboratory, it is necessary to turn to a distributed automation system.^6,7 The first decentralized system is the closed and decentralized system (CDAS). This corresponds to several localized automated systems, either CCAS or OCAS, interconnected with a rigid conveyor (e.g. Chemspeed Flexshuttle) or autonomous guided vehicles (AGV). As explained by Thurow and Fleischer,³ in such a CDAS: “… the process to be performed is predetermined and can only be changed by reprogramming the entire system. Thus, the system is considered a closed system. The integration of additional components is only possible with a considerable amount of time and money”.

1.1. The open and decentralized laboratory automation systems

An open and decentralized automation system (ODAS) must overcome these limitations and provide the ability to easily reprogram processes and workflows, and should allow the integration of completely new capabilities with a limited amount of money and time.

In order to extend the spatial domain of operation, an ODAS must certainly consist of a combination of mobile robots with stationary ones, possibly connected to a linear axis. Thurow and Junginger⁸ describe three possible scenarios for the use of mobile robots in laboratory automation:

Scenario 1 – mobile robot as a transport system, where simple mobile platforms without on-board manipulation are used to move samples between robotized stations. In this scenario, the transfer between the mobile platforms and the scientific equipment is performed by stationary robot arms fixed on the stations, where stationary indicates the arm's base remains fixed relative to its immediate platform or environment.

Scenario 2 – mobile robot as a transport system with a transfer function, where, in a full automation vision, mobile platforms are combined with an on-board stationary robot arm (6-axis, SCARA) and appropriate sensors to transfer the samples to and from the scientific equipment or storage stations. (e.g. Biosero-Omron,⁹ KMR iiwa Kuka, Augsburg, Germany)

Scenario 3 – mobile robot as a transport system with a transfer and manipulation function, where mobile platforms are combined with one or more on-board stationary robot arms (6-axis, SCARA) and adequate sensors. These components allow the samples to be transferred to and from the scientific equipment or storage stations, but also to take over some processing of the samples (e.g. Wolf et al. mobile manipulator MOMA,^6,10 Cooper et al. in 2020 as the Robot Chemist¹¹ which is a KMR iiwa Kuka robot with extended processing function).

The authors mention a number of limitations for the different strategies mentioned above. For scenarios 2 & 3, one of the problems is related to the limited universality of the gripping tools, which ultimately forces the use of gripper changers, which are not necessarily easy to set up on a mobile station and also create complex programming of the robot. The use of multiple arms could also be considered to improve the versatility of such a MOMA.¹² The authors also explain that the alignment of the mobile platforms and the robotic arms with respect to the scientific equipment stations can be complex, requiring more complex sensors and programming. They question the feasibility of such solutions in automated life science laboratories. We could also question several other points of the above strategies. For all of them, we should consider the significant footprint of these mobile platforms in the laboratory, especially when we consider that at least some level of redundancy is required for continuity of operations (battery charging time, troubleshooting) and task parallelization. In addition, even if we aim for full automation of the laboratory, human operators will certainly be needed for maintenance and recovery from automation crashes. The mobile platform will therefore have to deal with unpredictable humans with a significant risk of collision. Finally, for scenarios 2 & 3, we can question the ability to parallelize, because the more time each mobile station spends on local transfer tasks and sample processing, the less time it will have available for long-distance transfer operations. In scenario 3, the issue is even more critical, and task parallelization could quickly be limited by the available number of MOMA robots, and possibly by the available area on which to move them. With respect to the above limitation list, it appears that scenario 1 is the one presenting the smallest number of limitations. The question, then, is whether we can envision an ODAS based on scenario 1, that is highly parallelizable while maintaining the flexibility to perform complex tasks, that does not constrain the laboratory design by its footprint, that maximizes the safety of people, the ease of alignment with equipment, and that can operate robustly around the clock at a limited cost.

1.2. The automotive and warehouse robotics

To answer this question, we first looked at already highly automated areas such as the automotive industry and logistics warehouses to understand current robotics strategies and developments. Regarding the automotive industry,¹³ we see a recent evolution from the typically closed and decentralized automation system (CDAS, Fig. 1c) in traditional industry to a more open and decentralized approach (ODAS, Fig. 1d). Traditional CDAS organization can be described as stations with highly specialized robots dedicated to unitary tasks (parts handling, welding, automated assembly, painting,…), eventually combined with static dedicated tools,¹⁴ fed by humans or automated robotic transporters that bring parts to the station from the warehouse.¹⁵ These automated transporters include Automated Guided Vehicles, AGVs, which follow predefined paths, or Autonomous Mobile Robots, AMRs, which navigate freely in dynamic environments using onboard sensing. The stations are organized along a main transfer tool that moves the car under construction from the first to the last station of a fully defined sequence. The transfer tool can be a conveyor or an AGV, using either painted lines on the floor or beacons. The evolution towards ODAS for the automotive industry was initiated by TESLA with the Gigafactories.^16–18 These plants are organized around robot arms equipped with tool changers and advanced capabilities, enabling them to perform a wide range of operations on the same car and also transfer the car between stations. Thus, long-reach stationary robots (i.e., arms with fixed bases but extended reach) are used to handle transfers over a few meters, manage local logistics and perform various complex tasks. The fact that the robots are stationary could orientate on an Open Centralized Automation Systems (OCAS, Fig. 1b), but considering the range of operation of these robots and also the ease of system reconfiguration using a large number of possible tools to adapt the robots to different tasks, we think it is fair to consider it as a specific type of ODAS.

If we look at the logistics warehouse industry, it handles a broad range of load units and packaging types, from large pallets to small individual items. These differences often dictate which handling and transport systems are most suitable. We also see an evolution towards the ODAS approach, which can be adapted in different ways depending on the material format. In the beginning, it was mostly humans walking through long aisles of goods to pick and collect the desired items. Then came an approach using conveyors with static humans to finally move to the more recent strategy used in companies like Amazon with the Kiva robotic system.^19,20 The Kiva system is based on an ensemble or swarm of Autonomous Semi-Guided Vehicles (ASGVs)²¹ that transport the required samples (shopping carts) to human operators or localized static robots that assemble the customer packages. Semi-guided vehicles follow predefined routes using simple infrastructure cues (e.g., floor QR codes or magnetic tape), offering more flexibility than traditional fixed-path AGVs but less autonomy than fully fledged AMRs. In practice, the KIVA ASGVs use QR codes printed on the floor and an embedded camera combined with a collision detector to crisscross the floor in a dedicated, human-free space which enables flow separation (a clear division between humans and mobile robots operating in different areas). A similar system at Walmart allowed the number of picks by operators to be increased from 200–400 h⁻¹, for the conveyor strategy, to up to 600–700 h⁻¹.

To summarize the last generation of ODAS observed in the automotive and logistic-warehouse industries, we can identify three interesting strategies that will help us to achieve our objectives as defined above: (1) stationary robots able to perform different complex tasks and also take over transfers, (2) a swarm of simple autonomous mobile robots dedicated only to transfer adequate samples over long distances and (3) a spatial separation between humans and mobile robots.

2. The 2D-drone swarm system

By combining the three strategies described above, i.e., scenario 1 for mobile robots in a laboratory, the Amazon/Kiva flow separation, and local robot arms with varied or advanced tools similar to those employed in the automotive industry, we have developed a new open-source ODAS for the laboratory called the 2D drone swarm system. The herein proposed system shares certain similarities with the commercially available Formulatrix Rover (https://formulatrix.com/lab-automation/rover-autonomous-plate-handler). However, it also differs in several key aspects, including its open-sourced nature. Notably, it fully integrates and enables the use of multiple connecting robots, a feature made possible by our open-source GLAS orchestration system.²² This system is particularly well-suited for very heterogeneous laboratory environments. These aspects will be discussed in greater detail in the following section.

It is composed of an ensemble (swarm) of small mobile robots controlled by a central intelligence and placed in a track on top of the scientific equipment (Fig. 2a), thus providing a flow separation between the ground floor dedicated to humans and scientific equipment, and the first floor dedicated to sample transfer. This system forms the Long-Range part of the combined Connection Element (LR-CE, dark gray in Fig. 2c). The flow separation is represented by the dotted line in Fig. 2c and is similar to that in the Amazon/Kiva system. The scientific equipment is grouped into clusters to form stations (Fig. 2b) where the drones can stop to drop or load samples using a localized multi-tasking connecting arm robot. The arm robots are interconnected to the drone swarm system and together form the global connecting element of the automated laboratory (CE, in gray in Fig. 2c). The arms are the Short-Range part of this global Connecting Element (SR-CE, light gray in Fig. 2c). To ensure smooth operation and perfect mutual alignment, the LR-CE and SR-CE are controlled by the same central intelligence called the Robot Subscheduler (Fig. 4, in gray). The connecting robot arms are used for local and medium-range transfers with the addition of a linear axis and, thanks to gripper changers, they are also used to perform processing tasks (PT#) on samples (e.g. pipetting, dilution) or on scientific equipment (e.g. loading samples). This is similar to what we described earlier from the evolution of the automotive industry. Fig. 2c shows the organization of this new ODAS, using the same schematic structure derived from Thurow and Fleischer³ in Fig. 1.

Fig. 2 Schematic description of the ODAS 2D drone swarm for laboratory automation, global connectivity element for the automated laboratory (CE, in gray in 2c). In (a) we present a CAD view of the actual Swiss Cat+ laboratory with the 2D drone swarm track (long-range link LR-CE, in dark gray in 2c) visible above the equipment and with the 6-axis collaborative robots (Cobots) used as short-range links (SR-CE#, in light gray in 2c) to the different instruments (e.g. LC, NMR). In (b) an image of a station with a mobile robot on the plexi/aluminum track. The red glare comes from the light source of the industrial camera used for fine alignment of the 6-axis cobot (Universal Robot, UR5e) with respect to the mobile robot (locally developed). The 6-axis arm is used to connect both the visible plate labeler (Agilent PlateLoc, bottom right) and our self-developed robotic workstation for automatic sample distribution for optical spectroscopy and NMR. In (c), the schematic description of this ODAS based on Fig. 1, in the center we find the 2D drones dedicated to long-range sample transfer (LR-CE, in dark gray), the dashed line around them symbolizes the flow separation between the mobile robots (first floor) on the one hand and the scientific equipment level on the other hand, operated either by the short-range collaborative connection elements (SR-CE, in light gray) or potentially by operators. The localized collaborative robotic arms (Cobot), coupled with industrial cameras for precise localization of the mobile robots and equipped with gripper changers, form the base of the stations. These robotic arms are also capable, thanks to gripper changers, of performing a wide variety of processing tasks (PT#) as well as loading/unloading samples directly into scientific instruments. This is facilitated by the fixed relative positioning between the arm and the instrument. They can also be connected to additional logistics tools, such as SCARA Cobots and linear axes, to extend the range of operations and connect to more workstations (WS#).

As illustrated in Fig. 3a through Fig. 3c, the stations may be of disparate types and may combine disparate tools for local logistics and processing task functions. However, they must at a minimum consist of a Cobot and a camera for precise alignment of the cobot gripper with the sample carried by the mobile robots. In this concept, as in the Amazon/KIVA logistics system described above, the mobile robots are of the ASGV type.²³ In particular, at Swiss Cat+, we have developed a dedicated swarm of small autonomous semi-guided vehicles (ASGVs), approximately 20 cm in diameter and 2 kg in weight (Fig. 3d). These vehicles are hereafter referred to as “drones.” Long-range trajectories are controlled by distributed Aruco codes, as described by Figueiredo et al.²¹ (see Progressive precision model below). At the station, high precision is required for loading and unloading the samples. For this purpose, industrial cameras positioned on the station read the Datamatrix code^24,25 affixed to the drones, allowing the Robot-Subscheduler (see the Scheduling section below) to confirm the identity of the drone and associate it with all operations, and to define the drone's positioning (x, y and yaw) with submillimeter precision in order to adjust the fine movements of the six-axis Cobots. A separate publication will provide more detailed technical information about the drones and their control.

Fig. 3 (a) This is an illustration of the analytical and liquid sample preparation station, which is equipped with a six-axis Universal Robot UR3 Cobot (depicted in the upper right of the image) for the transfer of samples from the drones to the vertical storage tower. From the storage tower, a SCARA KX-2 1000 mounted on a 2.5-meter linear axis serves all the scientific equipment, including an Agilent Intuvo GC-MS equipped with PAL automation, two Agilent Bravo liquid handling stations, a microcentrifuge, a PlateLoc, and a Plate Labeler. (b) A front view of the same stations as in Fig. 2b. Here, a 6-axis UR5e is used to connect the track to an Agilent PlateLoc and to a locally developed ensemble of valves used to collect the flows from an Agilent 1290 preparative LC and distribute the samples directly to a Bruker Invenio FT-IR spectrometer, an Agilent Cary 60 UV-VIS spectrometer, and fill and seal 1. 7 mm NMR rack tubes and SBS sample plates are prepared for injection into the Agilent SFC-IM-Q-TOF (6560C). This second locally developed station, derived from an Agilent RapidFire, provides internal sample transfer via microfluidics or a SCARA Precise Automation PF3400 robotic arm. (c) A development done with Techvolver.²⁷ The apparatus is designed to be integrated with a UR5e robot, enabling the use of manual pipettes. It is currently employed for direct sample processing and to enhance the flexibility of the stations. (d and e) Depiction of a real image and a CAD representation, respectively, of the drones utilized within the track for long-distance transfers. The drones are equipped with a wide-angle camera, which is used for locating the distributed Aruco codes. Additionally, a Datamatrix code^22,23 is employed in conjunction with the industrial cameras to inform the system of the drone's identity and its precise alignment with respect to the 6-axis cobot and the SBS format sample plate.²⁸

Each drone is controlled by a dedicated Trajectory Controller (TC) implemented in the ROS2 framework²⁶ (Fig. 5). The task assignment to each ASGV is performed by the Fleet Manager (ROS2 framework) according to the high-level tasks received in cascade from the Laboratory Scheduler and the intermediate-level tasks received from the Robot Subscheduler.

2.1. Adaptive precision positioning model

The 2D drone swarm sample transfer system is based on an adaptive precision positioning model, which is described in detail below. The objective of this model is to provide an adequate level of precision at each stage of the operation, ensuring the safety of the scientific equipment, while limiting the necessary data processing and transmission, and allowing for partial optimization of the trajectories. As previously described, the ASGVs are guided for long trajectories with a precision in the centimeter range. This is achieved through the use of a combination of wide-angle cameras mounted on the robot and equipped with OpenCV and Aruco codes distributed in the laboratory space. This approach is described in detail by Figueiredo et al.²¹ (Fig. 4a below). The Aruco codes are fixed points, in accordance with the principle of automated guided vehicles (AGV model), but can be detected in a large field of view due to the 120° opening of the wide-angle camera, contingent on the relative distance between the camera and the Aruco codes. For precise measurement, camera calibration was performed to correct lens distortions and misalignments. Each camera was calibrated using OpenCV's standard chessboard-based method (https://docs.opencv.org/4.x/dc/dbb/tutorial_py_calibration.html), and during operation the detected marker corners were rectified with the resulting intrinsic and distortion parameters before pose estimation. The camera (black dot in Fig. 4a) is mounted on the top of the drone and is oriented towards the ceiling. The Aruco codes are mounted on the top of the circuit at approximately 50 cm, with the code facing the drones. This configuration yields a detection diameter of approximately 50 cm, which is consistent with the width of the track. This allows the drones to navigate with sufficient freedom to achieve smooth and partially optimized trajectories (Automated Semi-Guided Vehicles model, ASGV). All calculations and trajectory definitions are based on the drone's collected data and WiFi or 5G transferred information, which is then processed on a centralized computer (see Scheduling and trajectory management below).

Fig. 4 (a) Depiction of the long-range trajectory control, wherein the trajectory (dashed black line) and the target station (black dot) are circumscribed by the centimeter uncertainty zone (slashed gray). During the long-range transfer, the drones are permitted to move freely based on the trajectory control information received from the Robot-Subscheduler, which is informed by the localization information extracted from the Aruco codes distributed along the circuit with the wide-angle camera mounted on the drone in combination with odometry and IMU through an extended Kalman filter. (b) The operational control at the station. The industrial camera mounted on the track is capable of identifying the Datamatrix code printed on the drone with sub-millimeter precision (in the x, y, and yaw rotation angle) within the centimeter precision domain targeted by the drone. In order to achieve this, it is necessary for the field of view of the industrial camera to be sufficiently large to encompass the entire long-range trajectory uncertainty domain of the drone. Subsequently, the sub-millimeter drone position information is conveyed to the fixed six-axis arm cobot, which is utilized for the loading and unloading of samples. The same six-axis arm cobot is utilized to operate the scientific instrumentation with a high degree of safety, due to its fixed reference point and nominal submillimeter accuracy.

The sampling rate of the camera to capture Aruco code positions is 5 Hz. The dynamic trajectory is then controlled by a combination of absolute position information provided by the previously described Aruco system, wheel odometry, and a drone-mounted IMU through an Extended Kalman Filter (EKF).^29,30 The accuracy of the dynamic positioning is contingent upon the positioning system and several mechanical aspects, including the wheel friction factor, motor and gear types and precision, and the track material and geometry. The Swiss Cat+ system is capable of achieving a dynamic positioning accuracy of 2 centimeters in the x and y dimensions when a visual location (Aruco) is available and can reach a maximum error of up to 6 centimeters in between visual locations (located every approximately 50 centimeters), as indicated by the slashed gray zone in Fig. 4. The average x, y, and yaw positioning uncertainties are summarized below. For clarity, both the corresponding standard deviations (in meters or radians) and their variances (in m² or rad²) are reported. The maximum values are primarily caused by an initial peak during the Kalman filter initialization; after convergence, the uncertainty stabilizes at around 6 cm in the x and y directions and approximately 0.06 rad in yaw.

	Std. Dev. x (m)	Variance x (m^2)	Std. Dev. y (m)	Variance y (m^2)	Std. Dev. yaw (rad)	Variance yaw (rad^2)
Minimum	0.019	0.00036	0.019	0.00036	0.019	0.00036
Maximum	0.088	0.00775	0.078	0.00608	0.078	0.00613
Average	0.044	0.00195	0.043	0.00181	0.043	0.00182

This value ensures a smooth and uninterrupted trajectory, thereby facilitating secure and reliable drone navigation within the designated track. It also allows for safe and efficient crossings between different sections of the track and enables precise positioning within the industrial camera zone at the target.

Upon reaching the target station with the previously described centimeter accuracy (as indicated by the circle in Fig. 4b), the drone enters the field of view (FOV) of an industrial camera (Basler ACE 2 R a2A1920-51gcPRO with Fujinon HF8XA-5M) mounted above the track at an average height of 46 cm, corresponding to 34 cm above the Datamatrix codes. The camera mounting height is defined to provide a sufficient field of view (FOV) to encompass the entire long-range trajectory uncertainty domain (FOV = 14 cm in the case of Swiss Cat+), thus ensuring systematic capture of the Datamatrix mounted on the drone at the station. The industrial cameras are equipped with commercial image recognition software (http://www.cognex.com), which is used to identify and read the Datamatrix code printed on the top of the drones on the side of the sample plate (Fig. 3d and e). Upon confirmation by the Robot-Subscheduler that the drone has reached the target station, a single image is captured, significantly reducing the amount of data transmitted. The combination of the industrial camera and the image recognition software provides the sample position (as an offset text file transmitted via TCP-IP) to the Universal Robot 6-axis cobot controller with an average precision of 3.6 px in x and y.²⁵ Under the Swiss Cat+ experimental conditions (Fig. 4b), the x accuracy was 0.3 mm, the y accuracy was 0.4 mm, and the yaw rotation angle was 1.63°. This level of accuracy is consistent with the nominal accuracy of the UR 6-axis Cobots (pose repeatability according to ISO 9283: ±0.03 mm³¹).Most of the instruments have at least 2 mm of compliance, the cumulated 0.7 mm of errors is in range to allow the SBS sample plates to be loaded and unloaded on the drones with minimal risk of failure. Once the drone loading and unloading operations have been completed as previously described, the precision of operations on the scientific instrument is directly defined by the 6-axis Cobot nominal accuracy due to the arm's location in a fixed reference with preprogrammed and optimized motions. This approach ensures the safest level of operation for the scientific equipment, thereby eliminating any risk of misalignment. Moreover, this approach is advantageous for human operators as it is straightforward to secure the Cobot with light curtains or other zone-defining devices. This strategy allows for the data transfer rate to be limited, as the Cobot motions are locally encoded into the Cobot controller and only need to be called by the Robot-Subscheduler.

2.2. Drone vibrations

The drones and the tracks have been meticulously engineered to minimize vibration levels, with the objective of averting the inadvertent spillage of samples and the concomitant safety concerns. The primary design elements encompass the incorporation of high-quality wheels and driver motors, along with the implementation of smooth plexiglass in the circuit's rolling area. It is important to note that the initial iterations of the drones were equipped with omnidirectional wheels that were responsible for significant vibrations. The design of the drones has undergone modification to incorporate the use of smoother wheels. The level of mechanical vibrations was analyzed through the utilization of the internal IMU during sample transfers. However, it was not possible to discern vibration signals that were clearly distinguishable from background noise when the system was in a stationary state. Additionally, the drone's accelerations were adapted to prevent liquid mass transfers. The phenomenon of liquid oscillation was monitored visually, yet no substantial effects were discerned. Furthermore, it is imperative to acknowledge that in our laboratory, all samples are transferred in closed containers with the objective of averting solvent evaporation and curtailing the risk of spillage and cross-contamination. A subsequent study will be conducted with higher-sensitivity accelerometers to compare the impact of different rolling area materials, wheel structures, and driver motors.

2.3. Scheduling and trajectory management

To guarantee the seamless integration of the drones, cameras, connecting arms, and grippers, and thus the optimal functioning of the global Connecting Element (CE), the scheduling architecture must be centralized and synchronized for the entire system. First, open protocols such as SiLA 2 (https://sila-standard.com/standards/) and LADS OPC-UA (https://opcfoundation.org/markets-collaboration/lads/) were considered; however, although promising, these standards were not yet sufficiently mature and lacked driver support for several key instruments in our laboratory, while some implementations (e.g., for Universal Robots) required paid licenses. A multilayered Git-based scheduling architecture (GLAS)²² has been developed to facilitate the coordination of operations at various levels, open to interoperability with open protocols. This architecture, described in Fig. 5, enables the integration of tasks from the Main Laboratory Scheduler, which oversees high-level operations, down to the drone trajectory controllers coded in the ROS environment and associated with the drones.

Fig. 5 Adapted from Cousty et al.,²² a general schematic description of the GLAS-based global orchestration and scheduling architecture of the Swiss Cat+ West Hub laboratory. The Level 2 Robot Sub-Scheduler, which is responsible for controlling the 2D drone swarm system on a larger scale, is represented by a red, dotted, and rounded rectangle. The Level 2 Robot Sub-Scheduler receives orders from the Level 1 Main Laboratory Scheduler (REST API) and oversees the operations of the Fleet Manager. The latter is responsible for identifying and transferring tasks to the most appropriate drones based on proximity and availability. Subsequently, the trajectory control is dynamically regulated by the ROS2 trajectory controller, which is based on the adaptive precision positioning model described above. The ensemble of 6-axis cobots (Universal Robot, piloted through RTDE API) and Scara PAA KX2 cobots (dedicated API) as well as the 400 MHz NMR spectrometer (Bruker NEO 400, API co-developed with Bruker Switzerland) are also controlled directly by the level 2 Robot Sub-Scheduler to ensure a seamless interaction between the drones and the cobot used for operations.

The Main Laboratory Scheduler (REST API in the Swiss Cat+ West Hub infrastructure) receives a high-level operational workflow in the format of a JSON file from a dedicated Human Computer Interface (HCI) that will be presented in a subsequent publication or from an automated generator such as ChemCrow.³² The workflow is transformed into an intermediate-level set of tasks, which are distributed to the appropriate ensemble of equipment. Each workflow instance is assigned to the relevant equipment upon arrival and executed sequentially according to a first-in–first-out (FIFO) principle, while multiple workflow instances can proceed in parallel provided they do not interfere with one another. In the context of robotic operations, all tasks pertaining to robots, including those involving drones, 6-axis robots, and SCARA robots, are forwarded to the level 2 Robot Sub-Scheduler (Fig. 5). The level 2 Robot Sub-Scheduler divides the intermediate-level tasks into detailed, pre-encoded sequences, which are then routed to the appropriate robots. It is important to note, however, that while the present work relies on such pre-encoded sequences for reliability, the architecture has been conceived with modularity in mind and could be extended in future to interface with intermediate task description languages (e.g., XML/JSON or domain-specific workflows), thereby supporting scalability and adaptation to new equipment. The tasks pertaining to the 6-axis arms and SCARA cobots, in addition to those associated with the 400 MHz spectrometer (Bruker NEO 400), are conveyed directly to dedicated application programming interfaces (APIs) for operational control. The tasks dedicated to the drones are conveyed to the level 3 Fleet Manager, which automatically assigns each task to the nearest available drone and transmits the detailed task to the dedicated Trajectory Controller (ROS2 framework). Subsequently, the Trajectory Controller directs the drone to the designated point, taking into account the avoidance of collisions with other drones, and notifies the Robot Sub-Scheduler via the Fleet Manager upon the completion of the task. The aforementioned cascade of tasks is illustrated in Fig. 6 through the example of a request for a high-performance liquid chromatography (HPLC) analysis of samples prepared in synthesis station A.

Fig. 6 An example-based step description for the complete robotic scheduling of the 2D drone swarm system as existing at Swiss Cat+ EPFL. The example is a series of high-performance liquid chromatography (HPLC) analyses to be performed on samples prepared in station A. The high-level workflow is programmed by the chemist in the laboratory ELN or automatically generated by a generative algorithm, and then passed to the Laboratory Scheduler. The Laboratory Scheduler breaks down the high-level task into more detailed mid-level tasks that are sent to either the Agilent Subscheduler (OpenLab CDS) or the Robot Subscheduler (gray). The Robot Subscheduler, in turn, converts the mid-level tasks it receives into lower-level tasks and distributes them selectively to the arms and to the Fleet Manager (FM), which assigns the best drone position and transfers the task to its Trajectory Controller (TC). The operations of the machines (HPLC, Universal Robot UR, drones) are controlled according to the tasks by their respective API/TC.

2.4. Application example

This section presents a detailed account of the practical application of the 2D drone swarm system in the Swiss Cat+ West Hub laboratory. This example illustrates the transfer of samples from the automated NMR rack tube sample preparator, designated as OmniFire,²² to the 400 MHz NMR spectrometer. The complete scheduling of the procedure is ensured at the level of the main Laboratory Scheduler. Subsequently, all operations pertaining to robots (fixed 6-axis Universal Robots UR5e and drones), with the exception of the Brooks Precise Automation integrated into the OmniFire, which is piloted by the level-3 OmniFire Sub-Scheduler, are overseen by the level-2 Robot Sub-Scheduler. The corresponding workflow is depicted in Fig. 7.

Fig. 7 High-level workflow of the 2D drone swarm system operations corresponding to the transfer of NMR tube racks from the filling station to the high-resolution NMR spectrometer autosampler (Bruker SampleJet).

Fig. 8 depicts the various stages of the workflow described in Fig. 7, presented as images. The complete movie of the same sequence is available in the SI.

Fig. 8 Depiction of the various stages of the high-level workflow of the 2D drone swarm system operations. These stages pertain to the transfer of NMR tube racks from the filling station to the high-resolution NMR spectrometer autosampler (Bruker SampleJet), as illustrated in Fig. 7. In Steps 2 and 5.1, the operation of industrial cameras with red-light LEDs is observed. These cameras are used to capture the precise position of the drone and to inform the 6-axis UR5e of the necessary loading (Step 2) or unloading (Step 5.1) of the NMR rack for transfer from and to the drone. In Step 4, the top-mounted Aruco code utilized by the drone-mounted camera is observed, which enables the camera to orient itself during long-range transfers. The complete video of the same sequence is available as the SI.

3. Discussion

Our goal in developing this ODAS was, as mentioned above, (1) to follow Thurow and Junginger's⁸ scenario 1, where the mobile robots only perform sample transfer and are not equipped with arms, (2) to optimize the safety of the human operators and the efficiency of the mobile robots by separating the flow, as in the Kiva/Amazon system, and (3) to enrich the functions of the static connecting robots to increase the number of possible functions per station and thus reduce the number of required stations, as has been done recently in the automotive industry (Tesla Gigafactories). In addition to reaching these three goals, the 2D drone swarm system presents several specific advantages.

The first is to be cost-effective and easily scalable. In fact, the system is mostly open sourced (Arduino, Raspberry Pi, Open CV for video processing, ROS2 for drone control). The drones are locally 3D printed, and the track is made only of easily accessible materials (aluminum profiles and Plexiglas© plates). The cost of each drone is about 500 EUR and the whole track, for our 27 m long x 7 m large lab, is about 20 kEUR. If we consider the price of the robotic arms (about 15 to 25 kEUR, depending on the size and gripper used), the total cost for our system of 6 stations is in the range of 150 kEUR (similar to the price of a MoMA single mobile station with a robotic arm on it). Each new station would only cost the price of an additional robot arm and the time needed to reconfigure the mapping of the stations within the Robot Subscheduler. For comparison, in terms of scalability, a MoMA and our system have different trade-offs. MoMA scalability is constrained by the system's large footprint, which makes deploying multiple units impractical in smaller laboratories. However, MoMAs can scale more effectively in large facilities or when multiple distant laboratories need to be connected, where their mobility provides a clear advantage. By contrast, our system scales through modularity: increasing the number of small drones or adding extra arms at selected stations allows throughput to grow almost linearly with the number of added units, making the approach particularly well suited for medium-sized laboratories where space and cost efficiency are critical. In addition, if one of the drones fails, it can be easily removed from the circuit, replaced, and repaired by local personnel, as compared to a MoMA system which would need a specialized technician, and block the system in a small lab with only a few systems. UR robots are also easily programmed locally thanks to their user-friendly development environment and large availability of adaptable tools, grippers and open-source libraries.

Beyond cost and scalability, a second advantage of our system is its ability to be optimized. Since the number of drones can easily be increased, the long-distance transfers can easily be parallelized and continuously feed all stations without bottlenecks. Thus, the stations are optimally fed and can all run in parallel, depending essentially on the processing time at each station. This last point could also be optimized by using dynamic scheduling, as is common in industry (e.g. SyntQ by Optimal, https://optimal-tech.co.uk/), to improve the overall uptime in the lab. A third advantage, related to scenario 1 as described above, is the ease and safety of six-axis robotic operations with respect to complex and expensive scientific equipment. The fact that these robotic arms are static makes them easy to align with an accuracy of less than a millimeter, without the risk of relative position changes. In addition, the static positioning of the arm robots allows them to be surrounded and equipped with a wide variety of tools, greatly expanding their operational capabilities (e.g. at the Swiss Cat+ West Hub, one of the 6-axis UR5e robots is equipped with two different grippers, an automated screw tool, a Techvolver single pipette, and a vacuum pump).

A fourth advantage that we can mention here is the robustness of the operation, which is achieved thanks to the massive, low-cost redundancy of the drones. This makes the system resilient in terms of battery charging time of the drones and also in case of failure of a single drone. This is possible because of the open-source concept of the drones, but also because the drones are kept as simple as possible. They mainly consist of sensors (wide-angle camera, IMU), motors, microcontrollers and batteries. All the intelligence is delocalized in a central static lab server (the Robot Subscheduler), thus reducing the financial cost and energy consumption of each drone. This, in turn, helps to minimize the size of the required battery and keep it lightweight and energy efficient. Finally, it makes the system easily expendable by decoupling the management of long-distance transfers by the Fleet Manager and the Trajectory Controller from the management of local transfers thanks to cobots. Each station is a point on the map of the trajectory controller and in principle does not require any physical adaptation of the track. The local station can be fully adapted to the specific needs of the scientific equipment involved.

As briefly mentioned in Section 3, it is worth discussing the existing commercial solutions for automated laboratory logistics. The most relevant in this stage is the Formulatrix Rover (https://formulatrix.com/lab-automation/rover-autonomous-plate-handler), which is an industrial ODAS system composed of mobile robots, a centralized fleet-management system, and an overhead, ceiling-mounted track with lifts that allows mobile robots to move between stations equipped with plate storage. Each robot also includes an onboard transfer function based on a small linear actuator, enabling plate transfer to compatible storages and instruments. While this solution presents similarities to the herein described system, it is effective for laboratories that already operate with highly standardized, automation-ready or at least automation-adapted instruments. Our approach introduces several unique advantages. First, our system is open-source, lowering barriers for adoption and enabling customization by academic and industrial users alike. Second, it is designed to be modular and easily deployable in diverse laboratory environments without requiring specialized infrastructure such as static lifts, thereby reducing the overall system complexity. Third and most important, rather than focusing solely on plate transport, our platform integrates both mobile robots and robotic arms within a unified Robot Scheduler. This broader robotics ecosystem enables not only sample transfer but also direct manipulation of instruments and handling of complex tasks, including those involving instruments that are not inherently automation-ready. We have also noted that, although the Formulatrix Rover includes an on-board transfer function that is suitable for simple plate movements, it still requires integration with additional robotic arms to operate more complex instruments. Finally, we emphasize that our software architecture allows for flexible scheduling across heterogeneous non-necessarily automation-ready systems, which can even incorporate the Formulatrix Rover itself if desired.

On the side of limitations, we must first mention that a problem can occur if a drone has a failure, and even though such events are relatively rare, it can limit access to a station. To mitigate this, our system already incorporates basic failure-detection mechanisms, such as monitoring the continuity of ROS 2 communication and checking consistency between commanded motions and the drone's reported localization. Detected failures are also reported to the Robot Sub-Scheduler and the Fleet Manager so that the fleet can adapt. Additionally, we are working on a rescue robot that will automatically remove the blocking drone and plan to extend failure detection with onboard health monitoring in future work. In addition, an operator can manually resolve such issues via the Robot Scheduler interface when the rescue robot is not available or not implemented. A second point that needs to be clarified is the high level of robotics, IT and programming skills that are not necessarily available in standard labs to develop the complete planning chain for such a fully automated lab. But this is a general problem for all automated labs, and younger scientists are largely trained in coding. Also, more and more useful pieces of code are available either through GitHubs or can be generated through chatbots such as ChatGPT. We will soon make all our scheduling codes available via a free GitHub that will be announced with the next more technical release. Finally, developing such a completely integrated automation requires ideally a significant planification work. It can be added to an existing laboratory but will definitely benefit from an initial analysis and conception.

The reason for using a fixed industrial camera mounted on the track for precise positioning during sample loading and unloading, instead of reusing the wide-angle camera mounted on the drone, which would limit equipment and development needs, is the ability to establish a stable transform matrix between the industrial camera and the robot arm base coordinate system. With our software, this calibration can even be automated, making it repeatable and less error-prone. If we had used the onboard camera, we would have needed to localize fixed ArUco markers placed in the workspace and then precisely measure their distance and orientation relative to the robot base. This procedure is more cumbersome, reducing calibration stability. In addition, the fixed camera is directly connected via Ethernet and RJ45 cabling to the local network, which ensures industrial-grade communication with the robot arms. In contrast, the onboard camera communicates over Wi-Fi, which is more prone to packet loss and disconnections, reducing reliability for this crucial step. Finally, the fixed camera benefits from controlled lighting conditions, ensuring consistent and reliable vision detection. The onboard camera, however, is exposed to varying ambient lighting and reflections from the environment, which can compromise detection robustness and increase false measurements, especially critical in the final positioning phase where millimetric precision is expected.

4. Conclusion

We present here a new generation of open decentralized automation systems for laboratories based on a swarm of drones, stabilized in a dedicated ceiling-suspended track and used only for long range sample transportation, intimately connected thanks to a global task scheduling architecture with connecting robotic arms equipped with tool changers and multiple types of grippers. This concept, named a 2D drone swarm system, allows for safe, cost and energy effective, open-sourced, easily extendable laboratory sample transfer, handling and processing.

Author contributions

Conceptualization: E. M, Y. C, T. C, J-C. C, J. H, P. M. Funding acquisition: P. M. Investigation: E. M, Y. C, Y. E. G, J. T, T. C, J-C. C. Methodology: E. M, Y. C, J-C. C, V. S, J. H, P. M. Project administration: E. M, J-C. C, P. M. Resources: E. M, J. H, P. M. Software: J-C. C, Y. E. G, Y. C, J. T, T. C, E. M. Supervision: J-C. C, E. M, P. M. Validation: J-C. C, E. M, P. M. Visualization: J-C. C, Y. C, J. T, E. M, P. M. Writing (original draft): E. M, J-C. C, Y. C, J. T, P. M. Writing (review and editing): E. M, J-C. C, J. T, J. H, P. M.

Conflicts of interest

There are no conflicts of interest to declare.

Data availability

The data and code supporting the findings of this study, including robot control software, scheduling scripts, and system schematics for the 2D drone swarm laboratory automation system, are available via the EPFL Swiss Cat+ GitHub repository with the following URL and Zenodo DOI: https://github.com/swisscatplus/EM_onrobot – DOI: https://doi.org/10.5281/zenodo.17243582, https://github.com/swisscatplus/EM_pathplanning – DOI: https://doi.org/10.5281/zenodo.17243592, https://github.com/swisscatplus/EM_fleetmanager – DOI: https://doi.org/10.5281/zenodo.17243632, https://github.com/swisscatplus/EM_server – DOI: https://doi.org/10.5281/zenodo.17243681.

No human participant data were collected or used in this study. Supplementary information: SI videos referenced in the article and all references listed above in Data availability. See DOI: https://doi.org/10.1039/d5dd00342c.

Acknowledgements

The authors acknowledge the ETH Domain for its support through the Forschungsinfrastrukturen Program. Furthermore, the authors would like to extend their gratitude to the EPFL, SB, and ISIC administrations for their assistance. The text has been reviewed using the Deepl Pro language analysis tool.

References

1. M. Abolhasani and E. Kumacheva, The Rise of Self-Driving Labs in Chemical and Materials Sciences, Nat. Synth., 2023, 2, 483–492,  DOI:10.1038/s44160-022-00231-0.
2. P. Miéville and F. de. Nanteuil, Modern Automation in Organic Synthesis Laboratories. in Reference Module in Chemistry, Molecular Sciences and Chemical Engineering, Elsevier, 2024,  DOI:10.1016/B978-0-323-96025-0.00047-8.
3. H. Fleischer and K. Thurow, Automation Solutions for Analytical Measurements: Concepts and Applications, John Wiley & Sons, 2017.
4. C. W. Coley, D. A. Thomas, J. A. M. Lummiss, J. N. Jaworski, C. P. Breen, V. Schultz, T. Hart, J. S. Fishman, L. Rogers, H. Gao, R. W. Hicklin, P. P. Plehiers, J. Byington, J. S. Piotti, W. H. Green, A. J. Hart, T. F. Jamison and K. F. Jensen, A Robotic Platform for Flow Synthesis of Organic Compounds Informed by AI Planning, Science, 2019, 365(6453), eaax1566,  DOI:10.1126/science.aax1566.
5. P. S. Gromski, J. M. Granda and L. Cronin, Universal Chemical Synthesis and Discovery with ‘The Chemputer.’, Trends Chem., 2020, 2(1), 4–12,  DOI:10.1016/j.trechm.2019.07.004.
6. Á. Wolf and K. Széll, A Review on Robotics in Life Science Automation, 2019.
7. Á. Wolf, D. Wolton, J. Trapl, J. Janda, S. Romeder-Finger, T. Gatternig, J.-B. Farcet, P. Galambos and K. Széll, Towards Robotic Laboratory Automation Plug & Play: The “LAPP” Framework, SLAS Technol., 2022, 27(1), 18–25,  DOI:10.1016/j.slast.2021.11.003.
8. K. Thurow and S. Junginger, Devices and Systems for Laboratory Automation, 1st edn, Wiley, 2022,  DOI:10.1002/9783527829446.
9. Can robots speed up drug discovery? San Diego firm’s software helps labs embrace automation. San Diego Union-Tribune, https://www.sandiegouniontribune.com/business/story/2021-06-11/at-the-intersection-of-software-and-life-sciences-biosero-helps-research-labs-with-robotic-automate-drug-discovery accessed 2024-03-19.
10. Á. Wolf, P. Galambos and K. Széll, Device Integration Concepts in Laboratory Automation. in 2020 IEEE 24th International Conference on Intelligent Engineering Systems (INES), 2020, pp. 171–178,  DOI:10.1109/INES49302.2020.9147171.
11. B. Burger, P. M. Maffettone, V. V. Gusev, C. M. Aitchison, Y. Bai, X. Wang, X. Li, B. M. Alston, B. Li, R. Clowes, N. Rankin, B. Harris, R. S. Sprick and A. I. Cooper, A Mobile Robotic Chemist, Nature, 2020, 583(7815), 237–241,  DOI:10.1038/s41586-020-2442-2.
12. H. Fleischer, D. Baumann, X. Chu, T. Roddelkopf, M. Klos and K. Thurow, Integration of Electronic Pipettes into a Dual-Arm Robotic System for Automated Analytical Measurement Processes Behaviors. in 2018 IEEE 14th International Conference on Automation Science and Engineering (CASE), IEEE, Munich, Germany, 2018; pp. pp. 22–27,  DOI:10.1109/COASE.2018.8560377.
13. M. Bartoš, V. Bulej, M. Bohušík, J. Stanček, V. Ivanov and P. Macek, An Overview of Robot Applications in Automotive Industry, Transp. Res. Proc, 2021, 55, 837–844,  DOI:10.1016/j.trpro.2021.07.052.
14. A. S. Michels, T. C. Lopes, C. G. S. Sikora and L. Magatão, The Robotic Assembly Line Design (RALD) Problem: Model and Case Studies with Practical Extensions, Comput. Ind. Eng., 2018, 120, 320–333,  DOI:10.1016/j.cie.2018.04.010.
15. D. Andronas, A. Argyrou, K. Fourtakas, P. Paraskevopoulos and S. Makris, Design of Human Robot Collaboration Workstations – Two Automotive Case Studies, Procedia Manuf., 2020, 52, 283–288,  DOI:10.1016/j.promfg.2020.11.047.
16. How Tesla Used Robotics to Survive, https://roboticstomorrow.com/article/2022/06/2022-top-article-how-tesla-used-robotics-to-survive-production-hell-and-became-the-worlds-most-advanced-car-manufacturer/18908 accessed 2024-03-19.
17. Tesla shows new “Godzilla” robot and in-depth look at latest electric car production line | Electrek, https://electrek.co/2023/02/13/tesla-godzilla-robot-in-depth-look-latest-electric-car-production-line/accessed 2024-03-19.
18. Meet “Iceman” and “Wolverine” - the two coolest robots in Tesla's factory, Business Insider, https://www.businessinsider.in/meet-iceman-and-wolverine-the-two-coolest-robots-in-teslas-factory/articleshow/49149310.cms accessed 2024-03-19.
19. R. Bogue, Growth in E-Commerce Boosts Innovation in the Warehouse Robot Market, Ind. Rob., 2016, 43(6), 583–587,  DOI:10.1108/IR-07-2016-0194.
20. M. Marks, Robots in Space: Sharing the Sidewalk with Autonomous Delivery Vehicles, Rochester, NY, 2019,  DOI:10.2139/ssrn.3347466.
21. F. A. V. Figueiredo, E. G. C. Pereira and C. M. A. Vasques Indoor Navigation of an Autonomous Guided Vehicle Using ArUco Markers. in Multidimensional Sustainability: Transitions and Convergences, ed, F. L. Almeida, J. C. Morais and J. D. Santos, Springer Nature Switzerland, Cham, 2023, pp. 309–329,  DOI:10.1007/978-3-031-24892-4_20.
22. J.-C. Cousty, T. Cavagna, A. Schmidt, E. Mariano, K. Villat, F. de Nanteuil and P. Miéville, GLAS: An Open-Source Easily Expandable Git-Based Scheduling Architecture for Integral Lab Automation, Digital Discovery, 2024, 3, 2434–2447,  10.1039/D4DD00253A.
23. K. Thomas Wilson, Automated Guided Vehicles for Material Flow in Fulfillment Centers, PhD Thesis, Massachusetts Institute of Technology, 2023, https://dspace.mit.edu/handle/1721.1/151444.
24. I.-C. Dita, M. Otesteanu and F. Quint, Data Matrix Code—A Reliable Optical Identification of Microelectronic Components. in 2011 IEEE 17th International Symposium for Design and Technology in Electronic Packaging (SIITME), 2011, pp. 39–44,  DOI:10.1109/SIITME.2011.6102683.
25. W. Huang, A. Maomin and Z. Sun, Design and Recognition of Two-Dimensional Code for Mobile Robot Positioning, in Intelligent Robotics and Applications. ICIRA 2019, ed. H. Yu, J. Liu, L. Liu, Z. Ju, Y. Liu and D. Zhou, Lecture Notes in Computer Science, Springer, Cham, 2019, vol. 11743,  DOI:10.1007/978-3-030-27538-9_57.
26. M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger, R. Wheeler and A. Ng, ROS: An Open-Source Robot Operating System.
27. Techvolver - Automated Pipette Calibration, Techvolver.com, https://techvolver.com/accessed 2024-03-19.
28. https://www.slas.org/SLAS/assets/File/public/standards/ANSI_SLAS_4-2004_WellPositions.pdf, https://www.slas.org/SLAS/assets/File/public/standards/ANSI_SLAS_4-2004_WellPositions.pdfaccessed 2024-09-12.
29. O. A. Stepanov, Kalman Filtering: Past and Present. An Outlook from Russia. (On the Occasion of the 80th Birthday of Rudolf Emil Kalman), Gyroscopy Navig., 2011, 2(2), 99–110,  DOI:10.1134/S2075108711020076.
30. A. I. Mourikis and S. I. Roumeliotis, A Multi-State Constraint Kalman Filter for Vision-Aided Inertial Navigation. in Proceedings 2007 IEEE International Conference on Robotics and Automation, IEEE, Rome, Italy, 2007, pp. 3565–3572,  DOI:10.1109/ROBOT.2007.364024.
31. Ur5e-Rgb-Fact-Sheet-Landscape-A4.Pdf, https://www.universal-robots.com/media/1807465/ur5e-rgb-fact-sheet-landscape-a4.pdfaccessed 2024-09-12.
32. A. M. Bran, S. Cox, O. Schilter, C. Baldassari, A. D. White, P. Schwaller, ChemCrow: Augmenting Large-Language Models with Chemistry Tools, arXiv, 2023, preprint, arXiv:2304.05376,  DOI:10.48550/arXiv.2304.05376.

---