Automated Drone Battery Management System—Droneport: Technical Overview

Abstract

The popularity of using vertical take-off and landing unmanned aerial systems continues to rise. Although the use of these devices seems to be almost limitless, the main drawback is still the battery capacity and the need to replace or recharge it several times per hour. This article provides a technical overview of the development of an experimental mechatronic system for automatic drone battery management called Droneport. It was developed as a system with a landing platform, automatic battery exchange and recharging outside the drone, allowing a quick return to the mission. The first part presents its mechanical design, installed instrumentation and software environment. The next part is devoted to the description of the individual hardware components, highlighting the specific problems that had to be solved to optimize size, weight and robustness requirements. The final section summarizes our observations regarding the contribution of this tool to the autonomy of drones or UAVs in general.

1. Introduction

Drone technology has become inexpensive and accessible as a result of the continuous evolution and development observed over the last two decades. Numerous application domains emerged, ranging from aerial photography and disaster management over precision agriculture, shipping and delivery and mining to wildlife monitoring, law enforcement or military operations [1,2,3,4,5].

The cheap operational time of unmanned multi-copter drones becomes a significant advantage when compared to conventional aerial vehicles. On the other hand, the maximum flight duration in the order of tens of minutes might be the most limiting factor in many applications. This limitation comes from the maximum capacity of lithium-based batteries supplying power for most electrically-propelled drones. Unlike ground vehicles, the maximum flight range cannot be scaled simply by installing larger batteries since a maximum take-off weight and power consumption limits must also be considered [6,7,8,9]. While increasing the power density of the power source can potentially bring some performance improvements, novel battery technologies are still far from widespread commercial adoption [10,11,12].

Manual battery replacement by humans to keep the drone operational is generally not suitable while pursuing the ultimate goal of autonomous operation and cost-effective deployment. Therefore, there were many attempts to automate the recharging process without the necessity of human intervention [13,14,15,16]. Nevertheless, the long waiting time that leaves the drone grounded poses a significant drawback of this approach. Tethering the drone with a power station has been proposed as an alternative [17,18]. However, the physical connection of the drone with the ground is infeasible for many applications due to the inherent consequences for take-off weight and flight range.

Introducing an automatic station allowing battery replacement seems to be a more convenient option. Several experimental systems were reported in the literature [19,20,21,22,23]. Few commercial solutions have already been introduced to the market [24,25,26,27,28], mostly intended for a particular drone type. The emerging technology dealing with storing, deploying and recharging the drone using a single container is commonly designated as drone-in-a-box. The goal is to improve the aerial vehicle’s autonomy and safety while simplifying its utilisation. Automatic battery swapping or charging becomes an essential feature of such systems.

The paper deals with our proposed system, called Droneport (DP), which is designed to operate various drone types with Vertical Take-Off and Landing (VTOL) ability. The main functionality it brings is an automatic process of rapid battery swapping and charging, allowing fast return of the drone to its mission. The DP is equipped with a battery management system dealing with battery storage, identification and health evaluation. Unlike the above-mentioned commercial systems, DP is developed as an open-source solution, with a published source code for the traffic controller, MAVLink API description, etc. A link to the project repository is provided in the Appendix A.

Droneport was already introduced in our previous publications  [29,30], where the software and simulation tools were described in detail. The process of prototyping was described in [31]. The current paper extends the former results. It expands on hardware and software development details and provides a previously unpublished overview of the Droneport control system. The paper is organized as follows. Section 2 introduces the mechanical design of the Droneport, describing a robotic manipulator responsible for battery swapping. Section 3 deals with the description of HW and SW components of the system, focusing mainly on custom-designed gripper. Section 4 describes a real-time software environment used to implement the control system. Section 5 reveals the algorithmic and implementation details of the developed control system. This part constitutes the main contribution with respect to the previously reported results. Concluding remarks are given in Section 6.

2. Mechanical Concept and Design

The main goal was to develop a drone battery swapping system fulfilling a few fundamental objectives:

• automatic battery charging and swapping without any human intervention;
• extension of the UAV operational time from minutes to hours;
• simple communication protcol based on MAVLink standard;
• compact construction and easy handling;
• reasonable purchasing/maintenance cost.

These objectives led us to the Droneport architecture, which was designed as a landing platform covering the charging station and a special robotic manipulator arm for the necessary contact with the landed drone, see Figure 1. The following subsections describe the conceptual details.

2.1. Droneport Mechanics

Droneport employs a special robotic manipulator with a parallelogram structure, which is responsible for automatic battery swapping. The parallel manipulator structure is able to reduce the number of actuators, minimise the amount of moving inertial mass and provide the required manipulation workspace. This results in compact design providing easy handling. The robot links-length were optimized using a min-max discrete optimization algorithm, described in [32]. The goal was to derive optimal manipulator arm lengths with respect to demands on force/torque and acceleration limits in a given workspace. The manipulator consist of three distinctive mechanical subsystems:

• Planar moving base—the H-bot structure helps to reduce the moving mass by fixing the actuators to the machine support and connecting them to the manipulator via tooth belt, see [33] and Figure 2.
• Parallelogram structured arm—a lightweight planar linkage with a parallel structure, driven by a stepper motor with worm wheel gear in its base, detailed in Figure 3.
• Battery gripper—a gripper designed to securely attach and detach the battery, transport the battery from and to the charger slots and ensure the connections checks. Section 3.2.1 describes the gripper in detail.

The chosen kinematic structure allows to achieve a favourable reach to weight ratio. The manipulator arm is able to fold itself to the Droneport box as well as reach the battery of the landed drone, as depicted in Figure 4.

2.2. Droneport Kinematics and Workspace

Kinematics of the manipulator can be described as the relation between joint space coordinates ${[{\alpha }_1\left(t\right),{\alpha }_2\left(t\right),\phi \left(t\right),\theta \left(t\right)]}^{\mathrm{T}}$ and workspace coordinates ${[x\left(t\right),y\left(t\right),z\left(t\right),\psi \left(t\right)]}^{\mathrm{T}}$ in the form

$$[\begin{array}{c}\begin{array}{c}x\left(t\right)\\ y\left(t\right)\\ z\left(t\right)\\ \psi \left(t\right)\end{array}]=[\begin{array}{c}\frac{r}{2}({\alpha }_1\left(t\right)+{\alpha }_2\left(t\right))\\ \frac{r}{2}(-{\alpha }_1\left(t\right)+{\alpha }_2\left(t\right))+p_2-p_{1}sin\left(\phi \left(t\right)\right)\\ -p_3+p_{1}cos\left(\phi \left(t\right)\right)\\ k\theta \left(t\right)\end{array}],\end{array}$$

(1)

where r is a radius of the belt pulleys in the H-bot base, k is a gear ratio between orientation of gripper $\psi$ and its actuator $\theta$, and $p_1,p_2,p_3$ are parameters of manipulator as depicted in Figure 3. For the tilt angle $\phi \left(t\right)$ from range (−100°, 100°), there exist two solutions converging to one in the upright position. The Jacobian matrix $J\left(Q\right)$ defines the relation between joint coordinates and end effector coordinates in the form

$$\dot{X}\left(t\right)=J\left(Q\right)\dot{Q}\left(t\right),$$

(2)

more precisely

$$\begin{array}{c}\left[\begin{array}{c}\dot{x}\left(t\right)\\ \dot{y}\left(t\right)\\ \dot{z}\left(t\right)\\ \dot{\psi }\left(t\right)\end{array}\right]=\left[\begin{array}{cccc}\frac{r}{2}& \frac{r}{2}& 0& 0\\ -\frac{r}{2}& \frac{r}{2}& -p_{1}cos\left(\phi \left(t\right)\right)& 0\\ 0& 0& -p_{1}sin\left(\phi \left(t\right)\right)& 0\\ 0& 0& 0& k\end{array}\right]\left[\begin{array}{c}{\dot{\alpha }}_1\left(t\right)\\ {\dot{\alpha }}_2\left(t\right)\\ \dot{\phi }\left(t\right)\\ \dot{\theta }\left(t\right)\end{array}\right].\end{array}$$

(3)

The resulting singularity in the upright position of the manipulator parallel arm has to be overcome via motion in joint space. The robot workspace can be described in an x-z plane as a polygon with boundaries which are given by reach limits and structure collisions. This polygon is relevant at each shift in the y-axis and all $\psi$ orientations. Thus, the manipulator is able to move above the drone such that the battery gripper is still parallel to the landing platform, and can be turned to align with the drone battery holder.

The Jacobian from Equations (2) and (3) also defines the relation between the velocities of joints and the end effector, respectively,

$${\dot{\delta }}_X=J\left(Q\right){\dot{\delta }}_Q.$$

(4)

The impact of the worm wheel backlash has to be evaluated in order to validate achievable positioning accuracy. As shown in [31], the end effector position error varies along the tilt angle and the maximum position error is about 6 mm on each degree of backlash.

The backlash was found to be the main factor influencing the manipulator’s accuracy because the belt tension, bearings clearance and material rigidity are negligible in comparison to the gear clearance. These findings led us to the addition of capabilities to measure and control the contact force vector. This is achieved by changing the actual position of the gripper jaws with respect to battery holder alignment pins, see Section 5 devoted to Droneport control for more details.

3. Hardware Parts Specification and Functional Properties

3.1. Main Computer, Peripherals and Power Management

The DP consists of several modules, which are orchestrated using an UpBoard UP Xtreme computer with an Intel Core i3 processor. The computer is interconnected with the following components, depicted in Figure 5:

• Power supply, protection and distribution—230 V AC input, 24/12 V DC outputs,
• manipulator drives via CANopen communication,
• gripper via serial line communication over USB,
• gripper camera via USB communication,
• battery charger via serial line communication over USB,
• additional DI/DO via real-time EtherCAT gateway,
• Droneport interface via MAVLink communication protocol over Ethernet using UDP packets.

3.2. Battery Transportation and Gripping

Nowadays, batteries and their connections to drones have no standardization. Each company has its own system of connections, battery placing, etc. Most systems are not suitable for precise and secure gripping of the battery by the robot arm. Moreover, the connections of high-current connectors are intricate to push or pull, even for human operators. Therefore, a unified system for the battery case and holder reconnecting is developed and examined in the following subsection.

3.2.1. Battery Case and Holder

The goal was to design a special case for a standard Li−Po battery, which the automatic swapping system can easily replace. The XT-60 connector is commonly used for standard size batteries. It is reliable and capable of high currents. Unfortunately, it is challenging to connect and reconnect this connector manually, let alone automate this process with a robot. Therefore, designing a unique battery case and holder for a standard Li-Po battery was a necessary step.

The drone battery encapsulated in a unified case is assumed to be placed on top of the drone body to make it easily reachable by the robot arm. The case contains the battery slot, the two pin-hole centring system, two levers for gripping and two types of connections. The spring pin connector is intended for monitoring the cells and other diagnostic purposes. Conductive plates serve for high power distribution. These two conductive lines and spring pin connector fit securely to a custom design battery holder with a conductive complement in the form of 2 × 30 pins spring connector. Disconnection is provided via mentioned levers driven by gripper jaws. The only horizontal force is needed to disconnect the electrical connection. It also releases the battery case from the holder, which is then free to be pulled up from the alignment pins. A couple of springs in the battery case realize the necessary contact force for high power distribution during flight. Figure 6 shows the battery case and holder, including some safety features such as polarity control, short circuit protection due to improper handling, etc. An ArUco code as a unique ID of the holder is used for drone/battery recognition and visual targeting. This setup has been tested for a 60 Amp continuous current, see Figure 7, Figure 8 and Figure 9, which covers some testing results.

3.2.2. Gripper

A gripper was developed as a complementary part of the battery holder. It consists of several components depicted in Figure 10. The linear guide rollers of the gripper jaws are controlled by a RC servo. A built-in microcomputer in the form of an Arduino micro manages the servo commands and deals with the limit switches for detecting the current position of the jaws and established contact with the battery holder. A range finder and a web camera are intended for targeting the ArUco marker and searching and estimation of the battery holder position with respect to the manipulator. A custom control block that performs the gripper operations was also designed, see Figure 11.

4. Software Environment

The main computer uses Debian-based Linux OS with real-time kernel capabilities. The REXYGEN software developed and maintained by REX Controls company [34] was chosen as a real-time control system for the whole application.

The system includes a development environment supporting a graphical function block language without the need to write code manually. This is close to the workflow of Mathworks’ Matlab-Simulink or the industrial PLCOpen IEC 61131-3 standard. An extensive library of ready-to-use functional blocks is available. Their functionalities range from the most basic logic operators, amplifiers or timers to advanced blocks used for signal processing or feedback control. If needed, the user can also write a custom function block using RexLang, a scripting programming language similar to C. High-level programming via Python is also possible.

The system allows managing the whole control application with the capability to divide it into different tasks with various priority levels and sampling times. A real-time scheduler then assigns the CPU time accordingly to achieve the correct functionality of the whole application while meeting the timing deadlines of the individual tasks.

REXYGEN development studio can be used on a regular PC or laptop, where the algorithms can be compiled. Once running, either on a PC or connected to the target hardware, the control process can be watched in real time. It is also possible to check the calculation speed of the individual algorithms in the system. Connection to the target software can be made via a local network or the Internet. REXYGEN supports a wide range of communication protocols such as CAN/CANopen, Ethernet, EtherCAT, Modbus, Profinet and others. MAVLink protocol is also supported and beneficially used in this project.

The system also offers tools for creating human-machine interfaces which can run on a PC, tablet or smartphone. The interface is then embedded with the project and copied to the target control hardware.

The advantage of REXYGEN is its affordability and a wide range of supported target platforms. More detailed specifications can be found on the website: https://www.rexygen.com (accessed on 27 March 2023).

The Linux-based operation system with real-time Linux kernel patch allows precise planning of periodic functions. However, for control tasks, one needs an application that can benefit from these functions. The REXYGEN system was chosen because our team can easily influence development. The REXYGEN allows us to separate control to several tasks which are run in real-time. Additionally, the DP contains several HW components (see Figure 5) with various communications protocols (RS232, EtherCAT, HTTP, MAVLink, etc.); thus, we needed the bridge between them.

5. Droneport Control

The control system is developed using function block diagrams language in the REXYGEN software. It is divided into several real-time tasks, which run with different sampling periods. In parallel, there is a standalone application for image processing from the gripper camera written in Python and OpenCV. The data connection between the standalone application and the main control algorithm is established via UDP packets over MAVLink protocol. For example, the wrapper of the MAVLink interface for image processing app communication is shown in Figure 12.

The REXYGEN is used for the real-time task, but it lacks the support of image processing; thus standalone application for ArUco detection was developed. There was a need for data exchange. Since the MAVLink over UDP is widely used for commanding the drone and it supports message specification for vision messages, it was decided to use this means of data exchange. Moreover, Python is suitable for fast software prototyping, so this stand-alone module is based on it.

The following subsections contain the description of the control structure with respect to schematics diagrams, control blocks and subsystems, and the technology of commands and control.

The control system is divided into two main parts. The first one is responsible for the control of low-level functions such as manipulator movements, communication with the charger, control of the landing platform, etc. The second part is a high-level controller named Event/path manager, which is used for orchestrating all the actions together with error handling, see Figure 13 for details.

5.1. Low Level Control/Motion Control

Control of robot axes is based on PLCopen Motion control standard [35]. The Motion Control Manager (MCM) contains functional blocks representing all the robot Axes, called $R{M}_{axes}$. These blocks keep all status values and implement a basic algorithm controlling the state of one motion control axis (physically one drive), which includes limits checking, emergency stop, etc. MCM is responsible for generating the appropriate reference motion trajectories to the drive with a defined sampling period, respecting the axis limits, etc. The axes coupling to coordinated motion is based on the computation of the inverse kinematics (Equation (5)), which is implemented in block IK4F. The velocity reference for each motion axis is generated by this block according to the current state

$$\begin{array}{c}\left[\begin{array}{c}{v}_{r{\alpha }_1}\left(t\right)\\ v_{r{\alpha }_2}\left(t\right)\\ \dot{\phi }\left(t\right)\\ \dot{\theta }\left(t\right)\end{array}\right]=\left[\begin{array}{c}\dot{x}\left(t\right)-\dot{y}\left(t\right)+\dot{z}\left(t\right)\frac{cos\left(\phi \right(t\left)\right)}{sin\left(\phi \right(t\left)\right)}\\ \dot{x}\left(t\right)+\dot{y}\left(t\right)-\dot{z}\left(t\right)\frac{cos\left(\phi \right(t\left)\right)}{sin\left(\phi \right(t\left)\right)}\\ -\frac{\dot{z}\left(t\right)}{p_{1}sin\left(\phi \left(t\right)\right)}\\ \frac{\dot{\psi }}{k}\end{array}\right],\end{array}$$

(5)

keeping in mind the singularity that should be avoided.

Above that, a feedback control scheme in the extended cascade structure is created, as depicted in Figure 13. This cascade contains the position controller, which is commanded by the position generator with anti-windup switching. The switching is performed according to the demands on actual motion behaviour. This means the ability to switch between the motion to the target $TG{T}_{SW}$, motion according to the down-force and/or side-force commands or their combinations. These references are produced by a couple of force controllers $C_{SF},C_{DF}$ and via high-level commands. These commands come from a high-level controller, which orchestrates the motion generator according to the actual demands on motion, contact forces, HMI, etc. The force control algorithm can be designed using the method proposed in [36].

5.2. High Level Control—Path/Event Manager

The whole Droneport system consists of several discrete components which must be orchestrated together. As shown in Figure 5, several subsystems are connected via various communication busses. In addition, the communication process between drone and Droneport must be taken into account. Therefore, the simple closed-loop control is unsuitable for such a task. We have to use event-based distributed closed-loop control. REXYGEN system does not implement distributed control based on the IEC61499 norm, but several blocks can be used for such types of control algorithms. The finite-state automaton (ATMT) is a typical example. This block interprets a sequential function chart (SFC) with states and transitions and is widely used for event-based sequence programming. Another special block can parse the .JSON configuration file (PJSOCT) and interpret the simple Python script. By combining the .JSON configuration, sequential function graphs, and close loop control, one can achieve a suitable event-based controller. The high-level hierarchy is described in the following sections.

5.3. Schematic Diagrams of Main Control Blocks

This section contains the control scheme of all main compute/control modules or blocks which are responsible for the functionality of the whole system.

High-level control consists of several discrete actions that can be done in series or in parallel. These actions cover the positioning of the landing platform, positioning of the manipulator, the management of the battery holders and charger state, etc. One can imagine this high-level control as an oriented graph. Each node represents a set of parameters for multiple low-level tasks. The node also contains each task’s start and end conditions. Selected nodes can be interconnected to a chain named path. The parameters for the nodes and the description of paths are stored in one .JSON file.

As shown in Figure 14, when the controller is started, the .JSON configuration file is loaded to the Program subsystem. This subsystem loads selected path from the paths .JSON object, and when started, it provides the first node dataset to the ATMT_node block (see Figure 15). The ATMT_node block checks the input conditions for the given node and initiates the node_START pulse. This pulse is transferred to each action subsystem. The action can be waiting for a defined time, manipulator movement, closing or opening the gripper, etc. Each node can have multiple actions which are done in parallel. Each action is represented by a subsystem named Node_ as a prefix, e.g., Node_wait, Node_aruco, Node_gripper, etc.

Each action/node subsystem has a common interface and ATMT block. When node_START pulse is activated, each action node checks if the call is valid for the given action. After that, the whole program/path/node waits until all the parallel actions end with a done flag or with an error flag. If an error occurs, the action is stopped at the current state, path fails, and an error handling algorithm has to be called. If all actions are executed, the ATMT_node receives the next node from the current path and the executing process is called again. This continues until all nodes from the selected path are accomplished. The program can combine multiple paths into the sequence (path of paths) to cover some high-level operations.

5.4. Battery Replacement Process

Path/event manager nodes are listed here and described to better understanding the battery replacement motion control process. A typical drone battery transport looks as follows:

(1)

drone lands on the platform

(2)

cover is opened

(a)

$Node\_cover$ is executed

(3)

manipulator moves above the drone

(a)

sequence of multiple nodes $Node\_target$ are executed in serial

(4)

manipulator performs the ArUco searching process to localize the drone battery case

(a)

$Node\_aruco$ search is executed

(5)

manipulator performs a contact approach to the battery

(a)

Gripper is open via node $Node\_gripper$

(b)

Approach is done via $Node\_target$

Force control is performed via $Node\_side\_force$ and $Node\_down\_force$

(6)

battery is pulled out from the battery slot

(a)

Gripper is closed via node $Node\_gripper$

Force control for precise horizontal positioning is turned on via $Node\_side\_force$

(b)

Motion above the actual position done via $Node\_up\_level$

Force control for smooth pulling motion is done via $Node\_side\_force$

(7)

battery is transferred above empty charging slot

(a)

sequence of multiple nodes $Node\_target$ are executed in serial

(8)

battery is placed to the charging slot

(a)

$Node\_target$ is performed with known parameters of slot position

$Node\_side\_force$ and $Node\_down\_force$ are turned on for precise leveling

(b)

Gripper is open via node $Node\_gripper$ to place the battery

(c)

$Node\_up\_level$ is performed to move safely back above the charging slot

$Node\_side\_force$ remains turned on for precise leveling

5.5. Node Examples

5.5.1. Node Wait

For example, the subsystem for processing the simple Wait (one parameter t_sec—for how long should this node wait) node is depicted in Figure 16. Each node subsystem has a similar interface. There is an ATMT block for SFC processing, a special subsystem for parsing nodes parameters and a standardized input/output interface. Whenever the node is executed, the ATMT block checks if the parameters are valid, then starts the activity and waits for the result, in this case, when the t_sec time passes. Then the DONE signal is set. In case of error, the ERR output is set and the ATMT state remains in error until the node is reset. Examples of the SFC for ATMT_wait are also shown in Figure 16.

5.5.2. Node ArUco Searching

Each drone battery holder has a unique ArUco Marker with given ID. Each ID has assigned a mapping from marker position to position where the battery gripper should await for the battery holder. Sensing of actual battery holder position on the drone is given by sensed ArUco Marker position with a given spatial transformation in the form of

$$\begin{array}{ccc}{D}_x^{ID}& =& x-A_x+O_x^{ID},\\ D_y^{ID}& =& y+A_y+O_y^{ID},\\ D_{\psi }^{ID}& =& -A_{\psi }+O_{\psi }^{ID},\end{array}$$

(6)

where $D_{*}^{ID}$ is the new drone battery holder position computed from actual gripper position ${[x,y,\phi ]}^T$ in global frame and actual ArUco Marker sensing vector ${[A_x,A_y,A_{\psi }]}^T$ with given offsets ${[O_x^{ID},O_y^{ID},O_{\psi }^{ID}]}^T$. This offset is given by actual ArUco Marker placement on the battery holder plate, defined for each Marker ID. The actual location of the drone battery holder is based on the following search Algorithm 1.

Algorithm 1: ArUco searching algorithm

Init: k = 0 Output: manipulator new target position for node_TARGET WHILE not found and k < 10 DO Perform another search motion according to the equations $$\begin{array}{cc}{x}_r^k=& x+{\delta }_{x}sin(-1^k·2\pi /5),\\ y_r^k=& y+{\delta }_y/2+{\delta }_{y}cos(2k\pi /5),\\ k=& k+1.\end{array}$$ (7)

5.6. Battery Charging Management

Since the DP is a prototype device, we chose a widespread battery type for medium-sized drones. It is a LiPo battery with four cells (4S). The battery compartment and the charging position are designed for this type of battery. Since these are the standard type of RC batteries, we were looking for an affordable charger that would allow operating multiple batteries simultaneously. The SkyRC Q200 QUATTRO was chosen as a suitable charger and is placed in the body of the Droneport. In addition to charging four different batteries, it provides communication with the control computer. Once started, the charger takes care of the charging progress and informs about its progress via status messages. The serial protocol for this charger is not publicly described; fortunately, there is a freely available third-party description of the communication. The charger messages are decomposed and composed in the REXYGEN environment using a special advanced block named REXLANG which can interpret the general C-code. Once the battery has been replaced, the main program starts the charging cycle for the occupied positions. The charger itself can detect the state of the connected batteries. A separate HMI has been created for the charging subsystem, which can also be used in the simulation environment. An example of the HMI screen is shown in Figure 17.

6. Discussion

The developed system was designed to enrich the capabilities of drones or drone fleets cooperating together on some missions and requiring a continuous possibility of battery replacement and recharging. Droneport belongs to the family of systems with automatic battery swapping, which is the fastest way to redeploy the drones back to the mission. It was developed for middle-sized drones with batteries placed on top. It can be connected to any UAV with MAVLink communication protocol. The system is now in the phase of validation tests in real operating conditions, covering long-time monitoring, error handling and remote management, safety, etc. The current version of the prototype is depicted in Figure 18 together with Drone-X8 as a testing UAV from REX Controls company [37]. A hyperlink to a movie demonstrating the system’s functionality is provided—the reader is referred to Appendix A.

A comprehensive review of key technical parameters is shown in

Table 1. Comparison of our solution with existing drone management systems, part I.

	Droneport	DJI Dock	HEISHA D50	HEISHA D80
dimensions [m]	0.8 × 0.8 × 0.27	N/A	0.92 × 0.7 × 0.69	1.07 × 0.89 × 0.93
weight	37 kg	100 kg	55 kg	75 kg
IP protection	N/A	IP55	IP55	IP54
in the drone charging	no	yes	yes	yes
battery swapping	yes	no	no	no
outside the drone charging	yes	no	no	no
Nr. of battery slots	4	0	0	0
battery status management	yes	yes	yes	yes
battery types	LiIon, LiPo	DJI only (M30)	N/A	N/A
weather station	no	yes	yes	yes
D-RTK base station	optional	yes	N/A	N/A
precision landing support	ArUco markers	N/A	N/A	N/A
return to mission/charging time	2 min.	25 min.	40 min.	45 min.
battery compatibility	2S-6S	DJI M30D, M30TD	2S-4S	2S-12S
connectivity	Ethernet, wifi, LTE	LTE	Ethernet, 4G	Ethernet, 4G
drone type specific	no	yes	no	no
source website		[27]	[38]	[39]

and

Table 2. Comparison of our solution with existing drone management systems, part II.

	HEISHA D135	OPTIMUS Airobotics	Dbox M2	DBX-G7
dimensions [m]	1.65 × 1.29 × 1.58	N/A	N/A	2.78 × 1.42 × 1.96
weight	275 kg	2500 kg	N/A	450 kg
IP protection	IP54	IP54	N/A	IP66
in the drone charging	yes	no	N/A	no
battery swapping	no	yes	yes	yes
outside the drone charging	no	yes	N/A	no
Nr. of battery slots	0	11	7	N/A
battery status management	yes	yes	N/A	yes
battery types	N/A	Airobotics only	N/A	N/A
weather station	yes	yes	yes	yes
D-RTK base station	N/A	yes	N/A	N/A
precision landing support	N/A	yes	ArUco markers	yes
return to mission/charging time	90 min.	N/A	N/A	40 s.
battery compatibility	6S-12S	N/A	N/A	N/A
connectivity	Ethernet, 4G	5G, LTE, RF	5G, LTE, RF	4G, 5G, GMS, LAN
drone type specific	no	yes	yes	N/A
source website	[40]	[41]	[26]	[42]

. We compare the main attributes of our solution with commercially available drone-in-a-box systems. Some manufacturers do not provide the necessary level of detail on their websites or in data sheets. Such entries are marked as N/A (not available) in the tables. It can be seen that our Droneport system is relatively lightweight and compact compared to its peers. It is primarily intended for battery swapping, unlike many systems offering only direct charging of the battery inside of the landed drone. This is perceived as an important advantage diminishing the return to mission time as the drone does not have to wait to complete the charging process. Another important aspect is a limitation to specific drone types in some systems. On the other hand, the Droneport was developed as a general-purpose platform not dependent on specific drones but focused on mainstream battery types. Precision landing support using ArUco markers is also a desirable feature, as it allows a seamless drone approach to the platform. Affordability might be another benefit, with the purchasing costs of our system being around 20 thousand Euros. The compared commercial platforms are offered for prices ranging from 7 thousand to several multiples of our amount. However, a direct comparison is difficult since an exact price is often highly dependent on a specific configuration and additional purchased services such as support, software updates, etc.

The research team plans to focus future development on expanding the functionality of the manipulator with the possibility of payload exchange between the drone and the Droneport. Such possibilities would further expand the area of use of the Droneport system and enrich the capability of existing drones. Please contact the authors if you are interested in using the presented results in your application or research.